After Project Report

During the last half of the spring term my class at university was given the task to create a game using Construct. We were given 9 weeks and between 1-3 programmers per project.

The general experience is that Construct is entirely too filled with bugs to ever be useful in its current state. We spent more time finding work-arounds and tracking down bugs than we did actually getting any work done on our games. The bugs were so numerous that it was good we were working as a class... so most bugs only had to be tracked down once. After one group figured out a bug, the other groups could save time. Python is not as well integrated as it should be, subevents are ok... as long as you don't want to specify anything with OR or ELSE... then it has a tendency to not work.

Many features seem to have been just tossed in without much testing. Or features are half-added and half-completed. I'm well-aware that this is open source and such, but Construct is still not at the point where it is useable as anything except the roughest of game prototypes. Or as an exercise in patience and using unstable software. It does inspire creativity and problem solving though.

We were also unable to merge our files. This made groupwork very interesting. Most games today are mostly made in groups or teams. Not by individuals in their basements. As we are studying computer game programming, it is vitally important that we learn to work in groups. This meant that people had to work in separate cap files, then REDO everything in the main cap file once things were working correctly, and hope that nothing would cause bugs or conflicts. The other option was to have only one main cap file and have the other people in the group frantically looking after bugs and once a bug is found, try to figure out how to fix it without breaking anything else. The end result, at least for my group, was basically having a full-time bug finder-fixer.

Construct (Or "Scirra Destruct... click and crash" as we were calling it by the end of the project) was chosen over other possible programs for this course because it was open source. From comments the teachers have mentioned, open source is not terribly useful when the libraries required to compile and hence fix some of the many many bugs, are not open source. As with most free software, filled with bugs was expected... but not being able to fix them was just silly.

The REALLY ugly ribbon display was also very annoying. If working on a laptop or computer with a small screen, you quickly find that you have no space left to actually build your game. The menu bars which were almost required to be up all the time due to the information, also took up a ton of space on the screen. The layout works well... IF you have a large monitor. Otherwise, rather silly!

Construct was not all bad, as mentioned previously, it is a good learning tool. It also has possibilities if it is not abandoned and if many of the bugs are fixed. It might be an idea to stop attempting to add new features and get the current features stabilized first. I'm aware we were using the 'unstable release' but it is not possible to use the stable release when all help, advice, and such only refers to the most recent unstable. And the first response to any question is 'be sure you are using the latest unstable!'

Most groups in the class did manage to get games together. I don't think any of the groups have managed to create 100% stable games though. News releases and other information can be found at:

https://projects.gscept.com/projects/mp2010

Each group also has a public folder on their repository... swapping out the # with a number from 1 to 7 will get you there:

http://gscept.com/projects/games/2010/G#/public/

I agree about some points and disagree about some... but I hope you reported all those zillion bugs to the tracker or else they will be never fixed

It would be nice to read more project "post mortems" here.

was there a certain level of complexity required for the assignments?

were some of the games to be as simple as pac-man/tetris? or were they all past a certain threshold of complexity/size supermario bros or link to the past?

also, construct is obviously not designed to be very usable for multiperson projects. was it an oversight that some projects were organized into small teams, or was that done intentionally to create an additional challenge to overcome?

The bugs were so numerous that it was good we were working as a class... so most bugs only had to be tracked down once.

This is a good point. Construct has a lot of quirks/bugs that new users need to learn about before construct can be used smoothly. Perhaps someone should make a bug avoidance tutorial.

Many features seem to have been just tossed in without much testing. Or features are half-added and half-completed. I'm well-aware that this is open source and such, but Construct is still not at the point where it is useable as anything except the roughest of game prototypes. Or as an exercise in patience and using unstable software.

Even professional-level tools have bugs in them that need to be worked around, so at least it's a good skill to learn (not that I'm saying the developers shouldn't try to make it more stable).

We were also unable to merge our files.

As has been mentioned, that's an unfinished feature. Hopefully that'll be finished for 1.0.

