One thing I've learned in the process of developing my game is that there will be features that I am just not looking forward to adding because I know they will be more complicated than anything else I had added up to that point. However, these are the features that my game absolutely must have. By requiring that I work on my game every night, I force myself to confront these challenges and discover that I can in fact surmount them. And when I do, my game becomes so much better.
The first major leap forward was developing a GUI. I had reached a point where a GUI could no longer be avoided. I had been avoiding one because I didn't even know where to start with a GUI. But since I could not go further without one, I figured out where to start.
One of the game designer's best allies are pencil and paper. Nothing stimulates the mind like the flow I get from putting pen to paper. I don't have to worry about what the code will look like or where I will get the assets for the element I'm designing; I simply create a direct line from my mind to my paper and I watch as problems are almost miraculously solved. I returned to my design document and tried to draw out what my UI should look like and what features it would need. It took a couple revisions, but I actually had an idea of what to do, and I then turned to my code to create it. The majority of the UI is created by the draw functions, since I want my game to have that 1980s feel like WarGames. I discovered that the window size I had originally set was not going to cut it; I was going to need more space in the vertical direction. I also ended up making the buttons in the sprite editor, which is not ideal; I would prefer to draw them in code since then I could ensure they are positioned pixel perfect. I had no idea how I could make those buttons clickable, though, unlike sprites, so I stuck with it. I liked the end product. There turned out to be plenty of free space in the control panel that I had to fill. I added flags for the FRC and DPRFC that I drew myself, and I really like the effect. The process of designing the GUI gave me ideas for how to add little bits of flair or easter eggs that could make the end game more immersive and enjoyable, adding character to the setting that I originally was not expecting to add. I even got ideas for special effects, such as glow, typewriter text, and scan lines that I will add later when the basic structure of the game is complete. This makes me very happy. I've learned from others that these subtle, non-gameplay elements add immesurably to the experience and are necessart, but I had no idea how I would come up with ideas of my own. The lesson I learned is that these will come in time as the game is developed, and one should be open to these ideas when they do come.
After the basic UI was down, I had to make at least some of the buttons clickable, particularly the ones that are responsible for ending a turn or issuing orders. This was not a hard task. But after this came adding a GUI system for pop-up menus, and I was dreading that job. I had been searching for tutorials and products on the GameMaker Marketplace for an in-game window system and other GUI elements, but this search bore little fruit. I ended up having to make a pop-up menu system myself. The end result worked, but in the end it will require that I create an object for every dialogue box or menu I need. I was hoping to have a more flexible system than that, but beggars can't be choosers. And in the end, the menu system I came up with does work well and I learned in the process of creating it. Eventually, though, I will have to create a system for dialogue boxes, and I do not look forward to this.
What followed this was a landmark step in the game: the turn system. In my game, the player assigns orders to all his spies and expends all his resources to construct more silos or recruit more spies. (He is required to assign a mission to every spy and use every resource available. This is a conscious decision intended to prevent tactics of slowly building up a stockpile capable of carpet bombing the enemy, covering every inch of enemy territory with nukes. Since there is always a chance a captured spy will confess, a soft time limit is imposed. Avoiding spies altogether and building only silos would also result in disaster; so many silos would be built that the enemy will become spooked and launch a preliminary attack.) After the player has assigned all his resources, he may click the "Issue Orders" button and all the orders would be processed. This is done through a user-defined event that is triggered for all objects. Each object has code that will be run for this event that enacts orders and resets variables. This basically wraps up the player's side of the turn system. All that is left is the AI's side, which is considerably simpler.
The last job of the week was developing the different spy missions. The search mission was already present and took no effort to add. The counter-intelligence system was also trivial. But the investigate mission challenged me for days. The fact that the player selects which area of belief to refine means that this mission cannot act like any other mission I had designed. The player needs to be able to see which area of belief he will be selecting and the game needs to actually act on this information and give the player a chance to select the silo. This required some rethinking of how things are done in the game for other elements. I am getting close to getting this system finished, but there is still work to do.
The progress on the game has been good. The commitment to spending an hour every day on it forces me to overcome roadblocks and prevent procrastination (at least in terms of procrastinating for days; I still only make these games later in the evening). At this pace, I would not be surprised if a working prototype is ready by the end of next week. But I make no promises.
0 Comments
Leave a Reply. |
AuthorCurtis Miller is an instructor and graduate statistics students at the University of Utah. Archives
June 2016
Categories
All
|