Main idea

A lot of books, articles and tutorials have been written about the benchmarking of applications, engines and various software systems.

This is what the old Wikipedia gives us about it:

Benchmark performance test (eng. Benchmark) - a control task necessary to determine the comparative characteristics of the performance of a computer system.

But what if we get to the question of benchmarking game engines a bit from the other side? All game engines and game development SDKs (and not only) often advertise themselves as very intuitive and easily digestible tools. We sell easy to learn, amazing learning curve and the entrance, demonstrates lightweight and beautiful examples, where one screen of code being launched creates some kind of wonderful magic. So, in preparation for the upcoming Ludum Dare event, I once again decided to look around and see what the “market” simple Emelya offers - to someone who is in game development without a year a week. That is, one of the groups of people of the very Central Asian, which sells these most amazing qualities of easy engine digestibility.

What if we ... try to test yourself when working with different engines to write games? Yes, yes, that is, their productivity on them. Literally, we take a few of them, lock ourselves in a cave with a laptop, internet and a stopwatch, and write down all our results in a neat tablet, and then try to draw some conclusions. In parallel, we note that we liked it, which surprised or strained our work with this or that engine.

About benchmark

So, the objects of testing are three game engines. Here, probably, it is somehow more or less formal (as far as it is possible) to describe your “configuration” (yes, as in the case of typical benchmark results, they write the configuration of iron, where they did the runs, the description of the benchmark, and so on).

"Configuration" or About

I am a Java developer. Industrial development experience 5+ years. Also in the work I wrote a little on JavaScript, Lua (quite a bit), the shell. Higher technical education. I did not attend design courses, I did not study game design, only an ardent fan of various PC games. The last year was carried away by the creation of the simplest computer games.

About the task

The test task was chosen project clone Doodle Jump. I am sure many people know or played it, this is a very cool and very popular game for Android.

The rules will be:

1. Under each engine is given 4 hours of time. This includes how to study, familiarize, tinkering in the nose, trying to write a prototype, debugging the game, in general, the full cycle of creating the game.
2. Every half hour, in a short break, I will try to fix what has been done in order to somehow adjust my work, outline a future work plan, make notes, notes, and so on.
3. Before starting testing each engine, we will try to decompose the game project into its constituent elements in order to assign them conventional units. Thus, we will measure our “productivity” of the game developer for each engine in parrots and will be able to compare the results not in words, but on at least some figures.

Decomposition of the game into components

In a very abstract and high-level form, I see myself the components of the game like this:

