Rogue is a dungeon crawling video game first developed by Michael Toy and Glenn Wichman around 1980. It is generally credited with being the first "graphical" adventure game, and was a favorite on college Unix systems in the early to mid-1980s, in part due to the procedural generation of game content.


Thursday, July 29, 2010

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.

Wednesday, July 28, 2010

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.

Tuesday, July 13, 2010

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.

Thursday, July 8, 2010

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.

Friday, July 2, 2010

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.