Tinker Tinker

Seems like I have found my groove right now.  I kind of suspected that there would have been the mad rush at the beginning of the project to work on it and it would peter out a bit over time.  At least now I am getting a better sense of how long this will take.  At first I was stary-eyed and had great plans and thinking "how hard could this be."  Though I knew it was not a simple undertaking, but still I did not have enough exposure to fully understand what I needed to learn.

At this point I am slowly working my way though the RTS programing book.  Though I have started to do things more in my own way then blindly copping from the text.  The primary reason was not knowing enough about DirectX to do things better than what was stated in the book.  But now I am entering in to the Logic stage of the game design and not so much dealing with DirectX itself.  I think when I am done with the DX9 version of the game, I can then start to replace everything with DX10.  That exercise will help me get a better understanding of the structures and methods of the game engine itself.  

I am trying to keep the DirectX9 parts of the program limited to a small number of classes.  That way I can just replace the underpinnings.  We will see how that goes.  But it is a good idea for now.

On the Other Side

This week is Fallout New Vegas. 

Way back when, I watched the closing credits of Fallout 2 after a very fun romp though the NorCal wasteland.  I did my typical "Talkie/Sniper" build which is how I usually play any CRPG.  At least for the first run though.  Then a name popped up on the screen.  It was a name of Warhammer GM in High School.  And I went, is that him. A few months later we met up for our 10 year High School Reunion, and I found out that it was him.  I thanked him profusely for all the time he caused me to waste :)

The Fallout series has had gone though many hands over the past 15 some odd years.  And with Fallout New Vegas it has found its way under the guidance of my old GM from High School once again. 

Like any good Fallout game there is a lot going on, and I have only just begun.  However I thought I would share some of random thoughts on the game.  Hopefully non-spoiler. 

I have poked at some of the reviews of the game and one thing is quite common in most of them.  They use the phase "Built on a two year old engine."  By this most of the reviewers are making comments that the game is "out of date" technologically speaking.  But I would postulate that most CRPG players don't give as much credence to the latest technology.  Fallout 2 was still bucking the trend when it came out still in a crude tile based 2D format.  Even the Bualder's Gate series was pushing the 2D media further.  But it isn't the latest flashy graphics that I want.  I am there to play in the world and make a difference.

Now I come from the old table top era where we were lucky if we painted miniatures on the board.  A good RPG stimulates the mind to create more than what appears.  So I don't need the flash.  I need the story and world.  I still think Spiderweb games are some of the best CRPGs out on the market.  And they are very basic in their graphics. 

I think it is kind of missing the point to talk extensively about the engine of the game being up to date. 

Now being stable and with minimal bugs is a different story. 

Being an old gamer, I started with Bethsoft games with Daggerfall.  And for the most part I have had the same impression of any Bethsoft game.  Great story and world.  Lousy engine :).  But it is always big and fun.  Just quirky at times. 

Fallout New Vegas is much more of that. 

But I would not want it any other way.

Now where is the bloody sniper rifle.

Meat and Potatos

So I have finished what would be the foundation part of the RTS programing book.  That is mostly on textures and skinning and the heavy lifting of DirectX.  Now it is time to put all the pieces together.  First though, I need to take a step back.  The code in the book is fairly simple.  In that there isn't any real resource management, and much of the initialization information is hard coded in.  The author does state that this is intentional just to focus on the aspects of the game programing, and not what would be considered more generalized programing.  Basically the resource manager is left as an "Exercise for the Reader." 

Fortunately, this is where I can start re-using from the MazeMover project.  I did create a INI file parser and simplified resource manager for the SDL objects.  Now to adapt both for each other. 

This is were things get creative.  I have to now look at both sets of code and figure out what each is really doing.  So right now it is a lot reading and poking and seeing what has to be done.  This is were the power of code encapsulation really comes in to play.  I can now muck around with all the various implementations but still present the classes as they are in the book.

Still it means pulling some parts out and fitting in new ones, but if done correctly then the application itself does not change. 

Flying though the sky

So I have finished all of Chapter 4 and I am on the final exercise of Chapter 5 of the RTS programming book.  Right now I am have an issue with the vertex shaders and the terrain.  Once again, this will require going though the example code and taking a look at mine to see what little step I have forgotten.

So far it is just a fancy terrain map with some functions for later use.  Most of the problems I have encountered so far usually stem from tying to understand the subtleties of graphics programming in Direct X.  It is kind of interesting, I am not much of an artist so I don't know much about creating texture files and actual models.  However, I know all the math that goes on behind the scenes.   Matrix multiplication and inverses.  Using dot products to find projections and distances.

I am getting in to DirectX.  Well at least I am enjoying programming 3D graphics.  It just makes sense.  Put things in the world, then "do the math" to show it on the screen.  I was thinking about writing my own 2D Isometric view engine, but being the engineer that I am, I would rather use someone else tools then build my own. 

It is the little things

After beating my head against the wall, I called in a friend to help look at and debug the code.  If I were in a collaborative environment to begin with, I would have asked for another set of eyes sooner.  But after lunch at a nearby sub shop, I had him poke at my code.

Although the exact error was not found at that time, he did show me some more tricks working with Visual Studio and at least gave me a fresh perspective on where to focus my search.  After narrowing down the location, I was able to go back to the example code and figure out what I was missing.

In short, it was the typical "off by one" error.  In this case I was using a <= when it should have been <.  So after that was done, a few more errors in math were found in the rendering portion and finally I had completed the exercise.  Now I have half of a nice random terrain generator.

This is designed for an RTS so it has peaks and valleys.  I am not sure if I will have non-flat terrain in YAR itself, but it other aspects, such as path finding and object placement will be useful.  Orginally I was thinking of doing a simple 2D iso tile system, but it seems fairly straight forward to do this as a terrain/texture mesh over a 3D surface, even if the surface is going to be flat.  Since most of the heavy lifting has been done in DirectX (and OpenGL) like matrix transformations and what not, I might as well stay here as well.  I will be easier to make it simpler later.

Hitting a New Wall

I am slowing working my way though Programming an RTS Game using Direct 3D.  Only on Chapter 4 but I am taking my time to go over the code in the book and the full code on the CD to understand what I am doing.  Not to mention going back to some DirectX resources to see why I am doing what I am doing.

However, I have hit my first real stumper.  Some how I am getting corrupt memory in my initializations.  Annoyingly it happens at slightly different points in the code when I run it.  But the error is some type of heap corruption or other misaligned memory.  Unfortunately I have yet to see where the real problem is.  Also the example code itself runs fine, yet mine does not.  Now being the good learner, I am adding my own coding paradigm to the example code, so there are differences.  But I am not sure what difference is causing the error in question.

The upside is that I am getting more familiar with the Visual Studio Debugger.  It is kind of fun and for the most part I have been able to figure it out.  Right-Click is your friend.  Now I am still a little green trying to read some of the raw assembly code, but I got though reading UNIX trace/truss commands so this will just take some time to start seeing the patterns that have useful information.

FORTRAN is the Latin of Engineering

If you went to Engineering school in the 80's you most likely had to take a programing in FORTRAN class.  As I started in 1989, I too took FORTRAN.  Two years later, entering freshmen learned C instead of FORTRAN.  Granted I also took the C programing class as an elective, but FORTRAN was the required language.  Also I think my year was one of the last years to have a mechanical drawing class with actual boards, pencils and T-Squares.  And although I had my father's slide-ruler, we were allowed to use electronic calculators. 

So learning "old" technology is very comfortable for me even if it is academic.  Such is how I feel right now working with DirectX9.  It is on the way out since XP is finally no longer allowed to be put on new systems and soon that will be moot since it wont have the support of new hardware anyway.  I should be learning DX10 or DX11.  However there is a lot more written and available for DX9.  Currently most of the books of the variety "Programming $GAME with DirectX" are written for DX9.  So I have a lot more examples to pull from.

Now in my case $GAME = RTS. Though I do have access to the online copy of RPG as well.  So between the two of them I am getting a good idea of all the moving pieces that go in to a fairly typical, though small, game that I want to create for YAR.

I have found learning "old" methods very useful, though it has pigeon-holed me a few times.  On the other hand, I am one of the people that can bring grognards up a few centuries and use at least more modern equipment then what they were using.  Also since I am spending as much time learning the concepts of 3D graphics programing (like texturing and  transforms) I can use all the examples I can get.  My quick look in to DX10 shows that the concepts are still there but the implementation has changed (like Vertex and Index Buffers.)   You still have to know how to use those items from a conceptual standpoint regardless of the API.  When I poke a OpenGL sometime in the future, I will not have to learn basic 3D programing.

In Scottland they speak English

There is English and there is English.  I am from the US and have what is as close to what is the "Neutral US Accent."  This is the accent of the majority of news casters and for the most part the non-metropolitan east coast accent.  Being a geek I grew up with Monty Python and other British TV as well as spent some time in Australia.  And for the most part I never had an issue understanding most other non-US English speakers.  The vocabulary may change, but I could still understand what the words were said if I did not fully understand the context of the words.  Then there is Scotland.  In theory they speak English, but it is fairly difficult to tell at times. 

What does this have to do with programing?  Quite a bit.  There is C and C++ and for the most part it is all the same.  However everyone puts their own accent on it.  Since I am now learning DirectX, I am learning to understand the vocabulary used by Microsoft API base programs and able to translate in to my own understanding of the languages.

However, I am doing it in the most curious of ways.  I started with the DirectX 9 Tutorials from MSDN as I mentioned before.  But there was quite a bit of details missing.  Now I am going though Programming Role Playing Games with DirectX by Jim Adams.  The particular edition I have uses DirectX 8. Of course in reality I should be working with DirectX 10 or 11. So here I am flipping between that book, the MSDN site as well as the occasional Googling to see what other people have done.


I feel like I am having to translate English to English and back in to English again.  If Russian were in the middle, I could have gotten: "The Vodka is strong, but the meat is rotten."

Looks like a Duck

It has been a few days playing with DirectX and the tutorials from MSDN.  As tutorials go, the MSDN collection is fairly weak.  Lots of steps missing that you need to go research or already know.  Very little in the way of explanation.  On the upside it was nice to know that I could fill in the holes myself, and that I have learned quite a bit so far.

Like the Win32 API, DirectX (at least version 9) is much closer to C than C++.  Even glancing up at version 10 and 11, it is still very much the same. One of the scary parts I found was:

if(FAILED(g_pVB->Lock(0, 0, (void**)&pVertices, 0)))
        return E_FAIL;

Egads.  Casting void pointer to pointer of a reference.  Perfectly legitimate C code, and quite common to see.  But always a construction that makes me curious about the "power" of C when you need to go though some interesting hoops to pass the data you need around.  Ideally this would be a rare thing.  You take care of this level of detail once in your lower level engine code and not worry about it when you are designing your game at the upper level. 

So now to find some more in depth information.  Looks like I am finally signing up for Safari Books again.  Primarily because the one book that is recommended to me is out of print, but is available there for reading online.  This way I can take a look at other books as well and determine which ones I will want to purchase for my own library.

Character Is What You Are In the Dark

The past few days have been adventures in to the Win32 API.  After all the elegance of playing with the STL and creating classes, I have gone back to fairly basic C style coding.  Not only that, C-style coding with Microsoft style tags and means.  I can see the various Visual Basic influences as well as some other old school language methods. 

Now to be fair, this API has been around for over 15 years.  So it does pre-date the formalization of C++ and it is based on the early DOS methods of doing things.  The API is easier to deal with than pure C.  I do get more useful functions like WriteFile() and CreateFile() instead of write() and creat().  So when I was looking around for good resource books on the topic, the one that everyone mentions is Programing Windows by Charles Petzold.  The book was last updated in 1998.  Normally I am very leery of technical books over 5 years old, but it seems that the API has not changed too much since then.  What little has been added is documented well enough on the MSDN website.

It is the Microsoft Foundation Classes (MFCs) that are the "object-oriented" programing tools for windows, and that is what brings you back up to C++.  (Or Visual Basic and C#)

At this point, I got what I needed from the tutorial, that is enough information to read the road maps and signs for playing with DirectX.  Now I am no longer befuddled by LPTSTR or HWND.  I can see what they are obfuscating.

A New Begining

After putting a stop on Maze Mover, I have decided to take a few steps back and learn some basic Windows Programming.  Well at least the Win32 API.  Mostly this is because I am going to work with DirectX so I should get familiar with the Windows based calls. 

The SDL API did some interesting changes on top of the standard Win32 API while using Visual C++.  Then again SDL is meant to be more platform independent, so it might have to step on some established toes.  Right now this is my suspected reason for the conflicts I had with Python. 

Now I did some of the basic "Hello World" apps from MSDN, but it was a little lacking on describing all the Window-isms.  Mainly what are all these typedefs they have running around like "LPSTR."  After a bit of googling I am now running though theForger's Win32 API Tutorial.  And it is doing what I want.  Telling me what all the little bits mean.  I was at the point where there were too many foreign items I had to figure out and no Rosetta Stone to start determining my translations.

This site looks to be as good of a start as any.

Project Review

At this point, I have touched on most of the key traits I wanted to cover with Maze Mover. It isn't the complete Pac-Man game, but it has the elements I wanted to include and at this point I have gone as far as I would like with the current design.

So here is a bit of a sum up of what I wanted to do and was able.

• Separate the graphics/game library from the programming.  I did create a whole layer of SDL classes that managed all the low level resources without needed to make SDL library calls at the higher levels.  Though that is not complete true.  I still have to make the direct reference to SDL in the Event Handler section.  However, I suspect that I will continue to use the event handler functions directly of any library.
• Utilize class inheritance and polymorphism.  Every game object is a first or second descendant of the base YAR_Entity class.  For those of  you are serious game programmers you will most likely be muttering that this is a rookie move.  And I would agree.  Yes, logically it works but it does break down after a while.  For the next step, I think I will consider an attribute based model.  That is each game object is a collection of game attributes that it will use. 
• Primitive Resource and Entity manger.  For each resource and game object, I placed them in a simple map of pointers.  That way when a game object needed an already open resource, or information about another entity, it could query the map.  The improvements I would like to include here is possibility utilizing "smart pointers" as well as designing the list to handle more dynamic creation of game objects. (see next)
• Static deceleration of game objects.  Right now, I had to declare all my objects at initialization at run time.  This was a limit of the current design, the resource managers, and my personal knowledge at the start of this part of the project.  Addressing the two previous bullets should allow me better dynamic object creation.
• INI file reader. This was a nice little exercise in a simple file parser.  I did allow for multiple data per key as well as multiple lines of data for one key.  I considered writing either a XML or JSON parser but in the end stuck with simple INI since at this point, I don't need arbitrary hierarchical data.  Though I am limited by having unique keys within each file. 
• Tile Board.  I was able to create the map/board in the INI files and thus be able to load different maps depending on the INI file used.  Currently the map file has to be coded in from the start and I don't change maps in the game itself, but it could be done.
• Pathfinding AI. For the most part, I was able to create a means of having the Ghost find the shortest path to the player. However, there is a current problem with how collision and placement on the board is calculated such that ghost could get "stuck" by not being completely in the next tile before changing directions.  I have the same problem with the player sometimes not fully being in a tile at times.  This is partially a design issue since both the player and the ghost are larger than the actual tiles.  So there can be some issue with determining the true location of these objects.
• Windows Console.  I was able to redirect the SDL stdio to a windows terminal.  This was going to be used so that I could embed Python in the program and query and modify objects from the console, but as I mentioned before, there seemed to be some issue with SDL, Python and Boost.  If I am going to stick with SDL, I suspect that I will have to take the time and rebuild all of those libraries from scratch.  At the time I started none of them were explicitly build for Visual Studio 2010.  Independently they worked fine, but somewhere when putting them all together, something conflicts. 

Going forward, I think I will start dabbling in to DirectX.  This means spending the next week or so running though a few tutorials.  Also I should brush up on MFC as well, and write a simple (or not so simple) Windows App. 

I have a template of a game design document that I will also start to work on.  So August looks to be planning and some more tutorials.  Even though not much direct coding will be done, there will be design going on.

Back to the grindstone

The hectic month that July seems to be is finally over. With work sending me off to different locations and Comic-Con, it kind of disrupts focus. Granted, I should have still worked though it, but a few other games got my attention. While at Comic-Con, I did get to run to one of my game designer friends, so that too has help rekindle my fire.

Okay, now back to the project. Maze Mover is at a curious juncture. I am running into issues with my design. Namely that for the most part no entity has any awareness of any other entity, except when I check for collisions. And even then I can only consider pairs of entities at a time.

The problem that this creates is that the "Ghosts" need to know both the location of the player and have information regarding the board. This during the update function, I do not have the information to find the path.

Also in this regard, I don't have any means yet to create new entities on the fly without declaring them when the game starts.

Right now, I am adding a few hacks on top of things to get it to work. But after I get this done, I think it will be time to scrap this heap and then start working on the main project. The first part of that will be start with a simple design document. Sure "Rogue based game" sums up quite a bit, but there is still a lot that needs to be done.

It feels good when I stop

Well after a week of testing and rebuilding libraries, I have come to the conclusion that python and SDL have issues. For now I will forego using Python with Maze Mover and now just focus on getting some simple path finding and AI functions hard coded into the game.

I was going to move off of SDL eventually, but it may be time to do so after I get enough of this game working as a test project.

Now to determine if I go to DirectX or OpenGL. Both are industry grade libraries, though since I am doing most of my work on and for the PC, I may just stick with DirectX. I am still at the general stage and I don't suspect that learning OpenGL after DirectX will be too much of a challenge. Personally, the graphics library is just that, a library. Most of the work that I need to do will be on top of that anyway.

Still I won't make the decision till after next week. There is Comic-Con to deal with and I will finish up Maze Mover (at least to the point of learning what I want to learn from it) by then.

Immovible Object

Not programing objects, but really annoying obstacles.

I have hit a bit of a major road block with the current Maze Mover project. Something between Visual C++, Boost, and Python isn't working with the project. It seems there are two problems, both of which need to be solved in the long run.

First is the boost-python libraries do not "out of the box" work with the python debug libraries. I have been looking at the various bits of documentation and I have yet to create boost-python using the python debug libraries. Of the two problems, I suspect there is a solution for this as I delve deeper in to the details on building boost libraries. This is where I wish I did have some colleague or collaboration group that had all these tools in place so I would not be spending time just getting the tools to work. Granted, this is not uncommon in programing. Keeping your tools up to date is just what is required.

The second is that when running the standard Python library, which works with boost-python, the function used to create an interactive python session during the running of the program does not work correctly. The function does not error out, because it senses an EOF from stdin, even though I have not done anything. I suspect there is an issue with the stdin filehandle. It works with one library and not the other. And I have rebuild both.

Now the ever fun aspect of trial and error. Trying to find that one component that is causing the error. Most likely spend a full day just rebuilding test cases.

Things going Boom

Aside from being on travel this week for work, I had the unfortunate event of my laptop's hard drive dieing on me. The annoyance about losing "data" was minimal. I have multiple copies of all my critical data in various locations. All of the "YAR-Project" work is up on the Sourceforge Subversion server so nothing was lost there. A few documents that were in flux were lost, but I have hard copies of them so I still good to go.

Not having my laptop in while in a hotel room left me to the whims of broadcast TV to relax from the day. Of course this meant I was not able to do any work this week as well. However, I did get to to meet up with an old friends and got enough encouragement to keep following my dream.

This weekend I should have everything rebuilt on my laptop to continue.

Tower of Bable?

As you may have noticed, not much on the "new" programing this week. That is because I had the joy of flying around to perform IT related upgrades. Although there is a lot of time wasted while traveling, not much of if is directly conducive to getting any quality programing. I do have time to read more so I have started Effective C++. In short this will be a book that I will read again in the future.

What has been difficult is to resit tearing down everything that I have done already and start from scratch. Already I have a host of ideas that I would rather do. But for now, I will stick with what I have and get the Maze Mover game out in some form. Mistakes is where learning happens.

I am slowly making process to integrating Python in to the game. Lots of trial and error and figuring out what libraries are needed where. I had to build the Boost libraries from scratch since they currently don't have an explicit build for VS 2010. But that was not too bad. Just taking time to get all the paths in place.

This is far from the first time I had to build the tools I needed to use in order to use them. Before I made my first production level Perl script for managing back-ups, I had to debug the build and install of Perl on a Sparc 2. Now a days, things are fairly standard enough that I don't mind doing compiles. But back then there were quiet a few things that you may have had to tweak by hand in the build script and makefiles that it could take a day just to get the compile to complete.

It was very nice just to type "make" (or in this case "bjam") and let it go its merry way. Add the path to my VS config and I was underway.

A Coal Miner Debate

Over the years I have classified many arguments on the web as Coal Miner Debates. Unfortunately my reference hasn't caught on yet. In the circle I surf, one of the most common topic of debate is "Is $GAME and Role-Playing Game?" There have been many variations on the theme depending on the boards in question. The most common variant I find myself in is "Is $GAME is MMORPG?"

Keeping this closer to home, there is the specialized debate on "Is $GAME a Roguelike game?" The strange thing is that given that Rogue itself is over 30 years old, there is quite a bit written on the topic.

Personally, I go for very open definitions of games. Power grubbing Munchkin gamers and over action Role-Players both play D&D. They play in completely different styles but both are still playing a Role-Playing Game. In my world, any game that has some formal statistics per individual character that the player controls and that affect the interaction with the world is a RPG.

But now we get back to today's debate. Is my game (or more accurately 'will my game be') a Roguelike game?

For the purists, my game will fail two tests. The first test is that I will not be Text Based. I am doing this first in 2d with SDL, but I do plan on experimenting with OpenGL and/or DirectX as well. May not get to a full 3D rendering, but I do plan to play in the realm for a bit.

The Second test I want to fail is being "Turn-based." I would like to get to doing things as much in real time as possible. However that will depend on how I develop my RPG underpinnings.

Therefore, to be more accurate, I am working towards a Diablo Clone. When I first played Diablo when it came out "way back when" I thought to myself, this is a graphical NetHack. Even further back, I played NetHack on an AT&T 3B2 system. I never played the original Rogue, so my personal point of reference was NetHack. Anyway, I though it just another rogue game with pretty graphics even at the end when I stuck the Amulet of Yendor in my head. The main difference was that I could not be a Tourist with my camera and magical Hawaiian shirt of protection.

For those that say Diablo is Rougelike (like me) then my game will Roguelike. For those that don't, well pbbbth!

Snakes and Ladders

The last few days have been full of sound and fury and signifying nothing.   Okay, not that bad, but I was hoping that I would have something more tangible to show.  The last few days have been going though various amounts of documentation and web searches to understand the how and wherefore of embedded Python in C++.  I expected it to be a bit easier then it turned out to be.  Mostly because it had all been done before and I should have been able to just plug it in and go.

Downloading Python for windows was the easy part.  But building my first tutorial app proved to be a nightmare of wrestling with the hidden foibles of  Visual C++ and the stock Python windows install.  I can hear my old UNIX self snickering in the background.  I knew my way around Makefiles, but figuring out Visual Studio properties took a bit of fishing around.  Now Python is built with Visual C++ for Windows, but its include file uses a special debug library if you are in Debug mode and that library is not included in the install package. 

The best solution is to download the source and build the debug version.  Fortunately, there are some other useful examples and demos in the source that made the download more palatable.  Also it did just build straight up even though it had to convert from a Visual Studio 2008 to Visual Studio 2010 Project.  Event then it took a while to figure out that you need to used the Debug version of Python if you want to look at your debug version of code.   Anyway, that was a few hours of frustration and trail and error.

The rest of the time was going though the documentation at Python.Org.   I want to get an idea of what is really going on in the back end before I go and use something like Boost Python Library.  Actually, I am trying to stay away from Boost as long as possible.  I want to know why it is easier with Boost.

Of course it probably does not help that I am also learning Python itself at the same time.  However, from a pure scripting standpoint it is fairly straight forward.  I still should spend some time on how it deals with objects, and some of the more interesting aspects of memory management, but otherwise it is fairly similar to other scripting languages. 

In other news, I have finished yet another text book, Game Engine Architecture by Jason Gregory.  My review of it will be sometime in the next week.  Next up is Effective C++.  Also there are things brewing in the background that may make this more of a real project.  But I need to do a few more things before they be revealed.

The Changes of Style

I have always been a fan of seeing the development of ideas though common media over time. One of my favorite examples it Issac Asimov's Foundation Series. The first set of books were done in the late 1940's and then more books are added in the 1980's. What I found interesting is that both books represent more about the culture at that time then the future. How women are treated in the original trilogy is much different then in the later books. But they reflect the notions of the time they were written.

With respect to programming we have the same thing. Coding style and thought has changed quite a bit even over my 25 some odd years of exposure. And none has changed so much as C and all its offspring.

K&R is the book on C programing, at least according to programing purists (or gorgnards). It is authored by those that did the primary development of the language so they should know what they are talking about. One interesting note about K&R is the code examples. On one hand, they are correct in that they do what they say. They very concisely solve the problem at hand. But conciseness in coding isn't necessarily a virtue today.

Back in the day, a programmer flexed his muscles by writing a program in the fewest lines (or even characters) as possible. What you would get were these curious little nuggets of brilliance. Yet in the long run not very useful. Part of this came out of the days when lines were done on punch cards and so "smaller" programs were more efficient. This is also back when people "wrote programs" and not "develop software." Software development was done back then, but primarily from large firms like IBM or the DoD. Then again, back in the 1970's and early 80's large firms were the primary consumers of Software. Personal Computers and Gaming Consoles starting bringing software to the masses.

Now there is a whole field on the process of developing software. And as such, concise and clever coding is not as much an asset in its own right anymore. Take this little piece of code from K&R (p 115):

while ( --argc > 0)
printf("%s%s", *++argv, (argc > 1) ? " " : "");
printf("\n");
return 0;

This is a simple echo command. Except for the main() and {}, that is it. It is elegant and concise. And if I were a Project Manager and a coder gave me this bit of code, I would pat them on the head, give them a treat for "whose a clever programmer?" then beat them until they re-wrote the code with out too many operations happening in one line. Granted if the project were at the "extreme code tuning phase" where you need to pull out all your tricks, the beating may be a little less sever, but at the very least some better formatting and not manipulating argv and argc directly would be preferred.

For example. A "good" programmer knows the difference between i++ and ++i. Sure on a line by themselves they do the same thing. But if in the above code we had argc-- and *argv++ the output would be incorrect. The program name itself would be included along with the rest of the command line, it may try to print an undefined argv.

Today, you need to write software so that less qualified programmers could understand it and support/change it after you are done. Most prevailing thoughts on style, readability, and supportability would at the very least insist on moving all increment and decrement operations to their own lines. The embedded conditional in the printf is questionable. It is small enough to be quickly understood, but there is an opinion that you should not embed any arithmetic in your function calls. I personally would leave it in there. Unless that same computational result is needed elsewhere.

My style itself is changing. I started off doing procedural programing in Pascal over 25 years ago. In college I learned FORTRAN and studied mathematics so the use of i, j, and k as iterators and vector notation was just natural. C++ was just still in development and not fully standardized. Object Orient Programing was a nice idea, but at the time too much overhead to do properly. Now a days, both compilers and hardware have gotten to the point where the extra overhead can minimized or even eliminated.

My code has gotten more verbose. I use longer variable names and take time to create relatively good class structures. One thing I am finding out is a lot of the common problems have been solved and I don't really need to write them myself anymore. For example, C++ has a standard Double Linked List implementation that has been tuned over the years by many people. I can now just say "Make me a list of foo" and boom, I have everything I need.

A Maze ing

So here it is...Sort of.  The beginning of my Pac-Man like game.  Still needs quite a bit, but this is fairly significant. 

First off, I was able to use the tile board from before, but I the player token (Pac himself) is larger than the single tile size.  So I had to do some adjustments to the collision detection for the board.

Also there was some rework to get all the Resources and Entities to use my INI file reader to load in the information.  Since the board is just a collection of tiles, I can whip up a new one by changing the INI file.  However, I don't have a mechanism to load a new level.

Lastly I still need to get the tunnel to work.

That is all the small things to fix.  I still have to add the ghosts along with their own AI.  That should be fun since there are two major parts for me to learn.  First is looking at basic AI logic itself.  Fortunately the Four Ghosts of Pac-Man have fairly simple AI and they are somewhat well defined.  I just will have to understand the math and not figure it all out on my own.  The second part is adding the AI logic via a scripting interface.  I am leaning towards Python over Lua since I have more practical uses for knowing Python.  But I suspect that after I do it for one, most of the logic will carry over for the other.  Just a different syntax.

I would like to have this done by July 4th, but that will depend on how much time I have to spend traveling over the next few weeks.  My company is sending me off to three different regions for IT security roll out.  Joy.  Travel is good for reading, but not so good for coding. 

It is all about Choice

This weekend I finished my first play though of Alpha Protocol. Suffice to say it was a short story. However, it is not really a short game. One of the big things touted about this game was that it is all about choice, and their are no bad decisions. Most RPGs that have any moral choices tend to favor "Good" over "Evil" choices. The Knights of the Old Republic series had a really big distinction between light and dark side. And it seems that Dark Side characters had fewer options in the long run then Light Side characters.

However, in Alpha Protocol there is very few (if any) really good v evil choices. I think the only good/evil choice I had to made was the level of lethal force to use on civilian guards that are shooting at you.

Still I think I may do something that I rarely get to do with a RPG and that is play it all the way though twice. I am already over halfway though the second run. And I am seeing enough differences to still make it fresh and exciting.

All in all it delivers as promise. An excellent Spy Base RPG. And anyone who enjoyed the Deus Ex series or the Mass Effect series will very much enjoy Alpha Protocol.

Now the But... :)

