As I alone made the game and conclusions

The history of the development of one fan computer game Fallout: The X-Project and attempts to make it a "candy"

I will warn you right away that you will not see in this article any current and up-to-date knowledge, and in general I will not pay much attention to technical aspects in it.

Let me explain why: the game itself was developed from 1998 to 2008, and most actively - somewhere from 2004 to 2007. To be honest, even in 2005 I understood that there was no future for the game. But I just wanted to finish it. Otherwise, why so much time and effort spent on the project? Besides, I was not alone, and we should not allow other people's efforts to be wasted. A responsibility.

But let's not move aside. Who will be useful article? First of all, the same guys as I was myself, while studying at the institute. Dreamers who want to create their own dream game.
')

Let's start blessing

Although no, this game was not the very "dream", of course. But at the time of the decision on its development, I thought that I could quickly finish the project (aha-aha!) And get the attention of people like me. "Hope boys feed ..."

Of course, I played Fallout. The one from the Black Isle and Interplay, now remaining only in the annals of history. Two-dimensional, isometric. With disgusting Russian translation. But it was a blast. Roof cutting.

Therefore, when choosing a project, I decided to use this particular topic. The second Fallout is already out, but about the 3rd one, no one even stuttered (at the time of the idea). The toy was supposed to be fan-based, designed only for Russian-speaking players, and did not assume profit. Only experience. Whom I share here.

By the way, Fallout Tactics later came out, from which quite a few graphics were borrowed for the game. And sounds. However, everything from both the original Fallouts.

Why text quest? Again, because the graphics are required to a minimum. There were no artists, no freelance exchanges yet existed (and, I suspect, I would have invested), and only one 3D modeler was found on gamedev.ru by some miracle. He made a short intro at the start of a new game. For which a special thank you to him!

And so, I designated some background of the game creation. Let's go further!

Choice of language and platform

At the time I started learning GameDev, the standard in it was C ++. And for C ++ IDE - MS Visual Studio. I began to study and use it. To work with graphics and media - MS DirectX, and its parts DirectDraw and DirectSound. With 3D, I didn’t ask from the very beginning, and in this project it was completely out of place.

But DirectX itself is not so convenient, because I found the NukeDX library, which made working with DX much more convenient (read this as libGDX is now for Java). True, NukeDX already at the time of the start of work with him ordered to live long. But all I wanted was already in it and it worked.

The fact that the game will be for the desktop PC on Windows - at that time was not in doubt. Laptops were much more expensive than PCs, and tablets could only be read in abstruse reviews. Android and smartphones were only in the bud, in the secret lab basements. And Linux was perceived solely as a console server solution.

Although I will not hide, in the year so in 2010 there appeared a little thought “what if this whole thing is stuffed under Windows Pocket”? With the name of the operating system, I can lie, but the essence is clear, I think.

The idea as it appeared, and disappeared - would have to rewrite the entire code and redo the graphics.

And let's say a word about scripts

Since I was making a text-based Role-Playing Game, which initially implies non-linearity of passing (oh, it was a fashionable thing then!), Then I had to somehow lay down the possibility of manipulating game data without recompiling the project every time. On the whole, it was extremely interesting to try to fasten the script engine to the game itself.

The script engine had to solve the following tasks:

• interaction with game variables (acquisition / modification) and functions;
• do not require pre-compiling code;
• Do not load the game.

Of all satisfying these requirements, the choice fell on Lua. Why specifically he - now I do not remember. The language was definitely used in large projects. Yes, and now it is used (as far as I know, in the same WoW, for example).

The library is free, examples were. And I screwed Lua.

We gather air into the lungs and hold our breath before jumping.

Everything is great, with the platform and the tools I decided. Now we need to think about how to turn an idea into something tangible.

Since at that time I had already done some simple little programs with the help of Microsoft Foundation Classes, with their help I decided to write a script editor for the game.

Considering that the game consists of a sequence of scenes (in our case described by the text), and the transition to the next scene depends on the choice of the answer option, I created the following scenario structure:



As can be seen in the screenshot, in the scene there is, in addition to the description text and choices, also a lot of other data. For example, the current date (by game time). And looking at it now, I already see what needs to be fixed.

In addition to time, we still display a picture of the scene. In the editor, it is given by a number. And the game is displayed in the upper left corner. And the sprite, you guessed it, corresponds to this number.

There is also a scene name (Location). Playable music file for the scene. And options for action with links to the corresponding scene.

And here we will talk a little about interactivity. I think attentive readers have noticed an Event field in which something is written. That's right, this is a script that runs when you go to this screen. On the first screen, this is just adding new tasks to the player’s log:

AddQuest(1, "  , ,   "); AddQuest(1, " "); 

From the point of view of the program, we call in Lua the functions of the application available to it with the parameters we need.

And now two more points:

1) Each answer has a Condition field. Through the same Lua, we can check some game variables, and based on this check, we can either display the answer variant or hide it.
2) Each answer option can have its own executable script. That is, if we choose some option, then it may entail a certain action. For example, call the battle screen. Or playing a sound. Or go to a specific screen, if the condition is met. Etc.

It was in such simple ways that I solved the question of interactivity and user interaction with the game world.

And everything is stored in the file scenario.dat, in the data structure. It is saved to disk using the same MFC serialization mechanism. Well, for fun, during the save is encoded.

We dive

Well, not very convenient, but at least somehow I did a working script editor. Now it's time to start the game.

And here ... Yes, as if not so! There was a lot of chore in Photoshop with vyteplennaya graphics. But from the point of view of programming, there was nothing particularly complicated. At first sight.

I will not dive into unnecessary details, but the first serious task that arose before me is artificial intelligence. If for logical tasks everything could be put into scripts, then with the boev I decided to bury everything hard in the code. And it was an interesting, but time-consuming moment in the development of the game.



Of course, the great random rule here. But it was necessary to do at least some semblance of the meaningfulness of the struggle on the part of the computer. But in itself, the model of the battle was borrowed from the once extremely popular "Fight Club", or simply BK. And adapted to Fallout. Choose where to hit, strike and get a similar answer.

But it is fine. And for the passage of some tasks (quests) requires inventory. And here I was really stuck for a month or two.



No, the inventory itself is not a complicated thing. Quite the contrary. I was stuck on writing drug & drop for him. True, now I remember only that he caused a lot of indecent words!



When I overcame a problem with dragging and dropping objects, only small details remained, such as viewing holodisks, displaying a task log, etc. little things.

We must check the bottom so as not to meet with the stone

But ... it was already 2008. Came out and passed with a sell-out Fallout 3 - a kind of The Elder Scrolls in the world of Wasteland. The generation of gamers has changed a long time ago, and those for whom the Fallout: The X-Project text quest was intended have either stopped playing completely or have lost all interest in games of this kind.

But I have no regrets about the experience, because I have proved the following things for myself, and for everyone else:

1. You can write a program without initially possessing any knowledge of programming, and without studying in this specialty anywhere.
2. Even alone you can create a computer game for which you will not be ashamed (hello to GameMaker and others like it).
3. Developing games, you get a lot of fun!

And from my own experience I found out that:

1. The project must be deadline !
2. Before you start doing something, you need to carefully study whether it will be necessary for someone other than yourself. Banality, but it is a rake, on which all continue and continue to attack.
3. The version control system is just a super thing!
4. OOP is even cooler than the version control system.
5. Few people love reading large texts.
6. But if you have to read texts, then you need to make reading CONVENIENT ! In my case, style won convenience, which turned out to be a big mistake.
7. It is necessary to think over distribution channels still BEFORE beginning to work on the project.
8. Find companions who will not only talk about the language, but also to do something quite real. But not easy.
9. Combining several positions of a team in one person is not productive. Constant switching between tasks negatively affects the speed of work.
10. Creating a game as part of a ready-made setting (universe) is easier than doing with 0.
11. At the design stage, it is already worth removing the excess. It will not enter the final release anyway, but time will be eaten. For example, in the game there is no movement between cities (world map), although initially it was assumed.
12. A computer game is a fusion of various ingredients. Therefore, either all specialists are needed here, or you should be able to do it all yourself.
13. Sooner or later, persistence is rewarded. But so that it is not late, see item 1

And this magical moment, when your game is compiled without errors, is launched, and everything is in it exactly as you intended. This is the magic for which it is worth wasting your efforts!

Hostess note

I will not give the list of references, since it is no longer relevant for a long time.

→ But you can dig into the source code, if you wish, on GitHub
→ The game itself , if curious