Introduction

I had always wanted to tinker around with gaming development, but the task seemed daunting. I needed the idea for a game, programming knowledge, a development suite, and much time and patience. If I was missing one of those elements, eventually my child-like enthusiasm would be drained, and I would find myself defeated without reaching my grandiose goal and retired to other forms of entertainment, like playing games. I had plenty of experience from coding for MUDs, but nothing that really translated well to the computer/console game side of the world. Since I came across Blitz Basic, I found myself "kicking the tires".

Once I went through the samples that came with the download and looked through various articles like "Modular Programming & Libraries", "Definitive Guide To Types", "Writing A Simple Game In Blitz Basic", and "Programmers, Organise Yourself", I decided that I finally had everything in place to get me back on the road to my first newbie game. I had my programmer's insight and experience. I had my tools and my development environment that was going to let me finally cross the threshold into the world of Windows Gaming Development. From that start, I decided on a simple game that would like me get going and see where I ended. Since everyone had seemingly done games like Pong, Breakout, or Galaxia, I decided to look into something even simpler so I could focus on how a game worked and how I could put my name on such a finished game. My choice would be: Tic-Tac-Toe.

There is nothing special to my game. There is hardly anything really noteworthy about it. However, I wanted to write this article detailing my development process. I have read articles about the technical details of creating a game, but they really don't provide much detail to the real, and somewhat tedious, parts to a game besides keeping track of scores and lives, along with receiving input from users. As I have stepped through "versions" of my game, I have slowly gained a better understanding of the process as a whole. As I continue with this article, maybe it will help you get a firmer understanding of the process and details and motivate you to carry through to the other side. Whatever programming choices I made in this game are usually no where near the best possible choices, but I took the approach of getting it to work and then worry about making it work better.

Enter Tic-Cat-Toe

Click Here for the source.

Before I enter into my analysis of its development, take a quick lookover the main code file ( tictactoe.bb ) and try to make your own Pro/Con list about it. After you have done that much, continue on seeing how my own self-analysis went compared to your own work.

Preliminary Analysis:

File Count: 7
1 Source File: 8 kB
6 Image Files: 316 kB

Note: The image files are regular bitmaps. Once converted into a more management format like Portable Network Graphics, or .PNG, they will be much smaller. Luckily, they are so simple in design that, when compressed, the size of the image files shrinks by over 80% in most cases, making it quicker to upload/download the entire .ZIP file.

Pros:

Cons:

3 Random Questions:

Why do you label it as "Tic-Cat-Toe" (TCT)?

Why do you explain this version as "lets me play 'Tic-Cat-Toe'" if the AI is non-existent?

The graphics are worse than stick men. What gives?

Random Breakdown Elements:

Global/Const: "Defines"

As you can see, I decided to use global variables to hold the resolution of the game. Not only does it make easier to edit, in my opinion, it allows me to use those values in various spots of my program, allowing me to edit one variable and have the rest of my program updated. For the GFX portion, it doesn't mean that I don't have tweak the other spots, but it gives me a sane starting point if I so choose to do it. Other variables hold stuff like easier key references, game states, and simpler array creation/checking.

Types and Arrays

These variables will be used more and more as I get into TCT development. I use the array to let me store the values of the playing grid. I also choose to make it an array of characters (strings) to let me have easier-to-read representations of the grid. I could easily use something like -1, 0, +1 to show an empty or filled space, but I liked seeing "X", " ", "0". I picked the space " " for arbitrary reasons. The types are simple now, but they will get more complicated as I use types to handle the Z-Ordering of my game, along with other facets. Also, since I am fond of structs from C, and my MUD programming days, it is nice to have a single "object", like Board, to handle all of my "In Game" values.

Game Flow/Design

Very simplistic While loop. Nothing really fancy here. I use the ESCKey to provide an emergency way to leave my program, just in case I don't implement the logic I have swirling around in my head correctly. For the final version, I'll make sure that the game can only end by proper methods. The other point to make is unless you have looked over the code, you will have no way to know how to restart the game or even end it. That is a terrible weakness in the design and is necessary for correction before a "final" version is made. However, since it is just me looking at the code - mostly, I put it off until "later", which was in version 3.0.

Outside Commentary

cR@wLy: I really think it's a good idea to show pretty much everything you have gone through though, even where you made mistakes (although it'd be a good idea to point out that they are mistakes when you go through it after ):

3 Mistakes In This Version

• FindRow() & FindCol(): It isn't so much of a mistake, but more of a sloppy, bothersome way to handle data. As it will be shown in version 2.0, the X, Y coordinates used to define clickable spaces to place signs are hard-coded in each function that uses the data. This implementation isn't a "mistake" per se, but it makes future changes and updates more complicated, and allows more mistakes to be made between the computer chair and keyboard, when changing these values. A better implementation would be to store the values in a single spot and make one set of changes affect everything that uses that data.
• Single Source File: Once again, it isn't so much of a mistake, but more of a balancing act of "helping me" v. "hurting me". As it stands now, the game, and its source, is so simple that having everything in a single file is not too bad, but as it grows in complexity, and for a Tic-Tac-Toe game, it has, you will want to compartmentalize various aspects of it just to save you time and energy from scrolling through 1000s lines of text. This is no exaggeration. As it stands now, which is version 4.0, I have 8 source files and two of them alone combine for 1000+ lines. Also, you will want to make sure that you aren't accidentally messing up stable, running code when you are making changes. If you can keep your changes centralized ( Example: Keeping all image functions in a file and if you don't touch that file, you won't have any problems with your drawing routines. ) to each "phase", which is however long you deem it to be, it makes debugging easier. However, at the end of the day, it is a design/judgment call that each programmer will have to make.
  Note: See Ghost Dancer's article, "Modular Programming & Libraries" and Ted Jackson's article, "Programmers, Organise Yourself!" for more details.
• DrawBoard() & DrawMouse(): Okay, this implementation is a mistake. I got sloppy on this part, and I tried to handle the proper drawing order manually, instead of using Z-Ordering, like detailed in Krylar's article, "Z-Ordering". This implementation is a problem because, as I add more and more images to the game, they start drawing over each other out of order. Also, to "Keep It Simple, Stupid", all in-game drawing should be handled in a central spot instead of in different functions, especially if those functions do nothing but draw a single entity.
  Note: I am not using any FreeImage calls either. Since the game does nothing but load up, play, and shutdown, I am just letting Blitz handle the garbage cleanup. This solution is changed in later versions.

Conclusion

This document isn't over, but it is only beginning. I decided against doing a complete walk-through of version 1.0 because it is not anywhere near a complete game. This article should only act as a guide to help you see and understand what goes into a game besides the actual playing/AI aspects of it. If it helps you get a better footing on the ways, means, and methods to creating a game, it is doing its job. If it is falling way short of certain aspects or topics. It will be added later to this article or covered in the accompanying articles.