GBGames

I’ve talked about the book Difficult Questions About Videogames already, but I have found quite a few more resources regarding the language and vocabulary we use to talk about games.

• Game Design Patterns: to create a basis for a common language about video games
• The Case For Game Design Patterns
• The 400 Project: an ambitious attempt to collect “The 400 Rules of Game Design.”
• There Are No Words (Yet): The Desperately Incomplete Language of Gaming: comparing the development of film vocabulary to the development of a video game vocabulary
• Formal Abstract Design Tools: improving development and knowledge through FADT
• Digital Games Research Association: amazing resource for researching digital games and promoting knowledge
• Game Studies: a crossdisciplinary journal dedicated to games research
• Ludology.org: an online resource for videogame researchers

I’m still reading through the book, but I have to say that I am disappointed in the quality of the writing. The people who put the book together said that they wouldn’t do much more than publish the results, but could they at least have made it less painful to read? Simple spelling errors, grammatical mistakes, and others could have been cleaned up and still “kept it real”. It is still an interesting book to read. It is just not as enjoyable as it could be.

In any case, I’m now fascinated by the development of a common language to use in game development. A number of the articles will point out that video game language has so far been coopted from film, but film language isn’t always appropriat or available. Sure, there are certain terms to use to describe how a game looks. And there are terms to explain the narrative in role-playing (roleplaying? role playing? check google to see that there doesn’t seem to be a consensus here either) games. We can talk about technical aspects easily. But what about words to describe how items increase in power as a player goes through a game? Or how a game can provide you a situation and the player can create a plan based on it and the actions the game provides? These ideas are abstract and can be applied to many games in different ways. They’ve only recently been identified and given formal names.

Design patterns have sped up software development research by providing a standard way to talk about software. When someone talks about Singletons or Proxies, everyone knows exactly what he or she is talking about. Similarly, algorithmic analysis allows us to talk about the difference between algorithms that take constant, linear or quadratic time to complete based upon the input.

When it comes to game development, however, we seem to have very little to say that allows us to talk to each other. For example, what I mean by gameplay is different from what you mean by gameplay, so saying that Game X has better gameplay than Game Y is meaningless. Of course, it doesn’t stop people from having arguments about it.

I will be watching this field of study carefully, and hopefully I will be able to make my own contributions.

I loved participating in Game in a Day, and I gained a lot from the experience. For one, I have created a game that I can continue to work on until it is a finished product. I added a few more game development blog links to my list. Also, I learned quite a few new things as well as finally understanding things that I already “knew”:

• I still have a lot of C++ to learn.
• I still have a lot of Kyra to learn.
• Nothing helps more than proper planning.
• Hacking is a lot more fun with a good plan.
• I need to remember to make clean before packaging a project. There is a big difference between 500KB and 2.2MB.
• After a successful build, not checking in the code before attempting to add a feature is just asking for trouble.
• Too much Mountain Dew is bad.
• Not planning for snacks/eating/showering is even worse.
• It is a lot easier to see that death marches can result in a lot of uncommented code, even with the best of intentions.
• Eating your own dog food is great for revising your design since you can find out what doesn’t work quickly.

That last point is in reference to an article by Joel Spolsky. He basically talks about the importance of actually using your software to dig out bugs and usability problems before releasing them to the public. Eating your own dog food. While I was programming, I was testing. One problem I found was the arbitrary restriction of only four directions for movement.

When I created the control scheme, I didn’t want to waste time making four more images for diagonal movement (even though it would have been a few more minutes of copy, paste, edit, and encode to .dat file), so I made the movement restriction match the images in the game. Perfectly fine, right?

After a few iterations, adding a different feature or otherwise working on unrelated code, I found myself getting frustrated. When I built the program and tried to run it, I found that the controls were just plain irritating! At one point I decided to make the simple change so that the player character can move in all 8 directions. It wasn’t huge, but that tiny difference made the game less unbearable.

My ability to create improves every time I use it. All the theory and facts I’ve learned through books and tutorials are nice, but they don’t compare to the experience of actually making use of them. FuseGB may not be a great game, and I’ve definitely made some mistakes developing it, but at the very least it has provided me with a lot of experience to help in future game development. As Gilbert Chesterton says, “If a thing is worth doing, it’s worth doing badly.”

Click below to track my June 2005 GID development progress:
Part 1
Part 2
Part 3

5:03 PM

Cans of Mountain Dew: 7
Subversion Revision: 35

Let’s take a break.

At this point, I am trying to think about what I can do to improve on the project. Right now, the main player can drop a pulsating bomb which explodes after a few seconds. The explosion will make the enemies disappear. The enemies move about in a random, convulsing sort of way.

