Make A New Game

I do a great deal of hobby coding. If I'm not doing that, I'm playing games, which doesn't leave much time for blogging. It doesn't help that I also program for a living, so by the time I get home, gaming is much more appealing than hobbying around with code. Lately I haven't been into a new game so I've been thinking more and more about making another game myself. To date, my games are very simple, use a handful of 2d sprites and were easy to make. Limiting my games to 2d has two distinct advantages.

1. I can load up gimp and paint sprites, or as was recently suggested, load up Inkscape to make prettier sprites.

2. 2d logic is generally easier. You can cull to boxes instead of frustums and hit detection is usually trivial.

I could argue that you can get more depth out of a real 3d environment, but there are still a lot of really well done 2d games that knock the socks off of many recent 3d titles, not because they have more stunning visuals, but because they're just more fun. Even then, there are some 2d games with very impressive visuals.

Even though 2d logic is generally easier, 3d logic really isn't that hard once you wrap your head around the basics. Things like octrees, AABB trees and ray-triangle collision detection are actually not that hard to implement. Furthermore, there exists a wealth of open source 3d engines that solve a lot of these problems for you. (Ogre3d, Crystal Space, Irrlicht)

When I ask myself what keeps me from taking on a 3d game in any serious context, it's content creation. If my game needs people walking around, I'm going to have to model, UV-map, texture, rig, and animate human models. That's a lot of work, especially for one person or even a small team. Next our people are going to need to walk around on something, maybe enter buildings, swim and so forth. At least here we only need geometry and textures, but we need a lot of it. As I build my design document and flesh out gameplay ideas or story, I'm considering what kind of engine technology it's going to require and what kind of content I'll need.
How many game ideas involve a character walking around and interacting with other characters and the environment? Hint: lots.

Your story stops mattering at that point because it's not the bottleneck, it's not the hard part. Take a look at Fallout 3. I love the Fallout games. I even got some brief enjoyment out of that flop of a tactics game Interplay made. (This game marks the point where they officially jumped the shark.) Fallout 3 is immersive and visually impressive, a successful, although non-traditional resurrection of the franchise. Maybe everything is roughly the same color, but it still looks pretty good. The world is enormous and took a lot of time and work to make, but even in this professionally built game, they're repeating scenery and geometry.

All of this prattling on has been to lead up to the focus of some of my recent hobby coding. I've been tinkering with procedural terrain and procedural texturing of that terrain.
Thus far I've made a script that processes an 8-bit height map image into terrain geometry of the specified scale. You can even assign an arbitrary number of height levels with unique textures that are procedurally blended and 'baked'. In another mode it can use vertex colors to produce something more cartoony. Next I might look into using some Perlin noise to speckle the terrain with trees and rocks or other detail meshes.
My next post will be a more in-depth look at procedural terrain and my hope is that over the next few months we can explore some gameplay ideas and their accompanying implementations and requirements.

Classic Games

Most people I know, myself included, have games from their past that they remember fondly. Unfortunately, most attempts to revisit this ancient fun are met with disappointing results as we realize that not everything that was fun back then is fun to us now.
The good side of this is that you sometimes come across a game from your past that is simply timeless.
I keep thinking I'll put up some new blender material or maybe some programming goodies, but I've been lacking the time and the clarity to get any of it done. (Maybe these old games have something to do with that?) Instead I'm posting some older games that remain awesome.

The Ur-Quan Masters
http://sc2.sourceforge.net/

Dune 2
http://www.abandonia.com/en/games/36

Nethack
http://www.nethack.org/

Mechwarrior 4 : Mercenaries -- Online play doesn't work through MS anymore, but there are community mods.
http://www.microsoft.com/games/mw4mercs/
http://www.mektek.net/ -- Community site

This list could get long so I'll stop there for now.

Gun Sound Pack

Militia Defense has been updated with new sounds and some cleaner enemy tracking.
Some friends and I spent an afternoon target shooting and recorded some of the action, so I stripped out the non-essentials and packed it into uncompressed wav's for the masses.
These are released under the Creative Commons Attribution 3.0 Unported License.

Enjoy!

Game Programming With Lua

Love sold me on lua as a scripting language and provided a great excuse to learn it. As I get time I intend to keep working on Militia Defense, but I'm at a point now where I need to make some significant changes and there just hasn't been time.

Presently, what time I have has been occupied with some reading and a little work on lua-driven 3D library. I'm using SDL with Bob Pendleton's fastevents and net2. My older openGL framework used GLFW. GLFW is actually really nice, but for this project I wanted to use fastevents and net2 for network access, so it's SDL. Honestly it's just a little trickier to load textures, but beyond that they're pretty equivalent. GLFW has a higher precision timer on the platforms I use, but the perceptual difference between 3k fps and 1k fps is probably negligible, and neither one of the libraries require you to use their timer.
Right now I initialize everything and load up a lua script file that sets the video mode and has functions for the main loop.
I've started using lua's userdata element to create procedural shapes and draw them in 3D. I need to work out matrix transformations and camera functions, but none of this should be particularly daunting. At this point I figure it would be best to implement the scene graph in lua, as well as the camera, but my main concern is texturing and defining static and dynamic mesh formats.
I'm using display lists for static geometry for the somewhat marginal performance increase over VBO's, but I'll be using vertex buffer objects for anything animated. Blender will be the content generator of choice, of course.

Once I start getting tired of this I'll probably go back and re-work Militia Defense. Changing projects form time to time helps me avoid burnout and I can usually come back to old work with new perspective, so rest assured there will be updates to this.

Trying to Blog Again

