Our Knoxville Game Design group is featured in the cover story of our local Knoxville entertainment paper, Metro Pulse. The seven page article gives our thoughts on the current Indie Game community, and describes our participation in the recent Ludum Dare 28 competition. The article features interviews with Knoxville Ludum Dare participants ViNull, DylanWolf, Insane66, and myself (GaTechGrad) along with Chaosoft Games.
Tex Oneman is my third official Ludum Dare entry, and it was my eleventh game developed for this site (including mini-LDs and warm-ups) since I registered in April 2013. I feel like I’ve learned a lot during that time, and these projects have definitely made me a better Unity developer. For this Ludum Dare, I knew I wanted to do something different.
After hearing the theme announced at our local Knoxville Game Design meetup, I knew I wanted to make the number “one” a central part of the game. Going with that approach, I decided to make the number “one” humanoid, since I knew how to quickly make meshes from text in Blender. I added eyes, arms, and legs, but the character was still sort of boring. I thought about some of the characters in my latest XBox Live Indie game TTY GFX ADVNTR, and remembered the character “Needles”, which is a humanoid cactus wearing a cowboy hat. Then I remembered playing the classic game GunSmoke at one of those 20-in-1 arcade machines not too long ago. There really haven’t been too many western themed games lately. Therefore, I gave my humanoid one a cowboy hat, boots, and a gun to shoot. I also went ahead and modeled a cactus in Blender as well as a background prop.
Tex Oneman gameplay
Another classic western game was Wild Gunman. I liked the Gunman name, so I decided to call this game “Tex Oneman”. The original name (One Gunman) was also sort of a play on the term “Lone Gunman”, which differs my game’s title name by just the leading “L”.
After creating the models, I got the main character imported into Blender and moving around. I also created some enemy boxes that moved around. Next, I implemented shooting projectiles. However, I quickly found that trying to aim on the X-Z plane with no lock-on could be quite difficult. Therefore, I limited the character to just being able to move left and right, and he is only able to shoot forward. This makes the game similar to other classic arcade shooters, except this game uses a third person view instead of a top-down birds eye view. Shooting enemies was fine, but it still seemed really boring.
Then I had the idea that Tex Oneman would shoot number sequences as the targets. For each enemy, I assigned a random digit value in the range of 2 through 9. First I decided to use evens and odds as the requirements. Once I got those working, I added a countdown so that the requirement would change periodically. I was really inspired by a game called Pig and Bullet, which makes the player switch between collecting red and blue bullets every few seconds. The problem with that game was that you never knew when the objective would change, so I added a visible countdown in my game. New objectives were added, such as Fibonaccis (2 3 5 8), Squares (4 9), and Perfects (6). I didn’t include 1 in the sequences, because that would mean that Tex Oneman would be wanted as well causing unneeded confusion. Each sequence also has a set reward associated with it, where the more complex sequences have higher reward values. For the lose condition, I made it so that the player lost a life if they run into a number or shoot an incorrect number. Finally, I rendered 3D numbers in Blender, which replaced the box enemy meshes in my game. I included statistics such as number of shots and accuracy percentage on the game over screen, which was inspired by other classic arcade shooters.
Since I had the core engine finished on the first day, I worked on polishing the game on the second day. A “WANTED” poster was added which displays the current objective in the lower right portion of the screen. The objective change countdown was converted into to a bar which shrinks as it nears zero. Like my previous entries, I used Garage Band on my laptop to make the music for the game. The piano and guitar sounds were primarily used to give the game a more western feel. Bxfr was used again for making the gunshot and other sound effects. Using my computer microphone, I recorded myself saying “Shoot X”, where X is the current objective. Then, the vocal recordings were modified a bit in Audacity to give it a better sound. The voice seems to really enhance gameplay, since it keeps the user’s attention on shooting the numbers, instead of looking at the Wanted poster. Finally, particle effects were added using a star texture that I made in Gimp. I tried changing the particle system color over time, but for some reason it just wasn’t working for me.
https://soundcloud.com/gatechgrad/sets/one-gunman
I learned a few lessons from this game. The first lesson is that people don’t like shooting at a perspective. I thought the controls were intuitive, but some people definitely found it difficult to shoot. The best I can explain the shooting controls is that it is similar to rolling a bowling ball on a bowling lane. The game could have included some additional visual cues to help line up the shots down range. I could have also used a top-down view, but then the player would not be able to see the details of the model that I had created. Using an orthographic projection may have helped as well, which would have kept the numbers and bullets traveling vertically on the monitor screen. Another option would be to highlight the number that the player is currently targeting, but I thought that may make the game too easy.
There was also some difficulty with getting the model moving correctly. When I assigned the armature, I used the default “with automatic weights” that I always use in Blender. However, since the arms and legs were so skinny, it didn’t properly weight paint all of the vertices. I’ve done manual weight painting before, but this model had some difficult to reach vertices. After some trail and error, I discovered that it is possible to pose the model while weight painting it. This made reaching some of the difficult to reach vertices much easier, and you can see the vertices snap into place while weight painting it.
Overall, I am satisfied with the game that I have created. I would have liked to made the other numbers humanoid as well, and I really needed to add more props to the environment. Things like buildings, dust, and tumbleweed could have really added to the environment. If I get the time to work on this game some more, I definitely think it could be turned into a great game.
For this mini-LD, I decided to create a game in the style of the BBS door games that I played when I was a teenager in the mid-90’s. We had a 64 line BBS in Atlanta called INDEX (Information, News, and Data Exchange), which was huge at the time, since most BBSes only had one or two lines. This meant that when all of the telephone lines were tied, you had to wait for someone to hang-up before you could dial-in with your modem to play any games. However, these were the first games that I had ever played online, which had a persistent world and where you could interact and compete against other players online. These online DOOR games were really the precursor to current day MMOs.
Two of my favorites were L.O.R.D. (Legend of the Red Dragon) and Trade Wars 2002. I did a few web searches on these old games for inspiration, and I came across the Wikipedia page for Seth Able, the original creator of L.O.R.D. and in-game bard character. I looked through the list of his projects, and noticed a recent game called Growtopia. I knew I had heard about that game before somewhere. Then I realized that it was on the Ludum Dare website, and Seth Able (now Seth Robinson) is actually a Ludum Dare administrator. I guess the game development community is really a small world after all.
I wanted to use ANSI style graphics, but I knew I didn’t have time to implement a full networked game running through a VT100 terminal, so I decided to go with C and SDL and export my ANSI graphics into PNG images. To get the BBS DOOR game aesthetics, I created all of the artwork in AcidDraw using DOSBox running under Ubuntu Linux. Then I took a screenshot of that image using Gimp, cropped, resized, and then exported to PNG. It was much simpler to do it this way, rather than trying to write a complete VT100 terminal emulator in a weekend. However, I do have all of the original .ANS art files, so those could be used to port my game into a real BBS DOOR game.
Creating ANSI graphics using AcidDraw.
I started out by making the title screen and then the village, which is the hub for the game world. From the village, you can access the Inn, Blacksmith, explore regions, or view stats. I tried structuring my code like my other games, with a game loop that calls an Update event handler and Draw method for each screen. However, since C is not object oriented, I had to make sure that the names for the Draw and Update methods on each screen were unique, so I prepended the screen name before each method. Then in my main game file, I keep a state variable which determines which screen is active, and then calls the appropriate Draw and Update method based on a switch statement using the state variable.
I had two files that contained data structures, which are the Player and Enemy. To keep things simple, I avoided pointers and just had one instance for each. The characteristics for the enemy is loaded when the battle event is activated. It is important to declare the data structure variables as “extern” in any other files which use them, which is something that I had forgotten over the years. All of the structure definitions and function prototypes are defined in corresponding .h header files, which makes includes much simpler when everything is laid out correctly. The only headache is keeping the method prototypes in the header files and the method definitions in the game code in sync. If you add a method parameter or change the method name, you’ve got to change it in both places. I’m thankful that we no longer have to do that in languages like Java and C Sharp.
The game plays much like classic BBS DOOR games. You can rest at the Inn to regain your health, for a small price. The blacksmith will “upgrade your weapon”, but for now it just raises your attack power. I would like to add unique weapons and armor in a future release. On the stats screen you can view your health, gold, level, experience, and points required to level up.
The player starts out with two areas to explore, the meadows and forest. As the player progresses through the game, they will open up new areas to explore with more difficult monsters to defeat. Aside from the monster battle, there are three unique events while exploring: 1) The player can find money. 2) The player can encounter the old woman, who will either heal you or steal some of your money. 3) The player can interact with the merchant. Buying items from the merchant will open up new areas to explore from the village. Some merchants may refuse to talk to you unless you have a special item to show them. I had much bigger plans for the items acquired from the merchant, but I had to scrap those ideas for the sake of time.
I did learn (or re-learn) a few lessons while making this game, which is my first SDL game since I wrote Legend of Tux back in 2009. First of all I met my old friend the Core Dump, after trying to use an attribute that was set to NULL. Then after I thought I was done with the game, I noticed that the menu would sometimes go blank. After viewing the system processes, I noticed that I had a memory leak. Obviously, a simple game like this one shouldn’t take 2 Gigabytes of memory. I determined that the probable culprit is the method call which creates a texture from a character string, TTF_RenderText_Solid. I’m assuming that the menu went blank because the program ran out of memory to allocate new SDL_Surfaces for the menu text, so it wasn’t able to blit the text surface to the screen. This problem was fixed by calling SDL_FreeSurface on the SDL_Surface containing the text, after it has been blitted to the screen.
Finding memory leaks in Linux and Windows.
After I had the game completed, I wanted to make a Windows version so more people could play it. The most straightforward way of doing this would be to install Cygwin on Windows, and then compiling with SDL on Windows. That’s the way I’ve created Windows exectuables in the past, but it is a hassle to have to switch operating systems to do a secondary build. Therefore, I thought I would try my hand at using a cross-compiler to create the Windows binary under Linux. I found a good tutorial on Ryan “icculus” Gordon’s website, which explains how to build an SDL cross-compiler on Linux. First, I installed mingw32 for Linux from the Ubuntu Software Center. Then I used the install script from the tutorial. It was helpful since it automatically installs almost everything you need, however it does mess up some of the directory structures. For instance, the “i586-mingw32msvc-sdl-config –cflags” command puts “SDL” in the -I (include) parameter. In my code files, I include “SDL/SDL.h”, so having “SDL” in the include parameter will generate numerous compiler errors because it will be looking for the headers in “include/SDL/SDL”. I could have fixed this by changing the includes in my code files to just “SDL.h”, but that would have broken the compile for the Linux build. Therefore, I just explicitly put the output of “i586-mingw32msvc-sdl-config –cflags” as the compiler parameter, removing the extra “SDL”. The other problem with the installer script is that it put all of the optional SDL library headers (like SDL_ttf.h and SDL_image.h) in the “include” directory, so I had to move all of those up to “include/SDL”. See the Makefile included with the source code if you want to see the final compile command for Windows.
I really enjoyed this project, since it brought back memories of the games that I played back in high school. It also made me thankful that programming technologies have evolved over the years.