I could try to clean up the code, but what’s the fun in that? Cleaning up the code is what you do after GID. During GID, you just try to make the best game you can in 24 hours.

I could try to improve the AI, but that would involve research since I am not too familiar with setting up scripts and the like. Everything is hardcoded unfortunately. Still, it doesn’t close off my options too much. I think I will make the enemies birth new enemies every so often. Also, if they touch the main player, the player dies.

I should probably add a new state to allow you to return to the game rather than call in the main menu state as a placeholder. I believe it also ruins the game by deleting the Kyra engine and creating it again. A new state would be much better.

6:01 PM

Cans of Mountain Dew: 7
Subversion Revision: 39

Cool. The game now pauses, although it doesn’t display anything to let you know. Bad UI, but hey, it’s a feature that wasn’t there before. It is difficult to exit the game since there is no feedback to let you know what state is active. If you hit Esc, you will pause the game. Hit Esc again, and you resume. Hit Q while paused and you go to the GameOver state. Hit Q to go to the main menu. Hit Q to exit the game. Whew.

7:04 PM

Cans of Mountain Dew: 8
Subversion Revision: 46

The enemies can now kill the player. The player can kill the enemies. It goes to Game Over, and if you want to start over again, it now restores the game properly.

The enemies are still stupid, but now the player has a DEAD state. I think it is amusing looking, although it is a bit too subtle:

8:13 PM

Cans of Mountain Dew: 8
Subversion Revision: 49

Took a break to change, wash up, and talk to people in #gameinaday before continuing. My sister took some pictures of development:

10:51 PM

Cans of Mountain Dew: 8
Subversion Revision: 52

COMPLETED!

After a little scare where I had an actual working game and then messed it up WITHOUT having checked the working copy into Subversion first, I finally got it to work again. I changed the vectors to lists so I can actually remove blasts and enemies when they are no longer alive. The enemies multiply at a quick rate, but they don’t currently pose much of a threat as they still just randomly convulse. Still, the gameplay is there. I’m proud of what I accomplished for my first GID. I learned that I need to improve on my understanding of C++ and Kyra if I want to work more effectively with them in the future. And I had fun! I mean, I made an actual game in 24 hours! It has no sound, the graphics leave a lot to be desired, and the actual gameplay isn’t much better, but it is a game. It is something I can claim that I created. It’s a great feeling.

Click on the image below to get the source and graphic files. The packages are available in .zip and .tar.gz formats. Make sure you get the latest revision unless you want to see how the project looked at an early stage. You’ll need to make sure you have the Kyra Sprite Engine on your system, which requires SDL.

Click below to track my June 2005 GID development progress:
Part 1
Part 2
Part 3

10:11 AM

Cans of Mountain Dew: 4
Subversion Revision: 20

AH! I slept for FOUR hours! Whoops! Well, it turns out that people tend to assume that breaks that last less than an hour count in the 24 hours, but breaks longer than an hour don’t. So if I continue to work through 7PM until 11PM, my project is still considered a GID.

12:24 PM

Cans of Mountain Dew: 5
Subversion Revision: 23

Just finished wrestling with a problem due to my lack of understanding of Kyra. It turns out that Kyra’s Vault, which holds all of the resources in the engine, only handles one data file at a time. I was seeing two player sprites when I should have seen one player sprite and one enemy sprite. Once I combined the two sprites into the same data file, similar to how the Kyra demos handle it, it was able to create both sprites.

12:55 PM

Cans of Mountain Dew: 5
Subversion Revision: 24

Added diagonal movement for player. I was already seeing that it would be frustrating to be restricted to moving in only four directions. I don’t think I want to spend time updating the graphics for four directions though as I only have hours left.

1:50 PM

Cans of Mountain Dew: 6
Subversion Revision: 28

Blast! B-)

It’s getting there!

3:07 PM

Cans of Mountain Dew: 6
Subversion Revision: 29

Now I have blasts freezing upon impact with other blasts and enemies. I had some complications because I wanted to kill off enemies by removing them from the C++ std::vector, but vectors aren’t great for it, and I wasn’t sure how to replace it with something else without causing headaches. I’ve decided to work around it by making use of the alive variable in Enemy.

I’ve also noticed that Player, Enemy, and Blast are so similar they probably could have been derived from a common base class, making it easier for me to add new objects. I suppose I could go ahead and refactor, but it is GID, and I’d rather try to get gameplay working.

3:48 PM

Cans of Mountain Dew: 6
Subversion Revision: 32

