How to write a game in 1 day or Another snotty post-half manual on how to quickly learn C #

We thought with a friend (and part-time classmate) to write a term paper "Tanchiki" (the most common, 2D). However, not so ordinary, but tanks in the maze. In general, everything was conceived as a grandiose and improved clone of a flash toy of the same name.

And don’t have to fuck, the game can be written in one day really. Well, maybe you will not make candy out of it, maybe there will be a bunch of bugs in it ... But if you need to show the prototype of the project tomorrow, clave in hand - and go!

Initially, the plan was something like this (everything is written in C #, WindowsForms, graphics - GDI +, server - WCF):

  1. Deal with the algorithm for generating the maze (or, more precisely, decompile the aforementioned flash drive and slam the code from there);
  2. Draw the whole thing + one (for now - your) tank;
  3. Make the tank move (the same as in the original game);
  4. Attach a WCF service that will distribute a maze to clients;
  5. Add a second tank to the service and synchronization of movements between players;
  6. Add projectile flight;
  7. Fasten the database, finish the schedule, transfer the project from Windows Forms to WPF.


As you can see, the plan is very detailed, but still not enough to say that this is a clear guide to action. Although you can live. Looking ahead, I’ll say that, after all, it’s impossible. We didn’t start from that ...

We had plenty of time - three weeks, but it just so happened (well, yes, well, yes, it is not necessary here ...) that we sat down to do it 4 days before the change. Why is the post called "How to write a game in 1 day"? Because in fact we wrote it one day.

Maze

Difficulties began almost immediately - but how to generate a maze? The labyrinth is not easy, Eller's as is algorithm is not suitable here. This is not an “ideal” maze; it has many paths around one obstacle and may contain closed areas.

Decompiling the original game yielded nothing, because the code was not readable. Rather, it is readable, but either the creator tried, guessing that there were craftsmen like us, or the decompiler got the crooked code ... But I didn’t have any desire to understand the million variables with the names _loc2, _loc4, _loc6 and the like, and besides time was running out. I had to think for myself.

After several hours of thought and a lot of tea, the word “recursion” flashed through my head - and the algorithm was invented. In the code, the maze was represented by a two-dimensional array of MazeCell structures, which, in turn, had two fields - the lower border of the cell and the upper border (both fields are simple bools, initially set to true). Maybe I’ll post the code a little later, but for now I’ll explain the essence: you don’t need to build the maze, but break it. Those. First, we determine the number of cells (rooms) in the maze and set all the obstacles for them (both fields are true). Then we determine two cells where our tanks are. A prerequisite is the direct access of one tank to another. There may be enclosed areas on the map, but tanks must either be outside of them, or both inside that area. Therefore, recursion comes into play - we take the cell of the right tank and go to the left, passing the next cell as a parameter. When we get to the tank, we go back along the same route, but already destroying the necessary walls in those cells through which we pass.

And finally, the final stage - just run through the maze (recall, this is an ordinary two-dimensional array) and break random walls in random cells. Everything, the labyrinth is ready, you just need to draw it, sheer trifles! The algorithm was implemented after a couple of days. That is why we wrote the game 1 day.

Traffic

There were no special difficulties with drawing, so there is simply nothing to write about. That's the thing - the movement ... Making the tank move diagonally was not so simple. Frankly, we did not have time to do this. Rather, he moves diagonally, but HOW he does this is better not to see. Plus, when changing directions, the tank freezes for half a second in place and only then moves where necessary. We did not have time and tools to test the theory, but I think this is because we handled the button presses on the event of the KeyDown form , although we would have to catch them by timer.

WCF service, second tank and synchronization of movements between players

This is where the problems began. As we understood later, it was necessary to start work from this point, and already under it to adjust the maze, customers and everything else, and that's why. The main problem is a two-dimensional array. WCF does not work with two-dimensional arrays . We had to pretty pervert to remake this miracle in List. Well, if we decided to change the architecture, it would be easier to make a regular array. It took a long time to find the error, but even more to fix it.

To rewrite almost the entire labyrinth class was neither time nor power, so we just made a small wrapper, which, where necessary, expanded the list into an array, and after all, collapsed it back into the list. But that's not all - WCF is full of pitfalls that we stumbled upon while working. If there is no practice, you will certainly find them. This includes streams on the service side, and a bunch of different parameters for the contract, and the transfer of custom classes to the client (Attention! I remind those who forget that there cannot be methods in such classes, this is only a data contract!). In general, it was fun.

Now about the coordinates. We decided (and did it right) to transfer not the entire maze from client to client, but only variable characteristics - the coordinates of the tanks. The tank left, the coordinates have changed - we are sending a new position to the opponent, and his client will redraw everything. They also planned to do with shells.

Completion: Database, Graphics, WPF

We sat at the game all day and almost all night - I went to bed at 3:30 in the morning, because already almost buried his nose in the keyboard and did not think anything. My friend sat for another hour and also went to sleep. Protection assigned at 9 am. By 3:30 we almost had a client and a server. We did not manage to add the base, normal graphics and WPF. Did we turn in the project? Not. We stumbled too much in the service, because We do not have much practice in this area, I had to experiment a lot, which ate a lot of time. But now we are almost specialists in WCF.

For the term paper, they put us in the top three, saying that the idea is very cool, but the implementation is lame (and we don’t deny it). But is it realistic to hand over such a project in 1 day? Yes, more than. The main thing is faith in oneself, no matter how trite it may sound. And the desire to create. During our work, we made “extremely improbable” three times and “impossible” two times. To the "impossible" can be attributed the game itself. Yes, we have been coding for about two years (in the sense of learning), but this is the first project of this magnitude. When we arrived, we did not understand how to write a game. Rather, we understood something, but for us at that time it was impossible. But if you try and believe in yourself, even the impossible will become real. It just might take a little longer. The transfer of a two-dimensional array from a WCF service to a client can also be attributed to the same “impossible”. Yes, it cannot be done directly, but you can always get out somehow. And about “learn C # in a day” ... Well, you certainly won’t learn to learn, but in extreme conditions, quickly get to the bottom of the problem and gain experience.

During the day we did a tremendous amount of work and, moreover, this is an occasion for my little pride. Nevertheless, we made a prototype of the game, and did it in 1 day. If we had more practical skills, we would have managed to fasten even a normal base. Negative experience is also experience, now we have the skills of planning, system design and a lot of knowledge on WCF services.

So good luck, the main thing is to try and not be afraid!

Also popular now: