Game in 14 days [For those who have been building a team for years, but never made a prototype]

On the Internet, there are often "teams" that have existed for years, the list of developers consists of a dozen people, and even "we need everything!" In this case, there is no adequate demo even in the near future. Looking at all this I would like to say: “What the hell are you doing ?!” But this is destructive. It’s not enough to criticize. Positive examples need to be provided.

These thoughts prompted me to an interesting experiment: in November, the “flying contest” started on gamedev.ru . The competition involved development within two months. However, it seemed to me that this is a bit much. Therefore, I signed up for the participants ... And I forgot about the contest for a month and a half.

The main idea of ​​the experiment is to make a full-fledged project in two weeks. The deadline for the contest is a good deadline. In addition, the last week of the competition coincided with the end of the New Year holidays, which made it possible not to be distracted by other tasks. So: a contest, a project from scratch, two weeks.



If you don’t feel like wasting time on the whole article, you can scroll down. There is a review of competitive projects and a brief conclusion from this entire experiment.

We have two weeks. The main question is what to do. Honestly, I initially thought that the contest runs until January 7th and planned to spend only one week on it.

One week is not very much, and therefore the launcher genre was chosen.

Launcher is a game, all the action of which takes place only on one level. In fact, the passage is reduced to a series of attempts to fly further / higher. Each attempt (except the last one) is doomed to failure, but gives points that can be spent on pumping the character so that he can fly better. The game ends at the moment when the character is pumped enough to reach the end of the level.

A great representative of this genre is the game Butibo Bison .

I planned to repeat the gameplay of this particular game. However, when I decided to clarify the details of the competition, it turned out that the final was not 7, but 12. 12 days! You can already work with this! We will do 3D Action!

Based on a few of my favorite games: Vanger, Mechanoids, Ex Machine, Renegade Ops. I would like to make an RPG, but in such a short time to work out pumping will not work. Therefore, the goal: based on the gameplay of RenegadeOps / Vanger, a set of quests - by analogy with Ex Machine / Mechanoids. Well, so as not to waste time thinking through the universe, let the game be in the universe of Mechanoids. Moreover, my actual residence 7 km from the former office of SKYRIVER studios has such loans.

Day One
What do we have? A framework that released several 2D games. Of the 3D capabilities - only loading the mesh from the file. There is also a landscape editor. We use it to create a game landscape. Task on the first day:

• Create a test landscape and display it in the game.

For this we need a 3D camera. She should be able to establish a species matrix and a projection matrix. I didn’t even have to write a camera class; over the years of development, I already had it. Just drag and drop the camera into the framework.

The next sub-task is to transfer the shaders from the editor to the game. Shaders are open, all you need to do is remove the editor tools from them: highlighting the edges of tiles, dynamically calculating normals and other little things.
The main subproblem, which took up most of the day, is the implementation of the class responsible for loading the file containing the landscape and transferring the geometry to the render. The task is not too difficult, but took half a day.

The result of work:



And what do we see as a result? The landscape is very noisy. The reason is very simple - when I converted the textures, I forgot to register the generation of MipMaps. But already 11 o’clock in the evening ... A small task, but I really want to sleep.

Day Two
Two tasks are planned for today:

• Shadow Cards.
• Drawing models (without models, do not really test the work of shadows).

First of all, I turn on MipMaps, which I did not turn on yesterday and it turns out that something is generating an OpenGL error in the code. There are not many checks in the code and the error creeps out when loading shaders. I sin on the crookedly transferred shaders from the editor ... I spent an hour to understand that the error was not in the shaders ... It turns out that the texture setting was incorrect and the value GL_LINEAR_MIPMAP_LINEAR was gone in MAG_FILTER, which should not be there. I fix it on GL_LINEAR and everything starts without problems. Meanwhile, two hours were spent ... This is a lot, given that there are only 12 days.

Now let's take a look at the models. In general, I already have a loader of simple models. But it’s not enough just to be able to draw a model on the screen. It is necessary that the game draw only those models that are now in the camera frustum. The easiest way to organize this in our case is to divide the entire game space into squares, where the square is approximately equal to the area visible on the screen.

The landscape is already divided into approximately such squares, so we create an object manager that divides the playing space into squares in accordance with the landscape settings and processes only those objects that are no further than one square from the camera when rendering. That is, a 3x3 square zone is drawn, where the central square is the square in which the camera is located. Plus, the object manager must track the movement of objects and, if the object has moved outside its square, move it to the current square. The task of writing such a manager took about 5 hours.

