The goal of the experiment was to confirm whether or not my assumptions about three popular game engines were correct, at least in one important factor: processing speed. So I set the specifications of a benchmark to create in each that had the following specifications:
- 1028x800 resolution, windowed.
- Bullets made up by 2x2 pixel sprites of a single color (black).
- The bullets would bounce off each other.
- The bullets would bounce off of the edges of the window.
- There will be two text displays. One displaying the frames per second, the other displaying the number of active bullets.
Experiment 1: Construct 2.
Experiment 2: Clickteam Fusion.
I had completed all of the Clickteam Fusion tutorials a couple weeks ago, but apparently that was not enough for it to move from my short term memory. I ran into three problems replicating the code I made in Construct 2:
- How does one spawn an object where the mouse is clicking? It seems I only had a choice of spawn an object at a fixed coordinate or relative to something already in the screen, and there was no "mouse" object.
- How does one keep the projectiles on the screen? "If bullet is outside layout, bounce it (off of itself) back into the layout" was difficult to find, but I eventually recollected it was under the "test position" section.
- How does one perform a textual display of FPS and entity count (from an incremented global variable)? Turns out that the "text" objects were bad at this, there seems to be no means to do it, or else Clickteam Fusion's lack of Intellisense made it unable to point it out to me. The answer is that you use "counter" objects, instead.
I eventually cobbled together "close enough" code above, and the results were that I could pull 900 moving projectiles before the FPS fell to 50 with my hardware. (Funny enough, this was only in the Windows-engine driven "preview" mode. The free version of Clickteam Fusion only allowed me to build HTML 5, and their HTML 5 optimization is currently awful: it could only put out about 25 projectiles before the FPS had already fallen to 50! Way to put your worst foot forward, guys.)
Experiment 3: Game Maker.
Alright, so I haven't dabbled with Game Maker Studio in months. I tried to put together the benchmark in an identical manner to the other two, but found myself floundering because it has been so long since I used it. Game Maker is simple compared to coding from scratch, but significantly more complicated compared to either Clickteam Fusion or Construct 2, it is just that much less visual even if they did bend over backwards to add "drag and drop" methods to nearly everything.
Where the latter two go out of their way to differentiate different types of objects, Game Maker treats all objects as the same and has you define how they behave. I have a certain respect for that, I like an engine that lets you get at the nuts and bolts of things. (In fact, if you want to get really technical, you can even see the memory addresses of your various elements! I am guessing certain functions can make use of those addresses, because otherwise there would be no point in revealing them.)
Oddly enough, I could never get those projectiles to stay on the screen, even when I resorted to trying to wrap them around instead of bounce off the edge. It's probably possible, I'm just doing a lousy job of coding in Game Maker.
Even if the projectiles were not on screen, the engine was still simulating their movement, so this would work for benchmarking purposes. Game Maker could pull around 600 projectiles before the FPS fell to 50 on my hardware. This is without the benefit of the Yoyo Compiler, which is advertised as providing 100x the speed, but I do not yet have access to it.
I would like to reiterate what was saying earlier: these findings lack sufficient controls to be considered scientifically accurate. The main problem is that there is probably quite a bit of black box mechanics going on in each engine, and all I did was test one facet of that engine (projectiles) and possibly did not even code them in the most efficient way possible. It's possible each engine has strengths and witnesses in the performance of different kinds of operations.
It's a pity, because the worst-performing engine, Construct 2, is an absolute joy to develop in. Coding this benchmark on that IDE went a lot smoother than the others, and this is not completely because I had completed its tutorial so recently. It just has a radically improved GUI over the product it was initially created to supersede, and the implementation of intellisense auto-completion works well and made a big difference. Despite not being a very good performer, Construct 2 is a very tempting purchase for its incredibly user-friendly interface and an extremely attractive pricing structure, and it is probably going to be the choice for any 2D product that does not require much in the way of power, especially on the HTML 5 platform where speed really is not much of a possibility anyway.