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.