The next task is to implement the shadow map. But for shadow maps, I need Render To Texture support in the framework, which I did not have, since previously implemented projects did not require post effects, and RTT in 2D, except for post effects, is not used anywhere.

We spend another hour on the implementation of the wrapper over FBO. Nothing too complicated.

We proceed to the last task of the second day - Shadow Maps. Everything would be fine, but I'm a Stencil Shadows follower ... By all means I always avoided touching Shadow Maps. Well, I didn’t like them. But time goes on ... in modern realities there is generally no reason to use stencil shadows. Their performance drops too much with increasing complexity of geometry and screen resolutions. So there is no alternative - you have to tackle the implementation of shadow maps. Of course, I am well acquainted with the theory of the work of shadow cards, although I have never implemented them. Therefore, I do not expect any particular difficulties. I took a manual long delayed for a rainy day and implemented shadow rendering on it.

By the way, I used this manual. I recommend to everyone. Competently and in the case everything is painted, including the main problems that come out when implementing shadow cards.



With mipmaps, the landscape began to look better, and the shadows look good.

Day Three. We
continue to fasten the functionality we need. Two tasks are planned for today.

• Integrating the Lua scripting language using the LuaJIT project. Just recently, an updated version of the JIT compiler for this language was released, and our experiment is a great opportunity to try out the new compiler.
• Particle system integration. I planned to use Astralax's Magic Particles.

Let's start with LuaJIT. We download source codes and easily collect dlls under Windows. We are writing a small wrapper class (I do not like luabind and analogues, I prefer to work with lua through a minimum of layers). And, actually, that's all.

I tried to build it on Android ... and for an hour I could not do it. I decided not to spend more time on this, because this is not critical for the competition, and in the future it will be possible to get confused separately.

The second part of the plan for today is the integration of the particle system. I worked a lot and productively precisely with the Astralax Magic Particles system, since it is really difficult to find something more powerful and simple in this area. Plus a very adequate developer, which is important when developing projects.

However, I was stopped by one not important moment for the contest, but an important moment for the framework. The fact is that the framework is created, in particular, for projects under Windows CE. And, unfortunately, this is almost the only common OS that is not supported by MP. This is understandable, the game market on WinCE is absent as a class. But for me this is important, so I decided not to use MP yet ...

From frustration and procrastination, I went to play Burito Bison and spent an hour and a half on it.

However, the day is far from over. Hardly passed for lunch. I decided to make a start menu. He made a simple landscape, placed a couple of buildings and two helicopters on it. And a bug with shadow maps got out. It is clearly visible on the KDPV on the corner wall to the left under the "Exit" button. However, I decided not to edit this bug - the look in the game is not the same and on it these bugs are practically invisible. And editing shadow aliasing promises to kill several precious hours.

Made a menu interestingly driving up / down. It turned out fun. He added the “Settings” and “Continue” buttons, although I understand perfectly that with a high probability I will not be able to implement their functionality in the framework of the competition - there will not be enough time.

You may get the feeling that I spent time on unnecessary garbage - menu animations. But this did not take too much time, because the framework can animate for the UI. It took only a dozen minutes to indicate what and when to animate. But with the animation, the menu has become much more interesting.



Day Four
Plan for today:

• Player Helicopter Control
• Weapons: laser, machine gun, rockets

Only at 4 p.m. did I take up tasks directly from the plan. Before that, he had been solving all sorts of tasks that had no direct relationship to the plan, but the plan could not be started until they were finished. One of these tasks is a spawn unit. For example, a player’s helicopter ... Spawn requires working scripts, working scripts require loading the level and prescribing the corresponding functions through which you can control units ...

Next - more. I made a helicopter control and it turned out that when you press the button and move the mouse, Qt starts to hellishly slow down.

I, like any reasonable programmer, sinned on myself ... I rewrote the internal message processing system. I checked for duplicate messages ... And it did not help.

Okay, I abandoned the usual messaging system and read the status of the keyboard and mouse ... And that didn't help.

I completely disabled the input system in my engine ... And still got friezes. I made a WH_GETMESSAGE hook on all messages related to input, intercepting and canceling all messages ... This did not help. There is nothing left but to explore the system outside my development environment.

The answer turned out to be simple ... I spent three hours fixing a bug that wasn’t ... This Synergy slowed down if I pressed several buttons at the same time. I removed Synergy and everything became smooth and neat.

As a result, I did not have time to tilt the helicopter towards flight. It seems to be a trifle, but it’s important ... But still not so important as to spend time on it now. Moreover, it is already 11 pm on January 4 ... 4 days have passed, and I just started to fly a helicopter. So shooting, shooting and shooting again.

At two in the morning I recorded a video. Missiles did not have time. But he decided that now they are not as important as a dream.



Day Five.
The task for today is to make a game location.
I have ten buildings that were bought at 3drt.com for another project. First, I wrote about the plot of the game, then made a list of buildings and figured out which building can play what role in the game. What looks like a mine, what looks like a main base, etc.
In the landscape editor, I sketched a game zone:



At each point I made a signature, consisting of the name and serial number of the model used.

After that, I drew the boundaries of the playing area with the help of mountains and a couple of impassable mountains I drew in the middle of the map so that the player could not fly directly.

The next stage is to make the landscape heterogeneous and to lay roads. Because time is very short - allocated for all three hours. This time was only enough to create a minimally playable landscape. There was no time left for any artistic delights.

The next task is to arrange objects and set patency zones. I do not have a suitable 3D editor for the framework, as The framework has always been 2D and all projects on it were 2D. Fortunately, I have an editor created much earlier for 3D projects. It is quite complex and has a complicated save format. Yes, and he was written for a completely different engine, so you can’t directly use it. However, for today this is not important. Create a location in this editor.
In the editor, I arranged the objects and drew the zones:

• Roads
• Passable off-road areas
• Flight Areas
• Safe areas (located near buildings, within such areas you can not shoot).

The moments in the video when the whole landscape is painted red-green is, in fact, editing zones.

Day Six
Plan:

• Loading the location created in the editor
• The functioning of all buildings (the operation of turrets and the definition of "entry" into buildings)

We have a location in the editor, which is not designed to work with our game engine.
I decided not to bother downloading its complex format in the game and did a simple thing: I added the ability to save the scene as a text file to the editor.
Then I saved the location to a text file. It turned out something like:


Next, we write a simple utility that from a complex text file with a bunch of objects and properties tears out only the ones that are needed directly in the game and saves it in a digestible format.

Next we need to load zones and objects. Decoration objects are simply added to the object manager written earlier, and the game forgets about them, and the rest of the objects are created in the usual manner.

In general, the envelope and loading location took quite a small part of the day. Most of the time was spent on the implementation of the turret functionality. They work simply: if a player fired in a safe zone, then a timer for 15 seconds is activated, during which all the turrets in the radius of destruction of which the player is located open fire on him.



Seventh day

• It's time to implement artificial intelligence.

I already have artificial intelligence that can perform various functions.
It was made several years ago when there was an idea to implement an AI contest. Actually, a 2D model of the world of mechanoids with their rules was implemented. Merchants received points for the delivery of goods, security guards - for escorting merchants, hunters - for brought heads, looters - for stolen (not bought) and sold goods.
How this AI worked can be found here:



Circles are living units.
Red letters are dead units.
Black crosses are a burden.
Two teams - green and red. Actively trying to portray a living world.

AI cannot be transferred to the forehead. The fact is that in the world of mechanoids, a unit is something soaring and shooting in front of itself. That is, there is no problem with the turning radius, it is possible to move sideways. In this project, the situation is different: a unit is a land vehicle with wheels and all the ensuing problems.

All day was spent making AI.

There is no video for this day. Due to the fact that by the end of the day there was still nothing to show. The result of the work during the seventh day was the ability to create units using text files (an editor for these cases was already created outside the competition).

The usual unit config looks something like this:


In a day, the game learned to parse all this and load data. Configs of this kind, in fact, are not one, but two. The second - to describe the turrets that are placed on the unit. In this case, the turret GUN_TURRET_1 is placed.
As you can understand - this is January 7, Christmas. And the family tradition is to get together with all relatives in the parental home ... Therefore, so little has been done - I spent most of the day with my family.

Day eight

• We continue to cut AI.

Units learned to ride and attack. Also pursuing the enemy in sight. The main part of the work was devoted to movement.

