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 fellow student) to write a term paper "Tanchiki" (the most common, 2D). However, not so ordinary, and the tanks in the labyrinth. In general, everything was conceived as a grandiose and improved clone of a flush toy of the same name.

And do not fukat, it's real to write a game in one day. Well, maybe, you will not make a candy out of it, maybe there will be a lot of bugs in it ... But if you need to show the prototype of the project tomorrow, put it in your hands - and go!

Initially, the plan was approximately as follows (everything is written in C #, Windows Forms, graphics - GDI +, server - WCF):
')

1. Understand the labyrinth generation algorithm (or, more precisely, decompile the aforementioned flash and slice the code from there);
2. Draw the whole thing + one (for now - your) tank;
3. Make the tank move (and just like in the original game);
4. Attach a WCF service that will distribute a labyrinth to customers;
5. Add to service a second tank and synchronize movements between players;
6. Add the flight of the projectile;
7. To fasten a database, to finish the graphics, to 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 to say that, after all, it is impossible. We started not with 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 delivery. Why is the post called “How to write a game in 1 day”? Because in fact we wrote it one day.

Labyrinth

The difficulties began almost immediately - and how to generate a maze? The labyrinth is not simple, the algorithm of Eller as is not suitable here. This is not a “perfect” labyrinth, it has many tracks around a single obstacle and may contain closed areas.

The decompilation of the original game gave nothing, because the code was not readable. Rather, 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 similar time was running out. I had to think for myself.

After a few hours of thinking and a lot of tea, the word “recursion” flashed in my head - and the algorithm was invented. In the code, the labyrinth 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 bool, initially set to true). Perhaps, I will lay out the code a little later, but for now I will explain the essence: you don't need to build a maze, but break it. Those. First, we determine the number of cells (rooms) in the maze and set them all the obstacles (both fields are true). Then we define 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 must be inside such areas. Therefore, a recursion comes into play here - take the cell of the right tank and go to the left one, passing the next cell as a parameter. When we reach the tank - we go back the same route, but already destroying the necessary walls in those cells through which we pass.

And finally, the final stage - we simply run through the maze (remember, this is a regular two-dimensional array) and break random walls in random cells. That's it, the maze is ready, you just have to draw it, these are small things! The algorithm was implemented after a couple of days. That is why we wrote the game for 1 day.

Motion

There was no particular difficulty in drawing, so there was simply nothing to write about. Whether that's the case - movement ... Making the tank move diagonally was not so easy. Frankly, we did not have time to do it. Rather, it moves diagonally, but HOW he does it, it’s better not to see. Plus, when changing direction, the tank freezes for half a second on the spot and only then moves to the right place. We didn’t have the time and tools to test the theory, but I think it’s because we were processing keystrokes on the KeyDown event , although we would have to catch them by timer.

WCF service, second tank and synchronization of movements between players

This is where the problems started. As we understood later, it was necessary to begin the work from this point, and it was up to him to adjust the labyrinth, customers and everything else, and why. The main problem is a two-dimensional array. WCF does not work with two-dimensional arrays . We had to be pretty perverted to redo this miracle in List <MazeCell []>. Well, if we decided to change the architecture, it would be easier to make a regular array. It took a lot of time to find the error, but even more to fix it.

Rewriting almost the entire class of the maze had neither the strength nor the time, so we made just a small wrapper that, where necessary, expanded the list into an array, and after everything folded it back into the list. But this is 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 user classes to the client (Attention! I remind those who have forgotten - there can be no methods in such classes, this is solely a data contract!). In general, it was fun.

Now about the coordinates. We decided (and did it right) not to transfer the entire maze from the client to the client, but only the variable characteristics - the coordinates of the tanks. The tank left, the coordinates changed - we send a new position to the opponent, and his client will redraw everything himself. Just conceived to do with projectiles.

Completion: Database, Graphics, WPF

We sat at the game all day and most of the night - I went to bed at 3:30 am, because already almost nuzzled the keyboard and understood nothing. My friend sat for another hour and went to bed too. Protection is scheduled for 9 am. By 3:30 we had a client almost implemented and there was a server. The base, normal graphics and WPF did not have time to add. Have we passed the project? Not. We too stumbled on the service, because We do not have much practice in this area, we had to experiment a lot, which ate a lot of time. But now we are almost specialists in WCF.

For a term paper, we were given a top three, saying that the idea is very cool, but the implementation is lame (and we do not deny it). But is it possible to pass such a project in 1 day? Yes, more than that. The main thing is belief in yourself, no matter how trite it may sound. And the desire to create. During the work we have done three times “extremely unlikely” and two times “impossible”. By the "impossible" can be attributed to the game itself. Yes, we have been coding for about two years now (in the sense of learning), but this is the first project of such a scale. When we arrived, we didn’t understand how to write a game. Or 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. Just maybe it will 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, you can't do this directly, but you can always get out somehow. And about “learning C # in a day” ... Well, of course, you cannot learn to learn, but under extreme conditions you can quickly get into the essence of the problem and gain experience for sure.

During the day we did a tremendous amount of work and, moreover, this is a reason for my little pride. Still, 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 to you, the main thing is to try and not be afraid!