My criticisms of the game are general and to an extent would also apply to Deus Ex and Mass Effect as well. I have been of mixed mind on the FPS style RPGs. I personally prefer third person "turn-based" games in the vein of the old Fallout and Baldur's Gate games. Yes, I enjoyed Fallout 3, but I preferred the style of Fallout 1&2. I would consider Dragon Age: Origins also to be "turn-based." Loosely speaking any game where you can pause and queue up orders/actions is what I would consider "turn-based."

Second, as much as it makes perfect sense and was executed as well, I am also not a big fan of Hub-Based missions. It lacks the open exploration that I always enjoy. The mission maps are still fairly linear in that there is a start point and an end point even if there are a few different routes though the level.

These are part of the reasons why I am developing YAR the way I am. It will have the elements that I enjoy the most.

Row, Row, Row Your Boat

The past few days have been fun whit C++ streams and dealing with file I/O. Way back when, I remember dealing with char arrays and char pointers to handle text information. But most of what I recall was writing my own tools to crudely manipulate strings to at least do some basic tasks.

In my first career related job, I was introduced to the world of Perl. And lo did string manipulation just work as it should. Not only basic string manipulation but regular expressions so that you can define patterns that can be found and modified. Quite a bit of systems administration in those days was parsing large amounts of text/log type data and making sense of it all. Doing any of that in plain old C would have been not fun.

When C++ first came out, many of my programming colleagues mentioned that the first thing they each did was to create a string class. As such strings are now "Standard" in C++. (That depends on if you consider the STL truly a part of the C++ standard or it is a standard unto itself)

From the file side, there are now streams. Now, I did not have as much of a problem with file handles and reading and writing, but now there is a means of consistent manipulation between files and strings for I/O.

With that all said, now it is time to create a DataFile parser. For now I am creating a simple INI style parser. But with a few extra features such as multi-line values and dealing with multiple values per key.

A Polar Bear...

...is just a Rectangular Bear after coordinate transformation.

The nice thing about traveling cross country is having lots of time to read. My current text is: Game Engine Architecture. 6+ hours flight time each way means quite a bit read even with the occasional cap nap to digest the information.

By the time I got back to San Diego, I had finished just over half of the text. One thing that is making this a fairly easy read even as a upper division college text is that all the complicated math is something that I have already seen, just not in the context of gaming. I studied Mechanical Engineering for a while in college before ending up with what amounted to a applied mathematics degree. Vector math was done all over the place in both Statics and Dynamics. Not to mention that I also took various levels of advanced linear algebra though out my time in college as well.

What I recall from all of this was that it is very easy to succinctly express various concepts of rotation and translation in terms of vectors and matrices. However computing said expressions was a lot of tedious work. Even a dot product of two 3D vectors is 5 operations. Start adding in matrix multiplication and you start getting a lot of math going on.

In engineering, most of you learn is how to avoid doing lots of math by finding short cuts. And computer engineering is no different. In gaming it all comes down to getting an output close enough fast enough that people don't notice. We get to play with the fact that the human eye cant really see much faster then 20 Frames per second.

In the end, many of the concepts I have read about so far in game programming haven't been completely new. Math is math. Just the application of the math changes.

Warren Street NYC

My first real job as a Systems Administrator was at Salomon Brothers at 7 World Trade Center. A short walk north from the office is Warren Street, home of two of my usual haunts.

First was The Raccoon Lodge. To call it dive would be a complement.

Doing things the Hardway

(Okay, so I actually did some work on the project since Alpha Protocol arrived, but it arrived early)

I am starting in the next major component of the project. One that is fundamental to all games (and even most software projects) and that is data file reading and writing. Not just simple file I/O, but how to save and reload the various state information regarding the game itself.

I have done data and configuration file parsing many times in Perl and Shell. A simple Mark Up parser can be done fairly quickly with a few well place regexes and hash in Perl. With a few "Hash of Hashes and Lists" and i can easily slorp in an XML file for processing.

Now I am in C++. None of my old tools are there. I have fopen() and getc(). Okay, it isn't that bad. Using the STL I do get strings and streams. However the implementation is new to me. So here I am going over documents and examples to figure out how these things work. My goal is to make a JSON and/or XML parser. (IMO they very much the same thing, just with different brackets).

The interesting thing about C++ is that there are well supported add-ons. Namely the Boost libraries. There are all the old tools I am used to having in Perl. But I would rather still work with the streams myself for now just to get a better understanding of what is going on.

This brings me to why am I doing this in C++ and wanting to make my own engine from the ground up. If wanted to create a game, there are many components that can be gotten for free that do everything that need. But that isn't the point of this project for me. I want to truly grok game engines.

It is how I work in IT as well. I have quiet a bit of breadth in the whole technology stack from bits-on-the wire transmission cable properties to high level report generation tools for business intelligence. I would not really classify myself an expert in any of these fields. But then again I classify an expert as anyone who knows more than me in a particular field.