Shock absorbers did not fasten. One o'clock in the morning ... Due to a delay in the deadlines of the seventh of January, he categorically lost his plan. So the detour of obstacles - into the furnace ... Into the same furnace and physical interaction between units ... And the suspension of equipment is also there ... Especially sad last. Without calculating the suspension, the units rigidly repeat the landscape and it does not look like ice. But they perform their own functionality, so we leave it that way.



Day Nine.
Four types of AI were planned in the game:
Merchants - buy goods and sell in another building.
Guards - follow the traders and attack the enemy, if they see.
Hunters - ply the map and attack opponents, periodically taking the heads of killed enemies and friends to the base.
Marauders - they ply the map and attack primarily merchants, periodically taking selected goods to the base.
Three types of AI are made. I didn’t do looters, because there are no goods. Rather, there are goods. Merchants are bought and sold by them. But he decided not to dump cargo at the location in the event of the death of a unit. Accordingly, looters who were supposed to collect cargo near the corpses do not make sense. As a result, the AI ​​of traders, security guards and hunters was made. I fixed a couple of bugs. Made the attitude of clans towards the player changing - depending on the actions of the player.

Made by HUD. An inventory has been made into which you can pick up dead units and from which they can be thrown out if necessary.



Day Ten The
final is drawing near.

There is an understanding that you need to finalize the picture. As you can see from the result of the previous day, the battles look fine ... until someone dies. Units just disappear, which doesn't look good. There are two options. Or make the unit fall apart into separate parts. This task is quite complicated, and not so much from the point of view of programming, but from the point of view of the routine work of cutting units into parts and exporting them to a digestible format. A separate point - I really do not want to waste time adding animations to the engine. The second option is a particle system. But Magic Particles does not know how to WinCE. Integrate it for use on other platforms? But I really want to avoid solutions in a cross-platform framework that cannot work everywhere ...

In the end, I settled on the following solution: use Magic Particles, but completely abandon its native API.

In practice, this was implemented as follows: a converter was implemented that played effects created in MP and each frame saved the state of all visible particles to a file. The output was a file describing the state of the effect at each moment of time, but at the same time not tied to the Magic Particles API. A file that I can play on my own on any platform.

This option does not even closely cover the entire spectrum of MP capabilities, but it can cope with explosions and other simple and non-looping effects. And this is what I need.



For some reason, the explosion turned whitish, but I decided not to waste time on the proceedings. It looks at the C grade, but there is very little time left. In fact - a day and a half: the eleventh day and the night of the twelfth (the competition ends on the 12th day at 9 am).

Day eleven
All the remaining time, it was decided to spend on quests. Of course, the game already has some kind of gameplay. But the quests will give meaning and maybe delay the player a little longer.
There is nothing special to paint here.
Quests are completely hardcoded in scripts. No tools for editing links. No tools to configure the script without coding ... Simple and uncomplicated code.
I made a dialog box for communicating with NPCs (in our place buildings play their role). The principle of operation of such a window is almost identical to the quest dialog box in Space Rangers. I think it’s quite possible to write a simple converter that will make text quests from Space Rangers suitable for launching in this game.
I decided not to make a mini-map, because then immediately the limitations of the world become apparent. But I want to create the impression that the world is lively and large. But just like that, you cannot leave the player wandering. Of course, there are players who will be interested. But most of them get lost at the first intersection and send the project away.
Therefore, a half-hearted decision was made - to implement a compass without a map. The compass indicates the direction to the selected target, and at the starting base, you can separately add a mark for any building.

The video shows the process of completing one of the tasks in its entirety. Helicopter speed increased so as not to delay the video.



Surprise!
I completed the quests. The game is possible to completely pass. Late night of the eleventh day. I climbed into the topic of the competition to once again clarify the deadlines and determine a plan for the night ... And it turned out that a couple of days ago most of the participants voted to extend the competition for another two weeks!



This goes against my plans. Yes, and violates the idea of ​​making a project in a short time.

As a result, I come to the following decision: I sleep normally at night, and on the twelfth day I do what I planned to do at night. And I add two more days (up to a full two weeks) to “comb” the project.

Twelfth day
He polished and reshooted all the quests. Made the player respawn effect. At the point where the player was at the time of death, a teleportation effect is created, at the respawn point, an effect is also created. Slightly improved the search for the way so that units are less likely to run into obstacles. But they still come across with some probability.

