Cormania Game Dev Diary (pt. 4) – It… Lives?

By the end of this week, my game finally had a working prototype. All the systems that I felt were needed were in place. The game “AI” was completed. I was finally able to play my game and see what it was like…

… It sucks.

Picture

But more on that later. For now, let’s describe what I did. Up until this point, there were three levels of knowledge about the location of a silo: nothing at all, a very broad idea of its location, or its exact location. What I truly wanted was there to be a level of knowledge between the very broad sense and the precise location, one that the player could feasibly act upon, although not without some risk. Adding this was surprisingly easy.

Adding the missile targeting functionality was also surprisingly easy. It required toggling an attack mode, in which the player can select his silos and assign targets to them. The flag was a global variable, and those variables have always troubled me because I do not know where the best place to declare them is, since some global variables in the room creation code don’t seem to be acting how I would like them to. This problem might become irrelevant when I add a menu system; this will allow me to create and set globals in the game start well before the objects that need those variables first call on them. (The problem boils down to placing global variables where I know they will be created before they are needed; for some reason, objects call on the variables before they are created in the room creation code). But I digress. This global variable in particular was not a problem, and calling it in the room creation code suits the game well.

The most difficult task of the week was making the spies work as intended. Up until this point, spies performed their missions and always succeeded. In my game design, though, spies have a chance to succeed, to fail, to be captured and killed, or, worst of all, to be captured and rat the player out, resulting in a preemptive strike and ending the game. Adding all this and having it behave in a coherent manner was not simple. I had to create code that effectively ends the game, which at this point in time simply requires a “Game over” message and disabling all buttons so the player can’t do anything, along with revealing surviving silos.

Also, I had to devise a method for randomly selecting the outcome of the mission assigned to a spy. The probabilities for success, failure, and capture depend on the rank of the spy and the mission itself, and confession depends only on the rank of the spy. I stored the probabilities in arrays that required only an index for the mission and the spy rank. Then I would draw a random number from zero to one, and the code needs only to check that the number falls within particular ranges of values to get the outcome of the mission.

Putting all these pieces together was tricky, but it was not the most difficult challenge faced in this project. When completed, I had a game that more-or-less amounted to the player whacking at a piñata opponent and hoping that it would be destroyed before something bad happens (like a confession). All that was left was adding an “AI.”

I say an “AI” and not AI because the opponent isn’t truly intelligent. I have always envisioned the game as being between an aggressive player looking to destroy his opponent, and an opponent that merely wants to survive and not destroy the player unless it feels that doing so is necessary to survival. In other words, while the player country wants to the conquer the opponent, the opponent merely wants to survive and is unaware of its rival’s nefarious schemes. So the “AI” is just a die roll that determines what it does that turn. No “intelligence” required.

The enemy will randomly do one of three things: it will build a new silo; it will murder one of the player’s spies; or it will spy on the player and make a guess as to how many silos the player has, based on the same method the player is using to get his estimates of the enemy stockpile size. This last one is the most dangerous; if the enemy gets a guess larger than a certain threshold (relative to the size of its own stockpile), it will launch a preemptive strike, resulting in game over.

Adding this was not hard. The AI takes its turn prior to the player, so all I did was added to the AI object all the code to perform in user-defined event zero, and once completed, it would then call user-defined event one, which starts the player’s turn. The “Issue Orders” button then was set to call the user-defined event 0 rather than 1. And just like that (well, after sorting out bugs, of course), the prototype was completed, and I actually had a playable game.

And as I said before, it sucked.

First, it was all but impossible to win. So many spies are recruited (one has to recruit lots of spies lest they build too many silos) that the player was guaranteed that at least one of them would be captured and confess in only a couple turns, and this would very quickly end the game. This would happen very suddenly and its hard for the player to not feel like he lost for playing the game as it was meant to be played, not making any mistakes in his opening strategy. Endings were very abrupt.

Second, it doesn’t feel like the player is making a lot of decisions. All he does is assign missions to spies and hopes everything works out. The most fun happens when assigning silo targets; this is the moment the player really feels like he’s making a key gameplay decision. Otherwise, there’s a sort of tedium, one of making the same gameplay choices every game hoping that this one will turn out better than the last.

The first problem has a simple fix: give the player veteran spies at the beginning of the game and move the probabilities in a direction better for the player. This makes the game last longer on average. The second problem, though, points to a more fundamental design problem. The game is not very engaging, and the player feels like he is making simple, automatic actions and rarely has to make a key decision. I admittedly don’t have a good solution to this problem, and the game’s design may very well be dead on arrival.


Picture

Let’s give some example gameplay. One game started out like below:

Picture

I assigned missions to my spies. I don’t know where any enemy silos are and counterintelligence at this point doesn’t seem helpful, so all spies are told to search for silos. I build one silo and three more spies. This resulted in the next turn:

Picture

Two of my spies found enemy silos, and thus ranked up. The third found nothing, but at least he wasn’t captured. The enemy is estimated to have two silos, but I know that this is not true; he started with three. Since I know that he has at least three, and also because I do not have nearly enough information about the location of the enemy silos to launch an attack, I won’t authorize an attack. Rather, I will assign one of my veteran spies to gather intelligence about what the enemy believes my stockpile size to be (the most dangerous mission), my experienced spy to seek out new silos, and my three rookies will try to refine the knowledge we have about the locations of known silos (the safest mission). The result:

I lost. Again. Looking at the debug console (the one I added to my game, not GMS’s console), I see that one of my spies was captured and confessed. This is basically how all my games end. In fact, this is one of the more successful ones!


Picture

In another game, it appeared that I had discovered all enemy silos, and had decent knowledge of their locations. You can see why below:

Picture

The estimated enemy stockpile size is 3, and at least some information was known about each of them. I decided to take the plunge and authorize an attack. I assigned targets for each of my silos:

Picture

And after launching my missiles, the game ends with this:

If I had hit any of those missiles, a green symbol for “radioactive” would have appeared. So it appears I missed all my targets. Bummer. This game does not forgive any cockiness.

Even though my game’s design may be fundamentally flawed, I want to have a finished game, even if it is not very fun. And I only have a (buggy) prototype. There’s a large amount of polish to be added. Remember that the end goal of this whole exercise was to make a game, even a bad one, in order to learn the process and the software. I still have a lot of room to grow, and who knows? Maybe someone else will derive a minute or two of pleasure from my boring game. Only way to tell is to not quit and finish the job.


Leave a comment