Also C++ is the "Mother Language" of most other game design environments. (C itself being the grandfather) Even my friend Perl is very C like. Off to the side you have Java and Visual Basic and they have their uses as well.

Personally, I am fairly language agnostic. So another personal advantage of C++ means I can work more under the hood to really understand what goes on behind the scenes for various aspects of game mechanics. In the recent book I picked up on Game Architecture, it had three dimensional polar vectors and ODEs. I got excited to see things I haven't seen since Engineering School. But then I like math :)

It has Arrived

Alpha Protocol has finally arrived on my doorstep. So for the next week or so I will be entrenched in all the wonder that is the modern spy. This means not too much will be done programing over the next week or so as I get though my first burn of the game.

Having been around a while, I know how I play games. Which is good because I can easily plan my life around releases of games that I expect to play. Fortunately there is only a few games a year that I buy and play. Dragon Age and Mass Effect 2 were the more recent ones. Though I did dabble a bit in to Fallen Earth and D&D Online.

Now, being a good project manager, I already planned for this. I have pre-written some commentary pieces that I can publish over the next week. To be demonstrate my level of preparedness, even this particular posting was written a week ago. I really don't want to be interrupted when I am gaming.

Now Alpha Protocol does have some part to play in the YAR-Project. I went to high school with one of the designers over at Obsidian Entertainment. He was the GM for our Warhammer Fantasy Role Playing game. Many a Saturday afternoon was spent drinking coke and eating Pringles Lite while battling Sakven and other dark horrors he created.

This project started because I was sort of envious of him. Well envious of a few others of my classmates and peers that were in some type of creative occupation. I wanted to correct that. Over the past few years, I have attempted a few different ideas. However it took some time to put my finger on something that both excited me and was something that I had a good amount of skill already. And the result is The YAR Project.

So with that said and done. Let me go and play my game in peace :)

Bangging Two Rocks

It has been fairly productive over here at the project. With the Holiday free to program, and a fairly quiet day today, a good deal was accomplished. Monday started with a good deal of rework on the Entity classes as well as adding a hash_map to keep track of the various resources that will get loaded. Most of that was done to put off the inevitable dread of dealing with Collision Detection and Management.

The dread was trying to be too cleaver again. At first I was trying to abuse polymorphism and type casting to figure out if I am comparing circles or squares. Though in the end I decided to make it fairly explicit. Each Entity contains a vector of rectangles and circles that can be used to define its collision geometry. Then I compare all the rectangles of the first entity with the rectangles and circles of the other then all the circles. It works well enough and seems to run fast enough. With two mobile objects and a background tile board, I can hold between 70 and 100 FPS depending on which system I am testing on.

I think in my haste I have jumped between different naming schemes for variables. While quickly writing up new functions, I started using shorter and shorter parameter names. Attributes in classes are still fairly verbose, but I took a few abbreviation with parameters.

Then next task is Data File management. Every entity and resource has a Load call, but for now it is just static configurations. Now it is time to figure out a data file format as well as creating a parser to read those files to configure the entities and resources. I think for now I will go with a simple Key-Value system. I used these all the time in Perl, but it had built in regex support as well as much more flexible Hash data structures. Still I would rather a human readable file then some tightly woven string of numbers.

After I get this up and running, I may take a look at building an XML parser. Sure there may be some good ones pre-made, but I could use the time to get familiar with XML by itself.

I also may take a side trip to learn Python and start doing integration there as well. Sure the gaming folks may tend to favor Lua, but Python has some other uses as well for me. Besides it is the integration of scripting languages in to my code that is the trick. The actual scripting language isn't that big of a deal. I have learned many programing and scripting languages already, that it is matter of new syntax.

This should keep my busy for a while. My goal is to get enough foundation in place that putting together a Pac-Man game is just adding some sprites and glue.

Holiday Times Means Lots of Quiet

So it is a day off from work and having no real Memorial Day plans, I am looking forward to many hours of uninterrupted programing. I just finished my breakfast and morning reading of C++ for Game Programmers and about to dive in to the code.

Lots of ideas to implement today. So we will see what I get done. First I need to finish collision detections between the game board and pieces on the game board. Also I need to create some form of data file loading function. In the "wish list" today is to create a File, Resource and Entity Manager systems. At least get some foundation ideas in place.

Now once I get the collision system in place, I would have enough to work on my Pac-Man game. However, much of the information would have to be hard coded. So at the very least I need some level of data file system.

Aside from the lower level resource management items, I will need to create a AI system as well. Pac-Man is a good AI programming exercise since you need to create 5 different AI scripts.

With all the other events I have for June, I plan to get a release version of Pac-Man done by the end of the month. But if I am lucky that may come out sooner.

After that, I suspect that I will have most of the tools I need to start working on YAR itself. Or at the very least work on additional foundation items such as adding scripting support and developing the RPG aspects of YAR.

So much to do today before the quiet is gone.

Getting too clever

The nice thing about holiday weekends is that you can get so much done. Fortunately this gave me more time to program. Today was an exercise in possibly getting too clever. Yesterday I stumbled on to making my own operators for custom data types and I may have gone a wee bit overboard. My little old position structure is now a full class with addition, scalar multiplication, equality comparison and even a funky divisor for dealing with pixel movement per frame refresh.

Also I created structures and objects doing collisions on circles and rectangles. This way I can just do Entity1 < Entity2 to see if they overlap for collision. It got a little more convoluted then I wanted. But now I can define an object as a collection of circles and rectangles and see if it overlaps with another object of circles and rectangles. It is crude and will work.

There are better methods out there, but I will have to read up on them. I think what I need to find is a good Game Algorithm book. Something that will help with advance collision detection, AI programing as well as other more advanced topics.

However, what I have now will be more then adequate for what I have in mind for YAR. Everything I have is still really a 2D sprite in one plane, so circles and rectangles should be good enough. I will need to figure out how to do the map collision for Pac-Man. Defining all the walls as rectangles could work. I just should have something that tries the closest walls first. Though I may do it though tile definitions. Each tile has a predefined set of exits to other tiles.

Overall it has been a good week, even though I don't have anything to release this week. I might have something done over this weekend.

Off the Path

Today I did a small detour in to the Microsoft Windows API. Just did the old faithful Hello World, and a simple screen form. I have never been a fan of the whole "Design the interface then do the code" style that most form builders use. And Visual Studio is no different.

Though part of the problem in the past is that I was trying to learn the language as well as the Form Design. The design tool hid too many things going on in the background. Now, I am not struggling with the back end language. I can look at the code and see that is C++ structures in the MS style. Since I know what is really going on in the background, I don't mind missing the main() function.

Also I was poking around to see what the various smart phones were using for development. I might take some time to rewrite the Connect Four app to work on the Palm and/or iPhone. Unfortunately they use different base codes. Pre (and the Droid) uses a Java based language and Apple products use Objective-C. On top of that, each one has a different preferred IDE. And there is Flash as well which works on some phones. Still maybe when I want to take a long detour I will play with those.

So I think I will wait till I am much more comfortable with C++ and when I am not thinking about fundamental gaming concepts.

Today's new trick was overloading operators. I decided to make my position type be able to handle addition, assignment, and scalar multiplication. This will allow me to more succinctly do camera offsets. As such, the Display Surface now has a camera setting as well so it can scroll around larger images. Next up is doing a Board class. I plan on spliting it to both a tile based board as well as a static image board.

With the recent 30th birthday of Pac-Man, I plan on doing my own version of that after I get these parts in order. Hence both a Tile and Static image board. Pac-man is a good AI exercise as well.

Sort of "reading ahead" I know that I will start to learn more sophisticated algorithms soon. Collision Detection can get pretty hairy as you add more entities. The number of possible collisions goes up by n!. Also I will have to take a look at procedural map creation. Fortunately all of these are "solved" problems. I am not the first one to be doing this so many of the algorithms are defined. I just will need to translate them in to my code.

Treating Everyone like Objects

Coding wise, nothing too new to report. I finished off the lower level SDL interface objects and created the skeleton for the main gaming loop. Although I made a remark about Game Dev's "One Line Main" program, I am starting to see its usefulness in limiting scope and reducing the need for some type of global variables. At least now I can provide a context for most of active game data so that process events and rendering cleanly.

Tomorrow, I start up with the Tile and Board objects. I am not sure if I will have anything complete to release on Friday, but we will see what I do over the holiday weekend.

From a design perspective, I have given more thought about what I am trying to achieve and about how long it should take. I spent some time on RogueBasin and seeing what has been done before.

I definitely plan on spending my time on my strengths. That is mostly in engine development and game logic. For this project it will be a 2D Iso tile based game. How interesting the tiles and maps become depend on how much time I spend on art. I don't plan on going to far past some fairly basic graphics.

But it should end up to be a small but complete game. It will just be a simple dungeon delve of some depth. Though I am much better at creating story so I might put some meaning into the crawl.

How....Original

