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.