Rust game development. My history

Hi Habr! I am developing a game on Rust. This time I want to show some gifs and show the whole history of the game from idea to page to the incentive.



Why rast can be read at the beginning of the last post. But why such a strange gameplay? I hate football and everything connected with it!



The idea was simple - I read the article and noticed that there is only one game using synchronous network physics as the basis of the gameplay.

')

To realize the idea of ​​such physics, we need animations and a bit of logic. At least that's what I thought.



If we need animations, we have to do it! And I started with the implementation of skeletal animation on the CPU.



As a data format, I took smd - Valve will not advise the bad! Really very simple and convenient format. The specification, unlike even the .obj, is extremely simple, besides supporting bones and skinning. What you need!





Here it is - for the first time something is moving on the screen. A few days ago, this gif was exactly one year old!





I add skinning and lighting - and that's it, the game, you can say, is ready! It seems that I somehow thought so.





Once the animations are ready, you need to somehow organize the code and write the game logic. After all, to draw not one, but as many as four characters, you need some kind of game entities!



I turn to the book about patterns , I do not find an answer there. The answer is, at that time, just beginning, amethyst . This thread is very interesting and constructively discussed ECS - I recommend, there are many interesting links! But at that time specs have not yet done. Therefore, I write my bicycle . It allows you to display four people walking. Already very close to the game!





More men! I watch how fast the skinning works on the CPU. It seems to be applicable. Leave so.





The next problem - you need to somehow edit the scene! I am writing the first exporter from blender. It is extremely simple - all modelki will export to the familiar .smd, and describes the scene as a simple text file. Simple - but it works!





A game about physics, integrating nphysics .





Simple direct lighting was not enough, I realize in deferred lighting. Essentially just adapting an example from glium. But it works, it's beautiful!





Probably, such graphics could come in as a Directx6 demo, success can already be said!





And then the gameplay idea was born - to make a CTF shooter in collapsing scenery. Khm Yes, the video is exactly that!



At the moment when the game reached a state on the video, there was a turning point in the whole story - with my graphics I was able to impress a real modeler, and now we worked on the game together!



The concept of the game was born - we decided to test technology, engine, network and release the first game with the simplest mechanics - the one that already exists. That is - CTF and physics synchronization. And after we make a complete game that people can play, start using physics synchronization on a larger scale and make a more sophisticated project.



The plan was simple, and therefore beautiful - it's time to finish the owl.





The first network version. It's already quite exciting to play, I realized somewhere here that it all really works! The game has animations, you can play it together - what else do you need?





Began to increase the location. It turned out that the finish was slightly further than planned - with an increase in the number of objects from ~ 20 to ~ thousand, a whole bunch of problems appeared that need to be solved. We had to do more multithreading - the longest processes - physics and animation left in separate streams. Since everything is moving, you cannot make static geometry batting. We noticed that we have a lot of identical cubes - and began to deduce them by instaging. FPS returned to normal, the game continued to play on the big map.





Now we are also a 2D specialist! At the same time I had to invent a way to display gui. Before that, all the gui were on dies with text, or on imgui . Neither is suitable for beautiful windows. I have compiled a long list of all existing gui approaches in all engines - and I chose the most, in my opinion, convenient and simple - web gui. I made a small wrapper over the avsium , I learned how to draw a WebView on top of the screen, on dies - in general everywhere. It turned out conveniently!





That's actually the web dab over the character.





With gui, the productive (rather) engine and network, the game already began to look like a game (in my opinion). At this point, we tried to prove it to someone else and find money for development. For some reason, no one believes that the video game of 2016. We do not despair and continue.



But this video was an important moment in our history. After it was decided to change the style to a lighter one. And it was decided to spend the time, enough to remove all the inconvenient things associated with our engine. The first one is animation. We did not have the concept of "graph animations", and the skinning on the CPU also took away a lot of performance. I studied the old abandoned rast project . In it, I didn’t like the logic of the graph, but in general it worked perfectly, gpu skinning worked quickly!



Then the story will be more confused - the work has become more, and the results have become less noticeable.





I redid the logic of the graph and wrote the editor of the animation graph. Now you can set up animated events right in the blender, include them on the graph and all that - life has become much better.





Testing performance. I did not compare it with other people's decisions, but for us - speed is now more than enough!







The next problematic thing was - it was inconvenient to change materials and it was inconvenient to look at colliders. They made the very first editor - right in the game, you can click a button, switch the camera to free mode and poke it with objects with the mouse - see colliders, change the shader and all that. At the same time we made the material system itself - now the materials are configured in the blender exactly as materials.





The editor was developing - as a result, a system of "patches" appeared. You can form a “patch” on the blender scene right in the game and apply it in a blender. This is mainly used for particle lamps and - so far there is not even a turn. But it became much more convenient!





For such a historical note, this screenshot is too fresh :) But we started the particle editor just after the first public video. It had lasers shooting with a very funny sound - and without an editor it was too inconvenient to redo them. For the sake of this editor, another programmer joined us - and now we have a real team of 4 people! Since then, we have made a large and fairly functional editor of particles - now the shots will be much more interesting.





This jerky video - the first entry of a real network game with a full cycle mechanic - you can go into battle and even win it!





A little more about gui. Web gui fully justified itself. But awesomium is not ideal. It is not very fast (up to 20% of the frame is spent on it) and there are many unpleasant restrictions. I really want to use servo as a gui engine and I hope some day we will do it.







Now we are working on the possibilities to use the destruction of the environment as an important part of the gameplay, our next goal is a playable demo. We hope to launch the closed and then open series of alpha-beta tests soon. Stay tuned!