I never ever implied that what I am doing is unique in any way. Just found these today:

Rogue Basin: The wiki on all things RogueLike.

It even has How to Write Your Own Rogue in 15 Steps. Seems like I am already on Step 4. Looking at that outline made me feel good since it is fairly close to what I had working on in my head as a development guideline.

Anyway, back to the code.

Working in Circles

Today, I am almost back to where I started. Functionally speaking. I have been redesigning the under lying class structures. Aside from using "better coding practices" like const declarations and explicitly using more references to limit the amount of actual data movement, I also changed a fundamental logical method.

Originally, I had the source graphic object take care of applying itself to the destination graphical surface. However, since now that every surface is its own object, I decided that it should be the destination object that does the blit-ing. This is because it is the destination surface that is being modified. The source is left alone. So to follow the idea that classes should modify their own data and not allow other to so meant moving the "apply" logic.

Granted, it wasn't that hard. In the end the same information is passed, just a different order of the focus of parameters.

This has allowed me to get a better understanding of C++. At times I think I have a handle on it, then something new appears and I feel very clueless. Oddly enough it isn't the concepts itself, it is more the lexicon and vocabulary. Usually after a few readings it all makes sense since they are concepts I have considered, but not in this context.

I also just need to do and implement. At times I feel hampered in my progress because I am working hard to translate my thoughts in to C++. Speed will just come over time.

In other news, my previous comment about the bleakness of the San Diego Computer Gaming Culture may have been in haste. Last night I attended the local IGDA chapter meeting. It has been in hiatus for the past year or so and is now being resurrected. Still it isn't near the size as Orange County or LA, but there is some promise there. There is enough raw talent in San Diego, but there seems to be a lack of gaming business leadership to organize that talent in to more studios.

A quick "back of a napkin" estimate is still about half a million dollars to fund a small studio of about three developers for two years. That is quite a few units to sell to make back that investment, not to mention to provide revenue to continue. This isn't impossible, 10 to 20 thousand units is pretty achievable, but by no means easy.

From what I can tell, a studio is going to be cash flow negative until they get two or even three products out concurrently on the market. So a good business plan is needed to get though that long start up burn of cash.

The Begin Loop

Last week finished up a few things. First Connect Four was put to rest and I finished the book Code Complete. So this weekend was a bit of a interim break. But now it is Monday and time to get started.

First off, I have started C++ For Game Programmers. It is what the title says it is. I am only a few chapters in, but so far so good. Very meaty and it will take a while to digest.

Also this weeks starts what I have been calling the Maze Mover project. An exercise in tile map creation and some basic collision detection. I have also done some design work on how I want to move forward with the project. Over the weekend I formalized my general design philosophy.

Never use a complex idea when a simple one will suffice

Not really earth shattering, but it is keeping me from over designing too much complexity in to my project. I have a decent understanding of Object Oriented Programing, but I never really cared for the whole idea of making everything an object. I still like some things to be procedural. I would say that my coding method is "procedural using objects." Not what purists would call OOP. I really don't care what the purists say.

That isn't to say that as I learn more about the inner workings of C++ I won't utilize all the tools it offers, but sometimes simple C type structures is all that is needed for a particular solution.

Another key point that I have to keep reminding myself is that I should focus on 2D work in SDL. Every now and then I think how I will have to modify one of my classes for 3D in OpenGL, but then I reel myself back to stay where I am now. Eventually I will get to OpenGL, but I should not waste too much time writing for future development. The topics I need to focus on right now are complicated enough in 2D.

They Say it is one of The Books

So I finished Code Complete and I did enjoy it.

I started writing this on Friday (it is now Sunday morning for those that do not want to do date math from the archives) and I did something I like to do often but in the end turned out to be a bad idea. I have a slightly masochistic habit of reading the low rating reviews of products that I liked. Although I enjoy doing this, it made the first draft more of a defense of the book then a review of the book and its use to me.

This book comes highly recommended from various sources. So I don't really need to promote this book myself. Though personally I would still recommend people to read it at least once. Or make sure you know about all the topics covered in the book.

The book is an overview of many topics in Code Construction and some discussion on software project management. As I mentioned earlier, I have seen most of these topics before from other sources. Working even as UNIX systems administrator, I worked with software developers and I have had my share of design reviews. Also being a PMP, I kind of know a little bit about project management.

What the book does is it gives the reader a concise overview and connection between all the topics covered. It does it all at a high level and for the most part language independent. So if you are trying to get some tips on tuning your C++ source code, this book does not offer any specific advice. However, if you don't know where to start with code tuning, this book will help you think about what to address.

Personally, this book has been very useful. All the random collections of information I had on programing is now better organized in my head. I now have a clearer understanding of what I was doing "instinctively" and now I can modify my methods to produce more useful code.

My major take way for use on the YAR-Project is to not worry too much about making the most efficiently running code at start, and error on the side of readability and clear logic.

Another Bow On It

The Rev 2 Connect Four is up and out the door. Once again you can get it from SourceForge again. Today's joy in building the install package was more fighting with Visual Studio again an nothing code related. It seems that when you set your mode to "Release" in Visual Studio it decides to just bypass assert() functions completely. So parts of the code that actually started the whole game were skipped.

A minor issue, but a good lesson in understating you IDE and compiler.

So what is next?

Next will be what I have called "Maze Mover." This will be an exercise in map tiling, camera focus, as well as basic collision detection between the player controlled object an the map walls. This will include map generation via predefined map files and some experimentation in to random map creation. The latter will be the first foray in to procedural content. Movement is to be done with the mouse, though I might start with keyboard input for the camera controls. The plan also includes doing some art production of my own for the tiles. I should take some time to work on my artistic skills.

Depending on how this goes, I may work on the Collision Box exercise as well. This will be the foundation for dealing with multiple entity collision detection and resolution.

After that, I am not sure what I will do next. Either some type of Break-out game or a might experiment with first person view type games. I have a few books on my list to read so that may give me some ideas where to explore next.

Another View of SDL

I am the type of person who likes to read different sources on the same topic just so I can see the topic from different angles. At times I will even even jump to similar topics just to gain a better understanding in general. For example, I read up on Java and play with it for a while to get a better idea of Object Programing.

To that end, I still like to look at other SDL Tutorials even though the topics are all the same as before. Just seeing a different set of code that does the same thing can offer new insights. So, without too much more preamble, I offer you Dev Hub's SDL Tutorials

This site does require a bit of understanding of C++ and object oriented design as the coding examples heavily use class structures. On a personal note, the author is a member of the "One-Line Main" school of thought. That is main has one command to call another class the runs the show. I am not particularly fond of this school of thought, but it is a valid coding style and has its purpose.

The coding examples are very well laid out and for the most part I was able just to read the code itself most of the time to see how he implemented the topics covered. Also he has an Event Class that I will most likely appropriate in some form. It will have some modifications for my style, but once again, it is useful as is.

The approach of his basic tutorial is to end up with a fairly simple game structure. After finishing this tutorial you will have a strong skeleton of code to build some basic games. Each tutorial is fairly complex in terms of the amount of information presented, though the clear code and explanations help you along.

Another good thing about his site is that he has an active blog and offers additional resources there. There was recently a "Tetris" contest that just ended and it seems like he puts a contest together every few months. Not much in the way of a prize purse, but still could have been fun. I will have to keep an eye out for his next one.

Flavors Need to Rest Overnight

Today was a non-code day. After pretty much getting the final task done for the next rev of Connect Four, I thought I would let it rest. Also I avoided looking at any other parts of my own code. That isn't to say I did not think about various design aspects. I found another SDL tutorial site (which I will go in to detail later when I finish it) and I have been reading up various articles from the IGDA and GameDev.net. I am almost done with Code Complete and should have my review of that up later this weekend as well. The next text book should be arriving tomorrow.

Going over the new Tutorial site has given me quite a few ideas on how to redesign my current set of classes. So I have been doing object diagrams in my head all day. My lovely woman likes to say how cute it is when I am such deep though because I have this intense look and I mumble quite a bit. That is one reason why I like to code alone :) But as it may be, I will spend some time "between" projects to put some of these redesign ideas in to place.

After today's research at GameDev.net, I have come to the conclusion that I am much further along towards "breaking in" then I had originally thought. I think part of my advantage is that I already have some experience in marketing oneself for jobs. Not to mention a decent collection of degrees and professional certifications that have some value in the Gaming Industry. Much of the advice given out is fairly basic job hunting skills. Also it is about setting expectations.

I also confirmed that I am not really in a good area geographically to get a job at a computer gaming company. There is Sony, and Sony. Okay Rockstar has a satellite studio here in the San Diego area. But that is it. If I were up the coast a bit in Oceanside, I would be much better off. At least the trek to Irvine would be a hard but doable daily commute.

So while I am stuck here in San Diego for a while, I will make the best of it and program away.

