Pain is inevitable. Suffering is optional.
― Haruki Murakami, What I Talk About When I Talk About Running
Software Development and Data Consultant
Pain is inevitable. Suffering is optional.
― Haruki Murakami, What I Talk About When I Talk About Running
Being an early adaptor for Construct 2, it was about time to get a game built with it out of the door. I think I bought this in 2011 for 30€ or something like that. With an increasing interest in educational apps and new teaching and learning approaches I finally dug into Construct 2, building a complete, yet simple game.
Without further ado: Color Duel can be found an Google Play
It’s an adoption of the good old “Simon Says” game, with multi player support and multiple, unlockable levels.
Building it with Construct 2 was quite some fun! The build release cycle is great and development can be insanely fast. This does not only apply to the application logic, but also working with assets. All of this is quite well done and there are many components you can use out of the box to achieve a lot! Besides Construct 2 I did use Intel XDK for building the app.
On the downsides are maintainability and collaboration. As this was my first project in Construct with a considerable complexity, this might improve when having more experience with the tool. But this time, I found it increasingly difficult to navigate and change the application logic while the project grew. I am sure with a lot of discipline one can keep it clean, but Construct does nothing to enforce a good and maintainable design. It’s easy to end up with terrible state handling and a brittle code base.
I did not get into automated testing this time. As you are not writing code, but wiring up events via a GUI, unit tests don’t seem to be viable. However, it should be possible to use integration testing with a test framework for web applications and an automated browser, something like mocha + Selenium for example. As the rendering happens in a canvas element, this would be a lot more cumbersome than testing against the DOM though.
Construct 2 projects are stored in XML mostly, this is great, because you have a more sane version control than with binary files. However, when collaborating on the same code, this means you would need to resolve potential conflicts in XML. This alone does not sound very appealing and keep in mind, that you could not rely on tool chains you might be used to, like solving a conflict in your IDE or editor, getting nice diffs and being able to run automated tests.
Would I use Construct 2 again? Oh yes, certainly! It is an amazing tool and fun to use even if you are an avid programmer. More so if you cannot code, but want to create a game. Performance is very good and having support for Android Crosswalk via Intel XDK is nice. Of course it’s not a native app, which puts some constraints on the performance, but for most 2D games and building on recent hardware you should be more than fine.
It’s an amazing tool for rapid prototyping. It might not be the best tool to use in a professional team environment though. Maybe this is just me, but with having written so much code professionally, it’s a bit hard to see how to establish good QA solutions and most efficient development processes with Construct 2 in the longer term for more than trivial games. That being said, don’t hesitate giving it a try, especially if you plan to do prototyping or just a small and simple game.
Next time I am going to use Construct 2, I will try to pay more attention to long term maintainability and QA. What are your experiences with Construct 2?
Leave a Reply