Now blasts and enemies disappear upon impact, and blasts will actually explode after a few seconds and the explosions disappear after a few more. They act more like bombs than gun shots, but I can see it being kind of like Bomberman in that sense. Sometimes games evolve that way. I just wish it was a conscious decision. It was more of an accident.

4:31 PM

Cans of Mountain Dew: 6
Subversion Revision: 34

Levels end when no more enemies are detected. I now need to make an elegant way to transition back to playing again. Right now, it just brings up the main menu, which is itself not very usable as it still only brings up three menu entries that are all the same, and you can’t choose between them. Priorities. B-)

Check it out so far:

• FuseGB-r34.tar.gz
• FuseGB-r34.zip

Click below to track my June 2005 GID development progress:
Part 1
Part 2
Part 3

This blog post and the next one will act as my .plan and document the implementation of my game design for June’s Game in a Day.

While it is supposed to be between Saturday and Sunday, Sunday is my sister’s gradution party. Instead, GID for me was from June 10th through June 11th. After I bought a 24-pack of Mountain Dew, got home from work, and had dinner, I set to work.
I already put six cans of Mountain Dew in the fridge to prepare for the night. It should be a good boost, especially since I don’t drink caffeine often. I also cleared my desk and made sure I had the right books, notebooks, and other tools available.

June 10th

7:00 PM

Cans of Mountain Dew: 0
Subversion Revision: 0

I set WorkRave to give me 20 second breaks every 10 minutes. It isn’t very disruptive and lets me rest my eyes. At the end of 4 hours, it will force me to take a 10 minute exercise break.

I already setup my Subversion repository for the project and created the normal directories: source, documentation, and resources. The first two are self-explanatory. Resources are things like music, sound effects, images, and other data.

I started by trying to create a basic finite state machine as described by Tony’s Game Programming Tutorial. I didn’t want to just copy the files and use them as my own, since I didn’t like the naming scheme and the C code strewn throughout. I wanted to use Kyra instead of straight SDL. Besides, I will learn a lot more about how the FSM works by writing it out than by copying and pasting.

7:45 PM

Cans of Mountain Dew: 0
Subversion Revision: 6

I’ve written a few source files but it is mostly for infrastructure rather than game code. TomB warned me that I can get stuck trying to build the framework, especially since I am basically doing this from scratch.

Even though I asked people to leave me undisturbed, I still must do some laundry.

7:58 PM

Cans of Mountain Dew: 1
Subversion Revision: 6

First can of Mountain Dew opened.

Still writing the FSM…

8:45 PM

Cans of Mountain Dew: 1
Subversion Revision: 8

The basic FSM game engine is written. Now onto making individual states.

8:54 PM

Cans of Mountain Dew: 1
Subversion Revision: 9

It compiles and builds cleanly for the first time! A window appears and then promptly seg faults since I don’t have any states yet.

9:18 PM

Cans of Mountain Dew: 2
Subversion Revision: 9

Hit my first snag. Everything compiles, but it won’t link. Spent almost an hour before finding that I didn’t declare a static member in the implementation file before using it. Doh!

11:22 PM

Cans of Mountain Dew: 3
Subversion Revision: 10

Oh boy. I’m hitting a wall. I’m not sure how to proceed. A KrEngine is declared within GameEngine, but none of the states know about GameEngine. I ended up making GameEngine a Singleton and having everything accessed through it, which took quite a bit of refactoring.

The result:

I’ve been working on this project for about five hours now and I don’t have much to show for it. But I can’t get discouraged. After all, I have more done than I did five hours ago.

June 11th

12:48 AM

Cans of Mountain Dew: 3
Subversion Revision: 14

Now I have a splash screen. Yes, it is programmer “art”.

3:18 AM

Cans of Mountain Dew: 4
Subversion Revision: 15

Ok, I’m learning. Virtual destructors and static members are parts of C++ that I am not terribly familiar with, so I am glad I get the chance to fight with them now. Still, I would love to be further along than I am. From splash screen to menu screen. No gameplay yet.

I’m also getting sleepy. Should I rest or push forward? Push forward!!!

..after a quick bathroom break.

5:27 AM

Cans of Mountain Dew: 4 (-1 bathroom relief modifier)
Subversion Revision: 17

I’ve finally gotten to the point where I can write the PlayState, where the actual game takes place!

I’m used the Gimp to draw up a few images of the main Player. I decided to make a crude alien. The Player class was easy to make since it just has to encapsulate KrSprite and some data about the Player. I can probably get it playable fairly quickly. Even if you can’t do anything else, you should be able to move around and possibly shoot something.

For now, I can detect the arrow keys and change the action of the Player. The screenshot doesn’t show it, but his eyes move depending on the direction you press.