Pushing It Out the Door

So here I am once more. All goals for Rev 2 of Connect Four have been met. Now it is time to let the code sit for a bit and go over again to see if there are any other defects or issues that need to be addressed. There are still some style issues that are inconsistent as well as I feel the main class C4Board is just doing to many different things. But at this point it isn't really worth a redesign to see if I could break up the class a bit. Most of the extra bits it is doing is specific to the Connect Four game itself so not much for reuse.

I plan to tweak some of the sounds and visual aspects a bit, but for the most part the underlying logic will be unchanged. I expect that after a month or so I would like to come back to this and see what I could have done better. At that point I will have had at least one more exercise project out as well as having done more reading on the topic of C++ and Game Programing.

The next task is Documentation and Design. Documentation is updating the wiki over at Sourceforge. I added two new classes recently that will also be included in the YAR-Lib project so I should start putting my notes in there. Also I have a few more classes that I want to create for the Maze Mover exercise project. That is the Design part.

Challenges of Design

Today I read an article on Game Tutorials & How We Learn. There is a bit of confusion between kinetic and kinesthetic but for the most part it does bring in to light some thoughts when considering the audience of your game.

One path I have been exploring with my lovely woman, is the idea of developing software for use in education. She herself is currently a teacher of kindergarten a pre-K but has experience with primary education as well. Developing software for children is still a form of game design.

I would even go far to say that computer games help reinforce many fundamental educational skill such as critical thinking, problem solving, and comprehension. The level of challenge provided varies, but even simple arcade games like good old Space Invaders had a Solution that could be figured out. Once the solution was determined, it was then just a matter of rote repetition to consistently beat the game.

Back to the article at hand.

I have personally been exposed to the study of learning styles and methods for about 25 years. Not really studying it per se, but always brought up though out my formal and informal education over my life. Oddly enough, I never really though about how it would apply to game design. I took well to gaming, both computer and table-top, because of my personal tendency towards discovery and learning. So this brings up the question, does the dislike video games somewhat stem from the problem that many of those games do not present themselves in a style that allows the player to discover in a comfortable matter? People tend to dislike or even fear those things that they can not experience or understand.

Understanding learning and discovery styles is important in all forms of game design. This also includes considering the background of a potential player of a game.

Many games today make some fairly strong assumptions about the person is about the play the game. A friend of mine recently got Dragon Age for his PS3. He is not, however, much of a computer/console game player. He is a avid gamer of table top games so the RPG aspect of Dragon Age was not the problem. It was how to interface with the game and how things were done. Some things that would be considered trivial to those that have used a PS3 controller in many other games were not apparent. Over time he figure things out, but even the manual made a assumption about the level of knowledge that the player would have.

As a designer, both the level of interface familiarity and discovery/educational methods need to be considered. This does give me food for thought as I move forward with my various design plans. I have a few games in my pipeline to play and I have been taking time to take a step back and see how I am using that game, and how I am getting feed back. But this is a best a small anecdotal evidence. There is probably a decent academic paper or two that I could write on the subject. Too bad, I can't afford going back to school for yet another degree.

Adding the Bells and Whistles

Yet another reason why I like programing. At the end of the day there is some form of tangible progress. Some days it isn't easily quantifiable, like yesterday's refactoring, but today saw two notable features added to the Connect Four. First was adding the "Dropping chip" animation. The animation was fairly simple. Depending on how many ticks since the last screen refresh, move the chip down a certain amount.

The trick was realizing that I had gone from a simple Boolean state to needing to be in one of four states depending on what was going on. Thus the old problem of the player_chip_added mentioned before rearing its ugly head. The end result was create a enumerated type of what "state" the game was in. And which methods should be run. The advantage I got out of this new device was that I can now easily add a fifth state to say it is the AI_PLAYER's turn. So the hook for adding a computer player is also in place.

The second accomplishment was kind of unplanned. I was quickly able to whip up TextImage object to hold, display and modify text for the output screen. It works well enough for Connect Four, but it needs a few more tweaks to offer the flexibility that I will want going forward.

This only leaves adding sound effects, and computing the actual AI left. I also plan to put in a simple starting splash screen and the choice to play single to dual player. Depending on how much time I have, I may even add a few more graphic elements, but for now it seems to be working nicely enough.

The sound portion is both easy and tedious. If I though making art elements was time consuming, try sifting though various sound effects to find something close to what I am thinking. I have seen enough behind the scenes production making films to know that Folly artists are a very curious lot. You never realize how important they are until they are not there. I also always though it was one of the coolest jobs out there.

As such I am not making my own sound effects. I barely have the facility to make simple art objects. Audio production is another kettle of fish. Even limiting myself to free sounds, there is a lot to sift though.

The AI will be interesting. It is one of those areas that will just require some thinking on my part for valid strategies. It will start fairly simple with a handful of rules then some randomness for fun. Connect four has been around long enough that there is a mathematical ideal play. But at this point I don't know what it is and I don't think I would want to make the game impossible. Though I might do so later.

Sound and Fury

In reading Code Complete, one of the more interesting statistics was that the average amount of new code generated by one programmer was about 50 lines a day. Now, "lines of code" isn't a very good metric since it does not take in to the consideration of the density of each line of code. That is how much really is done. However it can give you a ball park idea on how complex the program is. The difference between a 100 line program and 200 line program may be very small, but the difference between 100 lines and 1000 lines is most likely very noticeable.

Still, no matter how you look at it, 50 lines of code does not sound like a lot, especially when commercial software packages get up to 10,000 (and more) fairly regularly. What it boils down to, is that being a software developer means doing much more than "writing code."

This isn't foreign concept to me. Being a sysadmin means a lot of prep and planning in order to do a little work as possible. I have done a host of upgrades and production roll-outs. And when things go smoothly, very little work is done at those time. Granted, to do little work, you have to plan and prep.

In Software Development, it relates to good design choices from the beginning make the rest of the project much smoother. Today was doing a good deal of refactoring to the classes and stand-alone functions I plan to reuse going forward. The current challenge was to slowly remove any direct reference to SDL calls outside a few lower level classes. Also I went over the better defined the level of abstraction for each of these classes.

Another change was more of a style change. I am moving from underscore_notation to CamelNotation. Though I am more worried about being consistent in the classes slated for reuse, but I did some clean up in the Connect Four Project as well.

After all was said and done, more lines were taken out (or at least bypassed) then added, even though the functionality did not change. I did make one apparent improvement, that was making the potential chip slightly faded. So not a bad day for a negative number of lines coded today.

Strawberry Waffles

This morning's breakfast was strawberry waffles. What does this have to do with game development? Well not that much but it was yet another aha moment for my journey. My lovely woman was craving pancakes this morning and since we were out of mix, we went to the local IHOP. She did comment that since I started this project, I have found new passion again. And I got to thinking how I could keep this going.

The original goal of this project was to create a portfolio of game programs that I could use to join a game studio as some level of programmer. But then I got to thinking, what about going Indie? There are times I am glad that I got my MBA. I am already running though marketing and business plans.

One important lesson I have picked up from B-School and other sources, is that creating the product is the easy part. In this case, writing computer games and programming is fairly straight forward for me. I don't have any doubt that I could create some rogue like game in the time I have allotted myself. Though to make money off of it is a different story.

Torchlight sells for 20 $US and is a very detailed game and well done. So that sets a benchmark for what people expect for a 20 dollars game today. They have a small studio of about a dozen employees. I am good, but matching the work of that may people would be a bit of a stretch at this moment.

So ideas are being processed and shifted. There are some promising paths that need to be researched, so time will tell what happens next.

Up Up and Away!

And now I am a Game Publisher. I have uploaded the Connect Four game over at SourceForge. I did change the name to Four Across just to not deal with any copyright issues with Hasbro. Sure there are some internal references to Connect Four (tm) in the code, but for now, I not overly worried about any legal action.

Most of the early part of the day was spent learning the Visual Studio release and deployment features. Though to be safe there is both the "Installer" version of the game as well as the "Zip of Files" version. The Installer version will check to make sure your .NET configuration is up to date, otherwise it will update your system and want to reboot. Most of you should be smart enough to figure out the zip file version should not want to trust a Microsoft Installer.

Still have at and feel free to comment. It isn't really anything exciting as a game other then being something that I created. I plan on giving the code a rest for a day or so before moving on.

I Are Game Programmer

As of this point, I am now a Game Programmer. Connect Four is complete and it does everything that the basic game does. It allows players to take turns and figures out who wins and ends the game. Sure the indication of "End of Game" is the background going from white to blue, and you no longer see a potential chip, but there is a change in how the game behaves. I will be a Game Publisher later this weekend when I put the release up for download.