From comments the teachers have mentioned, open source is not terribly useful when the libraries required to compile and hence fix some of the many many bugs, are not open source.

The developers know about that and are going to fix it for construct 2.

It might be an idea to stop attempting to add new features and get the current features stabilized first.

They have actually gotten to that point. However, they have mentioned that they learned to code making construct, and therefore not only is the code in many places kind of a mess, the structure of the program doesn't allow for a lot of the necessary fixes. It would be faster to recode the thing from the ground up than to fix everything, so that's what they're going to do. It won't require a complete rewrite though so it should require less work than coding construct 1 did.

I'm aware we were using the 'unstable release' but it is not possible to use the stable release when all help, advice, and such only refers to the most recent unstable. And the first response to any question is 'be sure you are using the latest unstable!'

The term stable/unstable is a bit of a misnomer. Stable doesn't really mean that it's entirely stable - it means that it's stable enough, but there's not any new huge crazy bug in it anywhere so it's at least as safe enough to use as the previous one. I would vote that a lot of the time the unstable releases are as stable as the stable ones. I think they need to put a new label on them that's less confusing.

Also, I'm not sure if you saw it already, but you should read Ashley's post on the topic here:

i run into very few bugs actually, if any at all that actually have to do with a problem with the program that i cant easily figure out and work around in a small amount of time, and the stuff i do is quite complex, much more than what ive seen done in any of the projects on your site. infact of all those projects, the level of polish i see in them is in on par with games ive seen made for one hour competitions on this site, by myself and others, which isnt all that high. with code like that, and sloppy work its a sure shot that your gonna be neck high in bugs of your own doing.

from what im seeing you werent given much time in those 9 weeks to actually work on it, or you rather chose not too, further resulting in your frustration with the program and feeling it was "buggy". there are a small deal of work arounds you have to understand to use this program without running into bugs, but theyre not all that difficult to figure out. After messing something up once you'll know what to avoid doing/using. even without those things being avoided construct still presents you with a great deal more power than you make it out to have, or rather seem to be.

I'm interested in what these bugs might be, and i'm pretty sure 90% of them if not more have to do with you inexperience with the program rather than construct itself, due undoubtedly the small window of time you all had to complete the games.

What a fun project, I would have loved to do such a project in collage.

[quote:399dntbv]...open source is not terribly useful when the libraries required to compile and hence fix some of the many many bugs, are not open source.

While you can't compile the Construct's IDE from the source (unless you have the PROF-UIS library), you can compile the runtime and all the plugins as long as you have Visual Studio. You can even compile with Visual Studio Express, you just need to get a hold of the MFC/ATL libraries.

Thanks for spending the time to post your experiences. This reads pretty critically of Construct, but I have a feeling a lot of it is justified. There are some serious problems in Construct that are really important to fix ASAP; we just don't always have the resources to fix them quickly, given our commitments to university, jobs, etc. I might also add Construct is officially still in beta, not yet 1.0, so bugs would be expected (was your tutor aware of this?).

One point about the UI - you know you can collapse/auto-hide all the bars - and the Ribbon - so that they only appear when you mouse over tabs at the edge of the screen. This can give you a near-fullscreen editing.

I'm going to take most of these points as suggestions for Construct 2, particularly:

• Implement a smaller, leaner set of features, and test them better
• Aim for solid reliability of all core features
• Support for collaboration (we're planning a system that works with source control systems like SVN, so existing collaboration systems can be used to allow multiple developers to commit changes in parallel, use the existing source control conflict resolution, and so on).

- Support for collaboration (we're planning a system that works with source control systems like SVN, so existing collaboration systems can be used to allow multiple developers to commit changes in parallel, use the existing source control conflict resolution, and so on).

Oh my word that would be incredible, especially seen as I (British dude) work with someone from San Fran on a game, we have to make sure we take turns using the same .cap - this SVN feature would be very helpful.