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!". At the same time, there is no adequate demo even in the near future. Looking at all this, I want to say: “What the hell are you doing ?!”. But it is destructive. It is not enough to criticize. Need and positive examples to provide.

These thoughts prompted me to an amusing experiment: in November, a game contest started for gamedev.ru . The competition involved the development within two months. However, it seemed to me that this is a bit too much. So I signed up for the participants ... And I forgot about the competition 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 competition 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: competition, project from scratch, two weeks.
')


If you do not want to spend time on the whole article - you can squander down. There is a review of competitive projects and a brief conclusion from the whole experiment.

We have two weeks. The main question is what to do. To be honest, I initially thought that the competition was going on until January 7 and planned to spend only one week on it.

One week is not very much, in connection with which the launcher genre was chosen.

A launcher is a game, all of which takes place on one level only. 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 it gives points that can be spent on pumping a character so that he can fly better. The game ends at that moment when the character is pumped enough to reach the end of the level.

An excellent 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! With this you can already work! We will do 3D Action!

We take several of my favorite games as a basis: Wangers, Mechanoids, Ex Machine, Renegade Ops. I want to make an RPG, but in such a short time to work out pumping will not work. Therefore, the goal: as a basis we take the gameplay RenegadeOps / Wangers, a set of quests - by analogy with Ex Machine / Mechanoids. Well, so as not to waste time thinking about the universe, let the game be in the Mechanoids universe. Especially since my actual place of residence is 7 km from the former office of SKYRIVER studios has such borrowings.

The first day
What we have? The framework, which released several 2D games. Of the 3D capabilities, only loading a mesh from a file. There is also a landscape editor. Use it to create a game landscape. Task for the first day:

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

For this we need a 3D camera. It should be able to establish the species matrix and the projection matrix. The camera class did not even have to write, over the years of development I have already done it. Just drag the camera into the framework.

The next subtask is to transfer the shaders from the editor to the game. Shaders are in the clear, all you need to do is remove the editor's tools from them: highlighting the edge of the tiles, dynamic calculation of the normals and other trifles.
The main subtask, which took 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 it took half a day.

The result of the work:



And what do we see as a result? The landscape is terribly noisy. The reason is very simple - when converting 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.

Second day
For today two tasks are planned:

• Shadow cards.
• Rendering models (without models, do not really test the operation of shadows).

First of all, I include MipMaps, which I did not include yesterday, and it turns out that something in the code generates an OpenGL error. There are not so many checks in the code and the error gets out when loading shaders. I sin on crookedly transferred shaders from the editor ... I spent an hour to understand that the error was not in the shaders ... It turns out that I had incorrectly specified the texture settings and the value of GL_LINEAR_MIPMAP_LINEAR was gone in MAG_FILTER, which should not be there. I am fixing on GL_LINEAR and everything starts up without problems. Meanwhile, it took two hours ... This is very much, considering that there are only 12 days.

Now let's do the models. In general, I already have a loader of simple models. But it is 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 frustum of the camera. The easiest way to organize this in our case is to split 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, which splits the game space into squares in accordance with the landscape settings and, when drawing, processes only those objects that are no more than one square away from the camera. 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 in case the object has moved beyond the limits of 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 a shadow map. But for shadow maps you need Render To Texture support in the framework, which I didn’t have, because previously implemented projects did not require post effects, and RTT in 2D, except for post effects, is not used anywhere.

Another hour we spend on the implementation of the wrapper over the FBO. Nothing too complicated.

We start the last task of the second day - Shadow Maps. All anything, but I am an adherent of Stencil Shadows ... With all my strength I have always avoided touching Shadow Maps. Well, they did not like me. But time goes on ... in modern realities there is no single reason to use stencil shadows. Their performance drops too much with increasing complexity of the geometry and screen resolutions. So there is no alternative - you have to take up the implementation of shadow maps. Of course, I am very familiar with the theory of the work of shadow maps, although I have never implemented them. Therefore, I do not expect any particular difficulties. I took the manual long overdue for a rainy day and implemented shadow rendering on it.

By the way, I used this manual . I recommend to everyone. Competently and on business everything is painted, including the main problems getting out at realization of maps of shadows.



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

Third day
We continue to fasten the functionality we need. For today two tasks are planned.

• Integration of 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 a new compiler.
• Integration of a particle system. I planned to use Magic Particles from Astralax.

Let's start with LuaJIT. We download source codes and easily collect dll under Windows. We write a small wrapper class (I don't like luabind and analogs, I prefer to work with lua through a minimum of layers). And, in fact, everything.

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

The second part of the plan for today is the integration of a particle system. I worked with Astralax Magic Particles system of particles a lot and productively, because 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 for the competition, 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 missing as a class. But for me it 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 over for lunch. I decided to make the start menu. He made a simple landscape, put a couple of buildings and two helicopters on it. And got a bug with shadow maps. It can be clearly seen on the KDPV on the corner wall to the left under the Exit button. However, I decided not to correct this bug - the view in the game is not the same, and these bugs are practically invisible on it. And editing the aliasing of shadows promises to kill several precious hours.