There is still a list of feature enhancements I could implement, like adding sounds, animating the dropping of the chips, and adding more feedback on the current state of the game. Not to mention I could spend some time adding some details to the various graphical elements. Right now it is just a lot of circles of single color. And there is adding a "computer player." I would not really call it an AI since it would be fairly simple, but it would at least be an structured algorithm.

If I were in a team environment, I would submit what I had for code review. Not because it is "perfect" but more to get an opinion of what would be more important to refactor and make the code better.

Today's coding insight was dealing with creating a state variable to determine if particular procedures should run or not. Now I am working with a fairly simple but clear game loop:

Initialize Game components:
Run Loop while game window is open:
    Get Event from Input
    Process events
    Apply game logic
    Draw/Refresh the screen with updated state of game
Clean up and end program

Since this is constantly iterating many times a second, I don't want the game to check to see if there is a winner every refresh, only once after a new chip is added to a column. Also when the game is "over" but the window is still open, though it should not handle any game related input events.

There are two procedures in the game object that were conditional on the state of the game and if there was a chip recently dropped. I only wanted to check to see if the game is over and change players if there was a new chip to consider. chip_added was a flag set so that both procedures could run. At one point I had the chip_added flag complete modifiable by the main loop and not by the game object. This broke the level of abstraction I was trying to maintain. Not to mention having a publicly modifiable attribute from a class.

My problem was not in setting the condition, that was easily done in the event for adding new chip. But which of the other procedures should reset it. The final solution was to change the name of the flag to player_added_chip. This now makes is consistent that NextPlayer() should be the one to reset the flag.

In the end it was just simply rethinking the name of a variable that makes the logic of the program flow consistently.

Can it be a game if no one wins?

The Connect Four game is moving along nicely. I will hit my goal of having a complete game by Friday. Though it may not be up on Sourceforge as a Release Download till the weekend. For now it will just be a .zip file of the executable, .dll's, image files. But I need to test it one of my non-development systems to make sure it works.

There two things left that need to be done. First, I need to have the game determine any "Game Over" conditions. And then I need to display some sort of notification of the Game Over condition. The sophistication of that display will depend on how much time I have left after the logic is done.

In other news, I have been reading Code Complete and I am about a quarter of the way though. It is an 800+ page text and I get though a chapter or two a night. Depends on what is on TV. I really like it. In away, I have already experienced a good deal of what he talks about in the book. But it puts all the little tid-bits of programing wisdom I have gathered over 25 years in one place. Also it defines terms to concepts I already held and giving me more to consider. It is now giving me a vocabulary to better describe the issues that I see with my own code.

For example, right now the main class in the Connect Four game seems to be doing too much, I am worried about its level of abstraction. Also, looking at how I wrote some of the earlier functions, I am making assumptions about data structures that are mostly valid, but ones I should not make if I were to consider each class more isolated. I already have a decent list of things I would like to refactor but I have my deadline to make. Thus it is with any software project, "It is never complete, only released."

You can always refactor a program to bring it inline with a different set of coding ideals. Most of the time, it is because you can do something one of two ways that would still be considered "Best Coding Practices." Though I suspect that one could even constantly refactor "Hello World" till the cows came home.

Having an Apostrophe

One aspect I love about programming, as well as systems administration, is the "Ah Ha!" moment of getting past some really challenging problem. It is that moment of clarity that everything else falls into place and the rest of the solution just falls in to place.

Now a days these moments are getting rarer and rarer in my primary career. It has to do with the fact that, as an industry, IT just knows more now. So the boundary of uncharted/unknown territory is seldom challenged. Also my current company is in an industry that doesn't require leading edge technology to be competitive. The last time I did anything "radical" in the IT industry was about 10 years ago. That isn't to say I am not learning new things. But they are already established ideas that are just need to be implemented.

I still deal with interesting problems from time to time, like how to avoid reconfiguring 500+ devices in 10 different cities that are connected via IP address instead of hostname and had no remote configuration ability. But for the most part everything works, or if it breaks the fix is fairly well documented.

But with programing, there always seems to be some challenge or wall to run into. Today I was figuring out how to best store the state information of the chip locations on the board. I wanted the Board class to really just be aware of itself and how to draw itself. The chip states are best stored as a two-dimensional array, but I did not want that also to determine where to draw itself. Lastly which object should handle the user inputs.

So I was thinking "I need something that is a board that contains the chip states."

Hey, that is an inherited object! This actually makes me kind of excited. This way I can extend the Board object here to deal with the connect four chips and then extend it again in Maze Mover to handle collisions with the movable token. I was not thinking toward code reuse at this moment, but it just fell out. I will redo the Board class after I am done to make sure it is general.

I expect that over time, I won't be hitting a wall every day. Or at least completing more development between walls. But I hope that it will be frequent enough to keep me excited.

In other news, you can see that I have been playing with the blog template. I like the three column approach only because I tend to have quite a few "side bar" objects. Also I have been giving though to my marketing strategy. What good is writing a quality game if no one knows about it? Right now going with online networking and "friend of a friend" approach.

Working with my Limits

I make no pretense to be any form of a graphic artist. Hence the simplistic look of my games. This is also why I have never gotten in to the Mod Community of games. I can structure story and dialog paths, as well as crunch numbers for encounters, but I must rely on stock images. I can get by drawing maps with pre-gen tiles, but I would not create new tiles.

When it comes to image manipulation in memory, sure no problem. Blit and flip, bitdepth, and refresh rates are easy for me. Even reading up on 3D graphics, I can figure out some simple equations for doing projections to a 2D screen. Object transformation and spatial manipulation is my thing. Collision detection is a relatively easy concept to employ. Even animation is simple for me. It is just a bunch of images that you cycle though. frame = (++frame) % MAXFRAMES

To create those images, that isn't me.

The interesting thing is, I see that a lot of people think game design is all about the graphics. Many interesting games are being developed in the indie/small press community, but they get panned because they looks dated. The YAR Project will be one of those "dated" applications. However, the trick will be to still make it look professional. Simple but professional.

Striving for Perfection

So it was a fairly productive day. The Connect Four Project as officially started and at this point I can create a the board of yellow plastic. As from before I have the image files for the checkers and for now that is all I will do for graphics. For this week my goal is just to get the basic game play for two human players taking turns and able to recognize when the game is won, or board full and thus a stalemate.

Today's dilemma of programming came from trying to do everything "correctly" right now. For example, I am reusing a the code I put together during the tutorials as a base, but I made fresh copies to edit instead of true code reuse. But I have decided to go a little further with the smaller projects before I start building a library of reusable objects. It is recommended that you design anything "new" for the project at hand with out worrying too much about reuse. You should still use good coding style and practices, but wait till after the project is done to determine which objects are good candidates for reuse and then redesign those objects as their own mini-projects between software projects.

Rest of the day was spent tooling around with more features of SourceForge. I started the Wiki documentation and created a few project milestones for the next few weeks as well as putting a line in the sand for the main project itself. The first key milestone is the formulation of the design document itself by my 40th birthday. Although "development" has really started with all the exercises I am doing now, this will be a formal document. And thus by my 40th Birthday the project will be underway in earnest. Proposed dates and milestones should be in place by then as well.

It Is What Got Me Started

So now that I have finished with the tutorials, time to give a bit of a sum up of my experiences at Lazy Foo' Productions. I found the site though various iterations of google searches. Between "Game Design Tutorials" and "Game Graphic Programing" it seemed to pop up a few times. So with a few clicks and away I went.

My first hurdle was getting used to working with Visual Studio 2010. It just released and I decided to jump right in with the express version. So it took some time to figure out how best to download and configure the SDL libraries. But that was not a fault of the tutorials. If anything they did a good job of showing me where I would need to set things in Visual Studio.

So here I am ready to become a master game programmer and this site will tell me how to do it. Aside from his tutorials, he does have a nice set of article as well and from this one on Starting out in Game Development he had a very nice idea bout "Jumping In." It is worth the read so I will not quote it here. But I do still have a hint a fish about me.

The tutorials gave a very nice overview of basic gaming mechanics and how the SDL library can help solve them. The code provided is very useful and I have based a good deal of my personal libraries on his work. In his examples everything is in one large source file and he makes use of many of his structures being global. So as a personal exercise, I broke classes out to their own header and code files as well as relying more on passing information by reference then by using global variables.

At this point I have heavily modified most of what he presented for my own use. Though I do need to give him credit for the Timer class. I think I will be using that almost exactly as presented, except for a few typographical changes for my own personal style and variable notation.

The information presented definitely gave me enough tools get started on my own projects. It starts with just the quick basic screen drawing and image mapping. Then gets in to topics of collision detection, camera panning, scrolling and other basic gaming topics. There was some advanced items on multi-treading that I did not review since that is an advanced topic in general programing let alone game programing.

The tutorials gave me some context to start going though the various SDL documentation and see what else I will be able to do and create. I am at this point ready to start my first design project and see where I end up.