5:55 AM

Cans of Mountain Dew: 4
Subversion Revision: 20

About 10 hours later, I finally have the main character moving about the screen according to the arrow keys. He only moves in four directions, but I’m not going to draw up more images for diagonal movement this late in the GID. I’d rather spend my time getting the fusion part of the game going.

I will try to take a nap now, but check out the 1.6MB project (mostly due to the raw images in FuseGB/resources/) so far:

• FuseGB-r20.tar.gz
• FuseGB-r20.zip

For June’s Game in a Day, the theme is fusion:

fu·sion (fyzhn) n.

1. The act or procedure of liquefying or melting by the application of heat.
2. The liquid or melted state induced by heat.
3.
1. The merging of different elements into a union: the fusion of copper and zinc to form brass; the difficult fusion of conflicting political factions.
2. A union resulting from fusing: A fusion of religion and politics emerged.
4. Physics. A nuclear reaction in which nuclei combine to form more massive nuclei with the simultaneous release of energy.
5. Music that blends jazz elements and the heavy repetitive rhythms of rock. Also called jazz-fusion, jazz-rock.
6. A style of cooking that combines ingredients and techniques from very different cultures or countries.

A lot of potential. I keep thinking of the episode of Invader Zim where the aliens try to fuse things together with duct tape. “Let’s feee-yuuuze him with this juicebox!”

I’ve been trying to come up with some ideas for this GID. I thought of one where blob-like organizms would combine together to form larger ones. Another one featured a Fuse Ray/Gun that would lock two items together: two enemies, an enemy and another object, etc. A third involves the main player riding around in a tank that would fuse to nearby objects that act as weapons or armor. Another ideas was a game where you have to mend pipes that are about to burst by fusing the cracks shut.

That tank idea apparently has already been done. TUMIKI Fighters is kind of like combining Katamari Damacy and a sidescrolling shooter.

I’ve decided to go with the Fuse Gun idea. I imagine it would be funny to see characters getting fused with objects and trying to move about. Two really quick characters might struggle to move together, resulting in a slow moving composite. Some objects might actually make them stronger, though. Fusing a metal bucket to a small creature would result in a living tank.

I’ve decided to use C++, Kyra, and SDL for this project. I think most GIDs seem to use Garage Game‘s Torque engine, but there is no rule about what you can use.

I’ve been warned by TomB in #gameinaday on irc.maxgaming.net that I really should pick something simple for my first GID. The fact that I feel I need a design means that it is too complicated. Perhaps he’s right, but we’ll see how I do.

The Design

Fuse Gun Blast, or FuseGB, is a game where the player can use a gun to fuse enemies and the environment together. I am thinking of making it an overhead game like The Legend of Zelda, and the player can move in 8 directions.

Fusing
When the player shoots the fuse gun, a charged bullet will continue until it hits a wall and disappears or hits an enemy/object. If it hits an enemy, the enemy is frozen and charged for a few seconds, and the player can shoot a second enemy or an object. The two will then fuse together, and their abilities and movements will be changed.

Enemies can be fused to existing fused groups. For example, if there are three enemies, you can fuse two of them together, then fuse the remaining enemy with the group. Objects, such as buckets, can be fused to these “enemy farms”.

For simplicity, two objects cannot be fused together, and nothing can get fused to the walls. If a fuse blast hits an already charged enemy, the enemy is simply stunned for a time, but takes no damage.

Levels
Each level is made up of a room filled with objects, walls, and enemies. Destroy all enemies to complete the level. The less ammo you use to destroy enemies, the more points you get. Fused enemies share the same life force, so fusing them together allows you to use less bullets to kill all of them at once. Objects such as dynamite and bombs obviously allow you to destroy larger enemies easily.

I’ll likely only have one level at the end of this GID.

Enemies
They can move about in 8 directions as well. Some are quicker than others. Some are bigger than others. If they touch the player, the player takes damage and/or dies. When fused with another enemy, their stats are kind of averaged out. Enemies with 1HP and 3HP in a fused enemy farm will have 2HP combined, for example. They will try to move independently, but obviously can’t. On the other hand, if they try to move in the same direction, the farm will move faster than either normally would.

Items
Some items will be explosives. Other items will be speed reducers, but they can also act as armor and add protection. I am thinking that some items can be fused to enemies, turning them into friends instead. But that might add too much complexity to an already complex design.

I’ll leave it at this for now. I’ll document the development process as I go and post a blog entry at the end. Hopefully, I’ll have a working game to show for my effort, but even if I don’t, it should be fun and I should learn a great deal.

Click below to track my June 2005 GID development progress:
Part 1
Part 2
Part 3