Made the menu, interestingly driving up / down. It turned out fun. I added the “Setup” and “Continue” buttons, although I understand perfectly well that I most likely will not be able to implement their functionality in the framework of the competition - I don’t have enough time.

It may feel like I wasted my time on unnecessary garbage - animating menus. But it didn’t take too long, as the framework can do animations for the UI. It took only ten minutes to indicate what and when to animate. But with the animation menu has become much more interesting.



Day four
Plan for today:

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

Only at 16 o'clock in the afternoon I was engaged in tasks directly from the plan. Before that, I solved any tasks that have no direct relation to the plan, but the implementation of the plan could not be started until they were completed. 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 units can be controlled ...

Further more. I made control of the helicopter and it turned out that when I clicked on the button and moved the mouse, Qt began to slow down like hell.

I, like any intelligent programmer, sinned on myself ... I rewrote the internal message processing system. Made a check for duplicate messages ... And it did not help.

Well, I abandoned the usual message system and read the state of the keyboard and mouse ... And it did not help.

I completely disabled the input system in my engine ... And still got the friezes. Made a WH_GETMESSAGE hook on all messages related to input, with interception and cancellation of all messages ... This did not help. Nothing left but to explore the system outside of my development environment.

The solution turned out to be simple ... I spent three hours correcting a bug that I don’t have ... It slowed down Synergy if I clamped several buttons at the same time. I removed Synergy and everything became smooth and neat.

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

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



Fifth day
The task for today is to make a game location.
I have ten buildings that were bought on 3drt.com for another project. First, I roughly painted the plot of the game, then made a list of buildings and figured out which building could play a role in the game. What looks like a mine, what looks like a main base, etc.
In the landscape editor roughly sketched the playing area:



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

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

The next stage is the imposition of heterogeneity of the landscape and the laying of roads. Since Very little time - allocated for all three hours. This time was only enough to create a minimally playable landscape. For some artistic delights there is no time left.

The next task is the placement of objects and the task of cross-country areas. I do not have a suitable 3D editor for the framework, because 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 complex save format. Yes, and he wrote for a completely different engine, so use it directly will not work. However, today it does not matter. Create a location in this editor.
In the editor, I arranged the objects and drew zones:

• Roads
• Passable off-road areas
• Flight Zones
• Safe zones (located near buildings, within such zones you cannot shoot).

Moments on the video, when the whole landscape is painted in red and green - this is, in fact, editing zones.

Sixth day
Plan:

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

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


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

Next we need to load the zones and objects. Scenery 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 way.

In general, the envelope and loading location took a fairly small part of the day. Most of the time it took to implement the functionality of the turret. They work simply: if a player has shot in a safe zone, then a timer is activated for 15 seconds, during which all the turrets, within the radius of damage of which the player is, open fire on him.



Seventh day

• It's time to implement artificial intelligence.

I already have an artificial intelligence that can perform various functions.
It was done several years ago, when there was an idea to implement an AI contest. The 2D model of the world of mechanoids with their rules was actually implemented. Traders received points for the delivery of goods, guards for escorting traders, hunters for bringing heads, marauders for stolen (not purchased) and sold goods.
How this AI worked you can see here:



Circles are live units.
Red letters are dead units.
Black crosses are a load.
Two teams - green and red. They are actively trying to depict the living world.

AI in the forehead can not be transferred. The fact is that in the world of mechanoids, a unit is something hovering and shooting in front of it. 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 attendant problems.

All day was spent on 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 on the seventh day was the ability to create units using text files (an editor for these cases was already created out of the competition).

The configuration of an ordinary unit looks like this:


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

Eighth day

• We continue to cut AI.

Units have 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 screw. The hour of the night ... Due to the backlog of deadlines on the seventh of January, he categorically got out of the plan. So detour of the obstacles - into the firebox ... To the same firebox and physical interaction between the units ... And the suspension of the technology is also there ... Especially sad is the last. Without calculating the suspension units rigidly repeat the landscape and it looks like it is not ice. But they perform their functionality, so leave it like this.



Day nine
The game planned four types of AI:
Merchants - buy goods and sell in another building.
Guards - follow the traders and attack the enemy, if they see.
Hunters - plying the map and attacking opponents, periodically taking the heads of dead enemies and friends to the base.
Looters - plying on the map and attacking primarily merchants, periodically taking the selected goods to the base.
Made three types of AI. Marauders did not, because there are no goods. Rather, there are goods. Merchants buy them and sell. But I decided not to dump the cargo onto the location in case of the death of the unit. Accordingly, marauders who were supposed to collect cargoes near corpses do not make sense. As a result, made AI dealers, guards and hunters. Fixed a couple of bugs. Made the attitude of the clans to the player changing - depending on the actions of the player.

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