1. Player (sprite, jump behavior, reaction to pressed buttons)
2. Objects at the level of: platforms, enemies, etc.
3. Physics: the player’s jump speed, free fall acceleration, the platforms should handle the collision only if they are jumped from above and let the player pass through him if he crosses it from the bottom of the platform.
4. Procedural level generation: initialization and addition to the level (in arbitrary places, but with certain rules and restrictions) on the fly of new platforms and enemies, creating for the player enticing game situation
5. "Camera", watching the player, as long as he moves up the level. The camera should keep the player in the field of visibility for the player and gradually “bounce” with him, displaying new platforms appearing in the rendering area (in the camera's field of view)
6. The mechanism of operation Game Over . A player loses if he reaches the bottom edge of the visible area (after having already jumped at least once)
7. Scoring points to the player. Let's just update the player's height meter. We will update the counter on the last reached platform (the one from which it pushed off the last time)
8. HUD : display player progress. Height display.

For simplicity, assign each component one point of our parrot units of measurement. Total maximum - i.e. The full playable version of the project is equal to 8 points.

Below are the assets used in the display. These are hand-drawn (I’m not an artist, as you can see) character and platform sprites sized 64x64, in * .png format.

And also give a couple of flowcharts:

1. This will be the calculation of the "floor" for the player (remember, with a jump up, the screen is shifted, and the flight over the edge of the screen means prigrysh)
   
2. And so we calculate and with each clock cycle we update the vertical speed ( y_velocity ) and the player's y coordinate, it is influenced by two factors: the acceleration of free fall ( GRAVITY ) and the platform, upon reaching which, the player pushes off with the fully restored speed
   
3. The algorithm for calculating the horizontal velocity, like other mechanisms, was left outside the scope of the article.

By the way, I still have questions:

1. How is it better to implement camera tracking for the player? For the time being, it will be tied to the vertical coordinate of the last, highest platform that the player was able to reach, thus, such a platform appears in the lower part of the visible area, and we see new pieces of the generated level.
2. The platform generation algorithm itself. According to my idea, it will be a certain “platform factory”, which, at each beat of the game cycle ( dt ), knows the highest platform that exists at the level and with a random height value (a certain threshold, not more than the player’s jump height, but not less than a certain percentage of its height, so that the platforms do not cling closely to each other) adds a new platform to the level when the player has advanced. It is also interesting to question the increasing complexity of the game, how the mode of generation of these platforms should change.

I would be very pleased with your ideas, lifehacks and suggestions in the comments and drugs on these two undoubtedly game design issues.

About engines

Three candidates with very interesting features were applied to me. So, the table below summarizes the parameters that would be useful to keep in mind when analyzing the results of their tests.

So, we see that the selection is quite interesting. It is interesting because we will deal with different combinations of our qualities and characteristics of engines. And let's see what sets up at the end: the engine in which I’ve already filled my hand a little, pumped PL or a completely fresh and new engine for me with promising chips, but not mastered at all, and besides, not in my main development language.

Why not Unity / Unreal Engine / Other Awesome Engine etc.?

Many would have probably wondered why, I didn’t go the standard way, and didn’t take the most common flagships of our time: Unity or Unreal Engine? I would formulate my thoughts like this: I want to build a very simple, minimalistic and tiny game. With a pair of game elements that make up the game mechanics, one playable character, simple level generation and no special effects or very conditional special effects, like on old arcade machines. So, figuratively speaking, my task is to draw a red circle on a black square, and for this I am invited to take Photoshop . Simply put, the set of features, modes, and features of Unity scared me off. At this stage I would like to understand every detail of my game.

Best of all, these are simple and small engines, with a limited set of possibilities, perhaps not with the best tuling and ecosystem, but simplicity and limitations also have their own beauty. Having only a limited set of tools - and in the case of Love2D, your tool is your code and nothing more, you focus on a fan, on writing something cool, reviving a character or a player’s environment. Already more complicated engines expand your choice, and writing code smoothly flows into many things: writing scripts (code), linking scripts, mapping assets, adding configs, redefining configs, mixing third-party plug-ins, writing scripts and configs for third-party plug-ins, multiple clicks on dozens and dozens of dialogs and windows ... Let's just say that I am still afraid of such tricked and undoubtedly advanced and powerful game development engines. Well, I also do not want to re-remember C # / JS / C ++ and write on them.

I’ll summarize a little my motivation when choosing an engine with a link to this video, where the author seems to me to literally remove from my tongue what I tried to formulate in words to myself and others all this time: https://www.youtube.com/watch ? v = JH8xwNOQ0TM

Defold

Defold - cross-platform engine from the company King.
Supported Platforms:

• Html5 (webgl)
• Android 2.3 (API level 9) +
• iOS 8.0+
• Windows Vista +
• OSX 10.7+
• Linux

A curious fact that King is owned by Activision Blizzard "holding".
In the engine, I was attracted by the development language - Lua , support for a heap of platforms for game builds, as well as the distribution kit of their own cross-platform IDE - can also be installed on Linux as well. This bribed me when choosing between Defold vs. Corona SDK .
And below is a log of what was done to the control points:

Below, in the spoiler, a few gif-animations are hidden, showing the progress in time:

Total, benchmark points:

1. Player (sprite, jump behavior, reaction to pressed buttons) (V) Yes
2. Objects at the level of: platforms, enemies, etc. (V) Yes
3. Physics: the player’s jump speed, free fall acceleration, the platforms should handle the collision only if they are jumped from above and let the player pass through him if he crosses it from the bottom of the platform. (V) Yes
4. Procedural level generation: initialization and addition to the level (in arbitrary places, but with certain rules and restrictions) on the fly of new platforms and enemies, creating for the player enticing game situations (X) No
5. "Camera", watching the player, as long as he moves up the level. The camera should keep the player in the field of visibility for the player and gradually “bounce” with him, displaying new platforms appearing in the rendering area (in the camera's field of view) (X) No
6. The mechanism of operation Game Over. A player loses if he reaches the lower edge of the visible area (after having already jumped at least once) (X) No
7. Scoring points to the player. Let's just update the player's height meter. We will update the counter on the last reached platform (the one from which it pushed off the last time) (V) Yes
8. HUD: display player progress. Height display. Optionally, it seems there are no progress indicators in the original game. (V) Yes

Benchmark Score: 5/8

Love2d

This is a very minimalistic, but powerful enough and flexible engine for creating prototypes. In general, with proper skill, it is even suitable for publishing full-fledged games on the market. There are some good inspirational examples. Offhand, one and two .

In general, on this engine, I recommend a very useful series of tutorials from Habra, which spurred me and gave a powerful impetus to mastering this engine, I will give only a link to the first part, then you can get to the other parts with it: Creating a game on Lua and LÖVE - 1

So, below is a log of what was done at the control points:

Calculate the "performance" of the engine:

1. Player (sprite, jump behavior, reaction to pressed buttons) (V) Yes
2. Objects at the level of: platforms, enemies, etc. (V) Yes
3. Physics: the player’s jump speed, free fall acceleration, the platforms should handle the collision only if they are jumped from above and let the player pass through him if he crosses it from the bottom of the platform.
   (V) Yes / (X) No // * Implemented, but not quite perfectly, with significant flaws. I would put here 0.5 points for the point.
4. Procedural level generation: initialization and addition to the level (in arbitrary places, but with certain rules and restrictions) on the fly of new platforms and enemies, creating for the player enticing game situations (V) Yes
5. "Camera", watching the player, as long as he moves up the level. The camera should keep the player in the field of visibility for the player and gradually “bounce” with him, displaying new platforms appearing in the rendering area (in the camera's field of view) (V) Yes
6. The mechanism of operation Game Over. A player loses if he reaches the bottom edge of the visible area (after having already jumped at least once) (V) Yes
7. Scoring points to the player. Let's just update the player's height meter. We will update the counter on the last reached platform (the one from which it pushed off the last time) (V) Yes
8. HUD: display player progress. Height display. Optionally, it seems there are no progress indicators in the original game. (V) Yes

Benchmark Score: 7.5 / 8

Java

Perhaps it would be logical and logical to take a closer look at the engines, where the development language is the one in which I have the most experience and skill, isn't it? Actually, intuition and some internal sensations kept me a little from this. The fact is that even as a student, I somehow watched my classmate suffer with the jMonkey engine. Tuling, work with the engine, documentation, all this together created some kind of not very pleasant picture. It seemed that the engine simply does not give you a chance to make friends with him, very much its use looked somehow unpleasant.

But still, I decided to see what is available today, and I looked only in the direction of engines that only guarantee 2D , I didn’t care about 3D support. One of the engines, Lightweight Java Game Library 3 , has in its title and introductory word Lightweight . Ironically, the simplest basic examples on the main page, just a few screens long, just scared off.

Yes, of course, Java very verbose, what do you want, you say. But I know that you can write very compact and very expressive things on it. I saw a nice and compact API.
And in the end, the choice fell on FXGL . At first, I didn’t have any enthusiasm and pleasant excitement that happens before I start learning some interesting piece or library. But from the first examples and brief pages of documentation and examples, this engine pleasantly surprised me more and more. In the approach and API that he proposed everything was logical, understandable and consistent. It definitely helped you to build a clear and flexible cycle of your game, handler logic, HUD , AI , collisions, and other elements.

Interesting moments and chips FXGL:

• As the name may hint, for the visual part, the engine uses the JavaFX API (with its all buns and anti-buns) for rendering and layout of elements. In general, I think this is a good and quite sensible decision. Thus, the author avoided a number of problems (there is no need to implement and maintain your rendering component, you can use a refined solution from the Java ecosystem). Here is what the author himself says in one of his first tutorials, and I really liked this phrase:

  
  

  "For most UI objects we simply use JavaFX objects, since the wheel."

  But in general, of course, you get a bunch of features and some drawbacks of JavaFX , and also (I'm not very aware of the details), but as far as I know, there are some licensing restrictions on using JavaFX in my projects, and it seems JavaFX Goes and will go only in limited deliveries JDK ( Oracle , maybe some more).

  
  

• The test project, cloned from the repository, on the basis of which I began to sculpt the game, kindly puts logs in the project logs/ daddy logs/ after each start of the game. It is very convenient, you can immediately watch the debug-information out of the box, it is very useful for diagnosing, understanding where you are nosyachil, if you suddenly met a plug in studying the engine.

  
  

• Also (apparently again with basic settings) the game provides a pop-up menu by pressing the Esc . Also a nice bonus, I hope it is customized or at least disabled by code or configs.

  
  

• Here Debag finally works! Finally! In Love2D doing it is uncomfortable and unpleasant to say the least.

  
  

  Development log

  
  

  Below is a brief summary of my progress, where I briefly noted what was achieved after the 30-minute interval, as well as some of my thoughts and comments. See the log of my consciousness during these 4 hours!

  
  

GIF- , .

"" … , , , ? .

Benchmark Score: 8

, ,

:

, , , ( ). , , Java FXGL , , Lua , . , , .

:

1. FXGL ? I would not say that. Love2D , Defold , , , , Love2D - , .
2. , . , . (, ), . , - . , , , , . , , , . .
3. gif-, . . , , "" , .

?

, - , ?

So:

1. , . , , , , . - , - ( Love2D ).
2. - , Love2D , . F to pay respect .
3. . , , , - - , , (, , )
4. . 4 , . - Game Jam , .
5. ! , , - Roadmap , , . (!) (?) . 30 . , . , , ! , pet- 44 - Ludum Dare .