It's been around a year since I last posted anything and I thought I might try to actually do something here for a change.

I've been hobbying around with a lot of 3d programming but lately I've started messing around with Love, which is a nice cross-platform 3d accelerated 2d engine that uses lua.
Content creation for 3d games can be a long, difficult process, especially for the lone game programmer. To that end, I've made a few simple 2d games if for no other reason than to say that I've made a couple of complete games.
First you'll need Love, which is a fairly small download.
http://www.love2d.org

With that installed, you can get the game files here:

My simple lander game
http://tyranny.ckt.net/land.love
http://architect.ckt.net/eq/land.love

Militia Defense game
http://tyranny.ckt.net/md.love
http://architect.ckt.net/eq/md.love

In Windows you should automatically have love associated with .love files if you ran the installer. In Linux, just run 'love land.love' or 'love md.love'. Alternatively, your preferred desktop probably has a mechanism for associating love files the the love binary. In gnome it's as easy as going to the 'Open With' tab on the file properties, adding the love command, then selecting it as default.

The .love files are actually just zips, so source code and resources can be found by unzipping them. Both games are released under the MIT license so feel free to play around in the source, but be warned, it might be nasty.
The lua backend makes it so easy to make games that I tend to just plow through them without much thought. The good side of this is, you can use your first game prototype as a design document and you really haven't lost any time.

Blender Modeling: Colt 1911

I spent a great deal of time in Blender today. Usually when I try to model something the hardest part is figuring out precisely what to model. I tend to focus on inorganic things, objects with hard edges and straight lines.
Why a Colt 1911 you ask? It's inorganic and it's a gun.

I learned a while back from some obscure tutorial that background images in Blender are a huge help when getting started. If you have a digital camera you can get your background images just by taking pictures of the front, side, and top of the object you wish to model. Since I don't actually own one of these pistols, I just did an image search and found a nice side shot.

My first step was to make a shape outline. Blender starts up with a cube at origin (0,0,0), which you can either delete or manipulate to your liking. Unless there's a trick for just adding a bare vertex that I don't know about, which is entirely possible, it is necessary to manipulate that cube in some way in order to get started. If you want, you can just select 7 of the 8 vertexes and delete them, then move the one that's left to a desired starting position and use the Extrude command (usually E).
The outline is easy but then you have to add appropriate depth. Obviously this is going to be easier on some objects than others, but if I've learned anything form fooling around with Blender it is this: Modeling requires as much patience as it does skill, especially in my case, since I really have no skill. A professional modeler might disagree, but for someone with no artistic talent and a rudimentary understanding of Blender, it's true.
I'm compelled to remark on Blender as a modeling tool. If you've perused my list of Open Source Software links to the right, you've seen it listed. The more I use Blender the more impressed I am with it. It seems like every time I use it I learn something new about it that makes using it significantly easier. Today I learned a great deal about seams and UV mapping techniques.

Anyway, back to modeling. Based on many of the tutorials I've read, symmetrical objects are created one half at a time and then mirrored. You can actually enable a persistent x/y/z mirror which should mirror your actions along a specified axis. This is probably what I should have done, however, I wasn't thinking about it and since it's far from habit, I simply forgot. I determined an acceptable width for the slide and extruded down from that to build the frame. From there I tapered down into the trigger well and the bottom of the barrel. Lastly, I outlined the grip area and gave it a bevel. I work with it in slices. Once I've made one taper, every vertex in that progression should be at a consistent and recurring 'slice' level.

I should also mention that throughout this process, the object did not have any faces defined. If I accidentally made any, usually by extruding an edge, I removed it just so it wouldn't confuse me later. The act of cleaning up after myself in this manner served to educate me on intelligently removing items from a model in Blender. When you press the delete key to delete something, you get a context menu. For the most part it is self-explanatory but I discovered an important distinction today. If you have enough vertexes selected to define at least one face and you press the delete key, you have an option to delete 'Faces', and lower on the list 'Only Faces'. If you choose 'Faces', you'll also remove the vertexes associated with those faces, but if you choose 'Only Faces', it does what you'd expect the first option to do and just removes the face definitions without removing the vertexes involved.

Once I got all my faces assigned I selected the whole thing and duplicated and mirrored it. This part is where I got into some work that I probably could have avoided. I moved the mirrored half very close to the original, but snapping vertexes has to be done one by one.
Once this was done I removed any duplicate vertexes and fixed any broken faces. Lastly, it's important to make sure your normals are pointing in the correct direction.

After messing with smart unwraps and seamed unwraps in the UV editor, I finally started experimenting and found the option to get UV's from the current projection. Cycling through the different views and manually selecting faces for the UV map strikes me as the fastest way to get it done at this point. That may change as my experience increases.
It was at this time that I ran into my most significant hurdle. I can't draw, paint, or otherwise compose images that are pleasing to the eye.
I was in a hurry at this point so I used a real photo to build the texture beforehand and then manipulated my UV pattern to fit on top of it. This actually proved to be very effective, however, in the future I'll take reference photos as suggested above and recycle those as textures.
This is getting wordy so here's a shot of the finished product.



I'm pretty pleased with it overall, especially when I look at it textured like that. Unfortunately, the naked truth reveals that my geometry is ugly and far from optimized. Later I'll have to clean up redundant faces, but the good news is that this won't affect my UV's as a whole.

SKS Update

The new stock and magazines are perfect. Everything fit and fired just as it should have and it was very comfortable to shoot. I couldn't be happier with the performance, and perhaps the sweetest aspect of it all is that the whole thing only cost around $300.