Tenth day
The final is coming.

There is an understanding that you need to finalize the picture. As can be seen from the result of the previous day, the battles look normal ... until somebody dies. Units just disappear, which looks bad. There are two options. Or make the disintegration of units into separate parts. This task is rather complicated, and not so much from the point of view of programming, but rather from the point of view of the routine work of cutting units into pieces and exporting them into a digestible format. A separate moment - I really do not want to spend time adding animations to the engine. The second option is a particle system. But Magic Particles can not wince. Integrate it for use on other platforms? But I really want to avoid solutions in a cross-platform framework that cannot work everywhere ...

As a result, I settled on the following solution: use Magic Particles, but at the same time completely abandon its native API.

In practice, this was implemented as follows: a converter was implemented that lost the 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 in time, but not attached 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 whole range of MP capabilities, but it does quite well with explosions and other simple and non-looped effects. And this is what I need.



The explosion somehow turned whitish, but I decided not to waste time on the proceedings. Looks at C grade, but time is very little. In fact - one and a half days: the eleventh day and the night of the twelfth (the contest ends on the 12th at 9 am).

Eleventh day
All the remaining time decided to spend on quests. Of course, there is already some kind of gameplay in the game. But the quests will give meaning and, perhaps, will 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 dialogue window for communicating with the NPC (we have their role played by the building). The principle of operation of such a window is almost identical to the quest dialog box in Space Rangers. I think it’s quite realistic 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-card, because then the limitations of the world immediately become apparent. But you want to create the impression that the world is alive and big. But just to leave the player can not wander. Of course, there are players who will be interested. But most of them get lost at the first crossroads 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 on the starting base, you can separately add a label to any building.

The video shows the process of performing one of the tasks entirely. The speed of the helicopter is increased so as not to delay the video.



Surprise!
Completed quests. It is possible to complete the game completely. Late night of the eleventh day. I used the topic of the competition to once again clarify the terms and determine the plan for the night ... And it turned out that a couple of days ago, the majority of participants voted to extend the competition for another two weeks!



It goes against my plans. Yes, and violates the idea to make a project in a short time.

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

Twelfth day
Polished and rescheduled all quests. Made a respawn player effect. At the point where the player was at the time of death, the effect of teleportation is created, the effect is also created at the respawn point. Slightly improved the search for the path, so that the units rarely stumble upon obstacles. But they still stumble with some probability.

Added a few more types of units. Rather than the types - units actually remained the same. But before all the roles (hunter, marauder) for all clans were performed by units that looked the same. And I made sure that each unit of each clan looked unique.

Slightly corrected the work of AI: before, hunters almost never brought units to respawn. Just did not reach.



Last two days
There is no work plan. I do everything that comes into my head. All that catches the eye. Anything I want to fix. Video of the result of the work these days is not, because There are many changes and they are mostly small. It would take 10-15 minutes to shoot to show them all on video. And everything that happened in the end and so it is visible in the competition project.

Here is a sample list of what was done (minor fixes are not included):
Support for the gamepad is included - in general, the interface framework is able to play a gamepad out of the box, you do not need to invent anything. Just added control directly to the helicopter.
Fixed a bug with incorrect calculation of the inclination of units in relation to the surface - sometimes a moment when transports with a strange nose are buried in the ground on the video. This is due to the incorrect use of a quaternion describing the inclination of the surface under the wheels of the unit.
Made a simple calculation of the movement of units, so that they do not enter each other - added simple collisions between units.
Fixed a crash bug when working with a dialog box: re-creating window elements in the handler of these same elements is a bad idea.
Added clan labels over clan units.
Shadows from the clouds - it seems to be a trifle, and the flat world ceases to be so.
The spread of the load - the load now does not just appear on the ground near the place where it was thrown away, but beautifully scatters from the point of discharge.
The effect of teleportation of goods - when picking up cargo, it disappears not instantly, but smoothly, with a corresponding effect.
Testing and fixing bugs.

The result of the work can be viewed at the link in the project theme: SkyRanger .

Reviews on all competition projects:



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

Outcome :
This game was made 14 days from scratch on the framework, which did not know how 3D at the time of launch.
Frankly speaking, half the time was spent not on the game, but on completing the missing functionality in the framework itself.

- (, UE4, ), 7 . . .

Conclusions :
, -----, — , , 200$ , , .

PS . — - . UE4 UE4 , . , , UE4 .

UPD:
. , . . .
.

UPD2:
, «, ! , ???».
, .
, «20% 80% » .
, .
. .
The first days of development are explosive:
Here we have nothing. A day later we have a landscape. The difference between “nothing” and “landscape on the screen” is huge. But after all, half a day of work!
Now add trees here. No seriously. The most common trees. Well, the wood is small.
"That is, as? Make the landscape - 5 hours of work, and the forest on the landscape - a month ???? ». That's how. , ( . . , — ) ( deffered shading , ). , , .

— , . .
, , .