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.

-- http://en.wikipedia.org/wiki/Rogue_(computer_game)

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.

0 comments:

Post a Comment