Added a few more types of units. Or rather not species - the units actually remained the same. But before, all roles (hunter, marauder) in all clans were performed by units that looked the same. And I made every unit in each clan look unique.

AI slightly corrected the work: before, hunters almost never brought units to respawn. They just didn’t reach.



The last two days
there is no work plan. I do everything that comes into my head. Everything that catches your eye. All that I want to fix. There is no video of the result of work these days, because there are many changes and they are mostly minor. It would take 10-15 minutes to shoot to show them all on video. And everything that turned out in the end is already visible in the competitive project.

Here is an approximate list of what has been done (very minor corrections are not included):
Gamepad support is included - in general, the interface framework can control the gamepad out of the box, you don’t need to invent anything. Just added control directly by helicopter.
Fixed a bug with incorrect calculation of the slope of units in relation to the surface - the moment sometimes jumps on the video when transports are buried with their nose in the ground. This is due to the misuse of the quaternion, which describes the inclination of the surface under the unit’s wheels.
A simple calculation of the movement of units is made so that they do not enter each other - added simple collisions between units.
Fixed a bug with a crash when working with a dialog window: re-creating window elements in the handler of these same elements is a bad idea.
Added clan tags over clan units.
Shadows from the clouds - it seems to be a trifle, but a flat world ceases to be so.
Cargo scattering - cargo now not only appears on the ground near the place where it was thrown away, but also scatters beautifully from the discharge point.
The effect of teleporting goods - when selecting a cargo, it disappears not instantly, but smoothly, with the corresponding effect.
Testing and fixing bugs.

The result of the work can be found on the link in the project topic: SkyRanger .

Reviews on all competitive projects:



Link directly to the project you are reading about development (if you do not want to watch the whole review):
www.youtube.com/watch?v=0nu2QxXAYjo&t=708

Summary :
This game was made in 14 days from scratch on a framework that did not know how 3D at the time of launch.
Speaking frankly, half of the time was spent not on the game, but on how to finish the missing functionality in the framework itself.

If the development was carried out on some ready-made industrial engine (for example, on UE4, which recently became completely free ), then the project could be done in 7 days and with better quality. And this applies to almost any genre. In the modern world, a playable prototype of anygenre is going within a month of leisurely work.

Conclusions :
If suddenly you see people who offer you to enter the project enthusiastically and make Super-MEGA-Killer-Krajisiz-i-VOVKA, but at the same time they don’t have at least a minimal demo, run away from them, because these are idlers who They didn’t bother to spend a week of work and $ 200 on assets to make a prototype that implements their idea.

PS The project after the competition, it was decided to slowly modify. The project is completely open to participation - anyone can come and do something of their own. Also, with the release of UE4, it was decided to transfer everything already done to UE4 and focus specifically on developing the game, not the engine for it. If the community is interested, I will write an article on how the transition to UE4 was made and what difficulties I had to deal with.

UPD:
Habroeffect killed me dropbox and blocked external links. All files will be transferred to your hosting in the coming hours, while all this is not available. This will be fixed soon. I apologize for the inconvenience.
The links are live again.

UPD2:
It turned out that some readers perceived this article as “Oh, yes, games can be made in a couple of weeks!” Why have you been picking there for three years, lazy people ??? ”.
This is not what I was talking about.
Unfortunately, the rule “20% of the work takes 80% of the time” has not gone away.
In a very short time you can make a prototype that will be playable and will reflect your ideas.
But this is still very, very far from the game. Development speed drops with each new chip.
The first days of development are explosive:
Here we have nothing. In a day we have a landscape. The difference between “nothing” and “landscape on the screen” is huge. But only half a day of work!
Now add the trees here. No seriously. The most common trees. Well, a small forest.
"That is, as? To make a landscape is 5 hours of work, and a forest on a landscape is a month ???? ”. And like this. When implementing the forest, we have a number of questions, starting with optimization (it won’t work to draw the forest. Just run into a lack of productivity. That means we need optimizations - a lot and often non-trivial) and ending with visual artifacts (suddenly deffered shading does not want to work normally by blending, and optimized foliage is only done by blending). Not to mention the search for a path that did not take into account the existence of separate small objects that AI should go around.

Developing a normal and high-quality game is a difficult, long and painstaking work. Most of which is not visible at all from the outside.
I talked about how you can create a demonstration of your idea in a short time, but not a finished product.