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.