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.


Monday, May 31, 2010

Holiday Times Means Lots of Quiet

So it is a day off from work and having no real Memorial Day plans, I am looking forward to many hours of uninterrupted programing. I just finished my breakfast and morning reading of C++ for Game Programmers and about to dive in to the code.

Lots of ideas to implement today. So we will see what I get done. First I need to finish collision detections between the game board and pieces on the game board. Also I need to create some form of data file loading function. In the "wish list" today is to create a File, Resource and Entity Manager systems. At least get some foundation ideas in place.

Now once I get the collision system in place, I would have enough to work on my Pac-Man game. However, much of the information would have to be hard coded. So at the very least I need some level of data file system.

Aside from the lower level resource management items, I will need to create a AI system as well. Pac-Man is a good AI programming exercise since you need to create 5 different AI scripts.

With all the other events I have for June, I plan to get a release version of Pac-Man done by the end of the month. But if I am lucky that may come out sooner.

After that, I suspect that I will have most of the tools I need to start working on YAR itself. Or at the very least work on additional foundation items such as adding scripting support and developing the RPG aspects of YAR.

So much to do today before the quiet is gone.

Friday, May 28, 2010

Getting too clever

The nice thing about holiday weekends is that you can get so much done. Fortunately this gave me more time to program. Today was an exercise in possibly getting too clever. Yesterday I stumbled on to making my own operators for custom data types and I may have gone a wee bit overboard. My little old position structure is now a full class with addition, scalar multiplication, equality comparison and even a funky divisor for dealing with pixel movement per frame refresh.

Also I created structures and objects doing collisions on circles and rectangles. This way I can just do Entity1 < Entity2 to see if they overlap for collision. It got a little more convoluted then I wanted. But now I can define an object as a collection of circles and rectangles and see if it overlaps with another object of circles and rectangles. It is crude and will work.

There are better methods out there, but I will have to read up on them. I think what I need to find is a good Game Algorithm book. Something that will help with advance collision detection, AI programing as well as other more advanced topics.

However, what I have now will be more then adequate for what I have in mind for YAR. Everything I have is still really a 2D sprite in one plane, so circles and rectangles should be good enough. I will need to figure out how to do the map collision for Pac-Man. Defining all the walls as rectangles could work. I just should have something that tries the closest walls first. Though I may do it though tile definitions. Each tile has a predefined set of exits to other tiles.

Overall it has been a good week, even though I don't have anything to release this week. I might have something done over this weekend.

Thursday, May 27, 2010

Off the Path

Today I did a small detour in to the Microsoft Windows API. Just did the old faithful Hello World, and a simple screen form. I have never been a fan of the whole "Design the interface then do the code" style that most form builders use. And Visual Studio is no different.

Though part of the problem in the past is that I was trying to learn the language as well as the Form Design. The design tool hid too many things going on in the background. Now, I am not struggling with the back end language. I can look at the code and see that is C++ structures in the MS style. Since I know what is really going on in the background, I don't mind missing the main() function.

Also I was poking around to see what the various smart phones were using for development. I might take some time to rewrite the Connect Four app to work on the Palm and/or iPhone. Unfortunately they use different base codes. Pre (and the Droid) uses a Java based language and Apple products use Objective-C. On top of that, each one has a different preferred IDE. And there is Flash as well which works on some phones. Still maybe when I want to take a long detour I will play with those.

So I think I will wait till I am much more comfortable with C++ and when I am not thinking about fundamental gaming concepts.

Today's new trick was overloading operators. I decided to make my position type be able to handle addition, assignment, and scalar multiplication. This will allow me to more succinctly do camera offsets. As such, the Display Surface now has a camera setting as well so it can scroll around larger images. Next up is doing a Board class. I plan on spliting it to both a tile based board as well as a static image board.

With the recent 30th birthday of Pac-Man, I plan on doing my own version of that after I get these parts in order. Hence both a Tile and Static image board. Pac-man is a good AI exercise as well.

Sort of "reading ahead" I know that I will start to learn more sophisticated algorithms soon. Collision Detection can get pretty hairy as you add more entities. The number of possible collisions goes up by n!. Also I will have to take a look at procedural map creation. Fortunately all of these are "solved" problems. I am not the first one to be doing this so many of the algorithms are defined. I just will need to translate them in to my code.

Wednesday, May 26, 2010

Treating Everyone like Objects

Coding wise, nothing too new to report. I finished off the lower level SDL interface objects and created the skeleton for the main gaming loop. Although I made a remark about Game Dev's "One Line Main" program, I am starting to see its usefulness in limiting scope and reducing the need for some type of global variables. At least now I can provide a context for most of active game data so that process events and rendering cleanly.

Tomorrow, I start up with the Tile and Board objects. I am not sure if I will have anything complete to release on Friday, but we will see what I do over the holiday weekend.

From a design perspective, I have given more thought about what I am trying to achieve and about how long it should take. I spent some time on RogueBasin and seeing what has been done before.

I definitely plan on spending my time on my strengths. That is mostly in engine development and game logic. For this project it will be a 2D Iso tile based game. How interesting the tiles and maps become depend on how much time I spend on art. I don't plan on going to far past some fairly basic graphics.

But it should end up to be a small but complete game. It will just be a simple dungeon delve of some depth. Though I am much better at creating story so I might put some meaning into the crawl.

Tuesday, May 25, 2010


I never ever implied that what I am doing is unique in any way. Just found these today:

Rogue Basin: The wiki on all things RogueLike.

It even has How to Write Your Own Rogue in 15 Steps. Seems like I am already on Step 4. Looking at that outline made me feel good since it is fairly close to what I had working on in my head as a development guideline.

Anyway, back to the code.

Working in Circles

Today, I am almost back to where I started. Functionally speaking. I have been redesigning the under lying class structures. Aside from using "better coding practices" like const declarations and explicitly using more references to limit the amount of actual data movement, I also changed a fundamental logical method.

Originally, I had the source graphic object take care of applying itself to the destination graphical surface. However, since now that every surface is its own object, I decided that it should be the destination object that does the blit-ing. This is because it is the destination surface that is being modified. The source is left alone. So to follow the idea that classes should modify their own data and not allow other to so meant moving the "apply" logic.

Granted, it wasn't that hard. In the end the same information is passed, just a different order of the focus of parameters.

This has allowed me to get a better understanding of C++. At times I think I have a handle on it, then something new appears and I feel very clueless. Oddly enough it isn't the concepts itself, it is more the lexicon and vocabulary. Usually after a few readings it all makes sense since they are concepts I have considered, but not in this context.

I also just need to do and implement. At times I feel hampered in my progress because I am working hard to translate my thoughts in to C++. Speed will just come over time.

In other news, my previous comment about the bleakness of the San Diego Computer Gaming Culture may have been in haste. Last night I attended the local IGDA chapter meeting. It has been in hiatus for the past year or so and is now being resurrected. Still it isn't near the size as Orange County or LA, but there is some promise there. There is enough raw talent in San Diego, but there seems to be a lack of gaming business leadership to organize that talent in to more studios.

A quick "back of a napkin" estimate is still about half a million dollars to fund a small studio of about three developers for two years. That is quite a few units to sell to make back that investment, not to mention to provide revenue to continue. This isn't impossible, 10 to 20 thousand units is pretty achievable, but by no means easy.

From what I can tell, a studio is going to be cash flow negative until they get two or even three products out concurrently on the market. So a good business plan is needed to get though that long start up burn of cash.

Monday, May 24, 2010

The Begin Loop

Last week finished up a few things. First Connect Four was put to rest and I finished the book Code Complete. So this weekend was a bit of a interim break. But now it is Monday and time to get started.

First off, I have started C++ For Game Programmers. It is what the title says it is. I am only a few chapters in, but so far so good. Very meaty and it will take a while to digest.

Also this weeks starts what I have been calling the Maze Mover project. An exercise in tile map creation and some basic collision detection. I have also done some design work on how I want to move forward with the project. Over the weekend I formalized my general design philosophy.

Never use a complex idea when a simple one will suffice

Not really earth shattering, but it is keeping me from over designing too much complexity in to my project. I have a decent understanding of Object Oriented Programing, but I never really cared for the whole idea of making everything an object. I still like some things to be procedural. I would say that my coding method is "procedural using objects." Not what purists would call OOP. I really don't care what the purists say.

That isn't to say that as I learn more about the inner workings of C++ I won't utilize all the tools it offers, but sometimes simple C type structures is all that is needed for a particular solution.

Another key point that I have to keep reminding myself is that I should focus on 2D work in SDL. Every now and then I think how I will have to modify one of my classes for 3D in OpenGL, but then I reel myself back to stay where I am now. Eventually I will get to OpenGL, but I should not waste too much time writing for future development. The topics I need to focus on right now are complicated enough in 2D.

Sunday, May 23, 2010

They Say it is one of The Books

So I finished Code Complete and I did enjoy it.

I started writing this on Friday (it is now Sunday morning for those that do not want to do date math from the archives) and I did something I like to do often but in the end turned out to be a bad idea. I have a slightly masochistic habit of reading the low rating reviews of products that I liked. Although I enjoy doing this, it made the first draft more of a defense of the book then a review of the book and its use to me.

This book comes highly recommended from various sources. So I don't really need to promote this book myself. Though personally I would still recommend people to read it at least once. Or make sure you know about all the topics covered in the book.

The book is an overview of many topics in Code Construction and some discussion on software project management. As I mentioned earlier, I have seen most of these topics before from other sources. Working even as UNIX systems administrator, I worked with software developers and I have had my share of design reviews. Also being a PMP, I kind of know a little bit about project management.

What the book does is it gives the reader a concise overview and connection between all the topics covered. It does it all at a high level and for the most part language independent. So if you are trying to get some tips on tuning your C++ source code, this book does not offer any specific advice. However, if you don't know where to start with code tuning, this book will help you think about what to address.

Personally, this book has been very useful. All the random collections of information I had on programing is now better organized in my head. I now have a clearer understanding of what I was doing "instinctively" and now I can modify my methods to produce more useful code.

My major take way for use on the YAR-Project is to not worry too much about making the most efficiently running code at start, and error on the side of readability and clear logic.

Friday, May 21, 2010

Another Bow On It

The Rev 2 Connect Four is up and out the door. Once again you can get it from SourceForge again. Today's joy in building the install package was more fighting with Visual Studio again an nothing code related. It seems that when you set your mode to "Release" in Visual Studio it decides to just bypass assert() functions completely. So parts of the code that actually started the whole game were skipped.

A minor issue, but a good lesson in understating you IDE and compiler.

So what is next?

Next will be what I have called "Maze Mover." This will be an exercise in map tiling, camera focus, as well as basic collision detection between the player controlled object an the map walls. This will include map generation via predefined map files and some experimentation in to random map creation. The latter will be the first foray in to procedural content. Movement is to be done with the mouse, though I might start with keyboard input for the camera controls. The plan also includes doing some art production of my own for the tiles. I should take some time to work on my artistic skills.

Depending on how this goes, I may work on the Collision Box exercise as well. This will be the foundation for dealing with multiple entity collision detection and resolution.

After that, I am not sure what I will do next. Either some type of Break-out game or a might experiment with first person view type games. I have a few books on my list to read so that may give me some ideas where to explore next.

Thursday, May 20, 2010

Another View of SDL

I am the type of person who likes to read different sources on the same topic just so I can see the topic from different angles. At times I will even even jump to similar topics just to gain a better understanding in general. For example, I read up on Java and play with it for a while to get a better idea of Object Programing.

To that end, I still like to look at other SDL Tutorials even though the topics are all the same as before. Just seeing a different set of code that does the same thing can offer new insights. So, without too much more preamble, I offer you Dev Hub's SDL Tutorials

This site does require a bit of understanding of C++ and object oriented design as the coding examples heavily use class structures. On a personal note, the author is a member of the "One-Line Main" school of thought. That is main has one command to call another class the runs the show. I am not particularly fond of this school of thought, but it is a valid coding style and has its purpose.

The coding examples are very well laid out and for the most part I was able just to read the code itself most of the time to see how he implemented the topics covered. Also he has an Event Class that I will most likely appropriate in some form. It will have some modifications for my style, but once again, it is useful as is.

The approach of his basic tutorial is to end up with a fairly simple game structure. After finishing this tutorial you will have a strong skeleton of code to build some basic games. Each tutorial is fairly complex in terms of the amount of information presented, though the clear code and explanations help you along.

Another good thing about his site is that he has an active blog and offers additional resources there. There was recently a "Tetris" contest that just ended and it seems like he puts a contest together every few months. Not much in the way of a prize purse, but still could have been fun. I will have to keep an eye out for his next one.

Flavors Need to Rest Overnight

Today was a non-code day. After pretty much getting the final task done for the next rev of Connect Four, I thought I would let it rest. Also I avoided looking at any other parts of my own code. That isn't to say I did not think about various design aspects. I found another SDL tutorial site (which I will go in to detail later when I finish it) and I have been reading up various articles from the IGDA and I am almost done with Code Complete and should have my review of that up later this weekend as well. The next text book should be arriving tomorrow.

Going over the new Tutorial site has given me quite a few ideas on how to redesign my current set of classes. So I have been doing object diagrams in my head all day. My lovely woman likes to say how cute it is when I am such deep though because I have this intense look and I mumble quite a bit. That is one reason why I like to code alone :) But as it may be, I will spend some time "between" projects to put some of these redesign ideas in to place.

After today's research at, I have come to the conclusion that I am much further along towards "breaking in" then I had originally thought. I think part of my advantage is that I already have some experience in marketing oneself for jobs. Not to mention a decent collection of degrees and professional certifications that have some value in the Gaming Industry. Much of the advice given out is fairly basic job hunting skills. Also it is about setting expectations.

I also confirmed that I am not really in a good area geographically to get a job at a computer gaming company. There is Sony, and Sony. Okay Rockstar has a satellite studio here in the San Diego area. But that is it. If I were up the coast a bit in Oceanside, I would be much better off. At least the trek to Irvine would be a hard but doable daily commute.

So while I am stuck here in San Diego for a while, I will make the best of it and program away.

Wednesday, May 19, 2010

Pushing It Out the Door

So here I am once more. All goals for Rev 2 of Connect Four have been met. Now it is time to let the code sit for a bit and go over again to see if there are any other defects or issues that need to be addressed. There are still some style issues that are inconsistent as well as I feel the main class C4Board is just doing to many different things. But at this point it isn't really worth a redesign to see if I could break up the class a bit. Most of the extra bits it is doing is specific to the Connect Four game itself so not much for reuse.

I plan to tweak some of the sounds and visual aspects a bit, but for the most part the underlying logic will be unchanged. I expect that after a month or so I would like to come back to this and see what I could have done better. At that point I will have had at least one more exercise project out as well as having done more reading on the topic of C++ and Game Programing.

The next task is Documentation and Design. Documentation is updating the wiki over at Sourceforge. I added two new classes recently that will also be included in the YAR-Lib project so I should start putting my notes in there. Also I have a few more classes that I want to create for the Maze Mover exercise project. That is the Design part.

Challenges of Design

Today I read an article on Game Tutorials & How We Learn. There is a bit of confusion between kinetic and kinesthetic but for the most part it does bring in to light some thoughts when considering the audience of your game.

One path I have been exploring with my lovely woman, is the idea of developing software for use in education. She herself is currently a teacher of kindergarten a pre-K but has experience with primary education as well. Developing software for children is still a form of game design.

I would even go far to say that computer games help reinforce many fundamental educational skill such as critical thinking, problem solving, and comprehension. The level of challenge provided varies, but even simple arcade games like good old Space Invaders had a Solution that could be figured out. Once the solution was determined, it was then just a matter of rote repetition to consistently beat the game.

Back to the article at hand.

I have personally been exposed to the study of learning styles and methods for about 25 years. Not really studying it per se, but always brought up though out my formal and informal education over my life. Oddly enough, I never really though about how it would apply to game design. I took well to gaming, both computer and table-top, because of my personal tendency towards discovery and learning. So this brings up the question, does the dislike video games somewhat stem from the problem that many of those games do not present themselves in a style that allows the player to discover in a comfortable matter? People tend to dislike or even fear those things that they can not experience or understand.

Understanding learning and discovery styles is important in all forms of game design. This also includes considering the background of a potential player of a game.

Many games today make some fairly strong assumptions about the person is about the play the game. A friend of mine recently got Dragon Age for his PS3. He is not, however, much of a computer/console game player. He is a avid gamer of table top games so the RPG aspect of Dragon Age was not the problem. It was how to interface with the game and how things were done. Some things that would be considered trivial to those that have used a PS3 controller in many other games were not apparent. Over time he figure things out, but even the manual made a assumption about the level of knowledge that the player would have.

As a designer, both the level of interface familiarity and discovery/educational methods need to be considered. This does give me food for thought as I move forward with my various design plans. I have a few games in my pipeline to play and I have been taking time to take a step back and see how I am using that game, and how I am getting feed back. But this is a best a small anecdotal evidence. There is probably a decent academic paper or two that I could write on the subject. Too bad, I can't afford going back to school for yet another degree.

Tuesday, May 18, 2010

Adding the Bells and Whistles

Yet another reason why I like programing. At the end of the day there is some form of tangible progress. Some days it isn't easily quantifiable, like yesterday's refactoring, but today saw two notable features added to the Connect Four. First was adding the "Dropping chip" animation. The animation was fairly simple. Depending on how many ticks since the last screen refresh, move the chip down a certain amount.

The trick was realizing that I had gone from a simple Boolean state to needing to be in one of four states depending on what was going on. Thus the old problem of the player_chip_added mentioned before rearing its ugly head. The end result was create a enumerated type of what "state" the game was in. And which methods should be run. The advantage I got out of this new device was that I can now easily add a fifth state to say it is the AI_PLAYER's turn. So the hook for adding a computer player is also in place.

The second accomplishment was kind of unplanned. I was quickly able to whip up TextImage object to hold, display and modify text for the output screen. It works well enough for Connect Four, but it needs a few more tweaks to offer the flexibility that I will want going forward.

This only leaves adding sound effects, and computing the actual AI left. I also plan to put in a simple starting splash screen and the choice to play single to dual player. Depending on how much time I have, I may even add a few more graphic elements, but for now it seems to be working nicely enough.

The sound portion is both easy and tedious. If I though making art elements was time consuming, try sifting though various sound effects to find something close to what I am thinking. I have seen enough behind the scenes production making films to know that Folly artists are a very curious lot. You never realize how important they are until they are not there. I also always though it was one of the coolest jobs out there.

As such I am not making my own sound effects. I barely have the facility to make simple art objects. Audio production is another kettle of fish. Even limiting myself to free sounds, there is a lot to sift though.

The AI will be interesting. It is one of those areas that will just require some thinking on my part for valid strategies. It will start fairly simple with a handful of rules then some randomness for fun. Connect four has been around long enough that there is a mathematical ideal play. But at this point I don't know what it is and I don't think I would want to make the game impossible. Though I might do so later.

Monday, May 17, 2010

Sound and Fury

In reading Code Complete, one of the more interesting statistics was that the average amount of new code generated by one programmer was about 50 lines a day. Now, "lines of code" isn't a very good metric since it does not take in to the consideration of the density of each line of code. That is how much really is done. However it can give you a ball park idea on how complex the program is. The difference between a 100 line program and 200 line program may be very small, but the difference between 100 lines and 1000 lines is most likely very noticeable.

Still, no matter how you look at it, 50 lines of code does not sound like a lot, especially when commercial software packages get up to 10,000 (and more) fairly regularly. What it boils down to, is that being a software developer means doing much more than "writing code."

This isn't foreign concept to me. Being a sysadmin means a lot of prep and planning in order to do a little work as possible. I have done a host of upgrades and production roll-outs. And when things go smoothly, very little work is done at those time. Granted, to do little work, you have to plan and prep.

In Software Development, it relates to good design choices from the beginning make the rest of the project much smoother. Today was doing a good deal of refactoring to the classes and stand-alone functions I plan to reuse going forward. The current challenge was to slowly remove any direct reference to SDL calls outside a few lower level classes. Also I went over the better defined the level of abstraction for each of these classes.

Another change was more of a style change. I am moving from underscore_notation to CamelNotation. Though I am more worried about being consistent in the classes slated for reuse, but I did some clean up in the Connect Four Project as well.

After all was said and done, more lines were taken out (or at least bypassed) then added, even though the functionality did not change. I did make one apparent improvement, that was making the potential chip slightly faded. So not a bad day for a negative number of lines coded today.

Sunday, May 16, 2010

Strawberry Waffles

This morning's breakfast was strawberry waffles. What does this have to do with game development? Well not that much but it was yet another aha moment for my journey. My lovely woman was craving pancakes this morning and since we were out of mix, we went to the local IHOP. She did comment that since I started this project, I have found new passion again. And I got to thinking how I could keep this going.

The original goal of this project was to create a portfolio of game programs that I could use to join a game studio as some level of programmer. But then I got to thinking, what about going Indie? There are times I am glad that I got my MBA. I am already running though marketing and business plans.

One important lesson I have picked up from B-School and other sources, is that creating the product is the easy part. In this case, writing computer games and programming is fairly straight forward for me. I don't have any doubt that I could create some rogue like game in the time I have allotted myself. Though to make money off of it is a different story.

Torchlight sells for 20 $US and is a very detailed game and well done. So that sets a benchmark for what people expect for a 20 dollars game today. They have a small studio of about a dozen employees. I am good, but matching the work of that may people would be a bit of a stretch at this moment.

So ideas are being processed and shifted. There are some promising paths that need to be researched, so time will tell what happens next.

Friday, May 14, 2010

Up Up and Away!

And now I am a Game Publisher. I have uploaded the Connect Four game over at SourceForge. I did change the name to Four Across just to not deal with any copyright issues with Hasbro. Sure there are some internal references to Connect Four (tm) in the code, but for now, I not overly worried about any legal action.

Most of the early part of the day was spent learning the Visual Studio release and deployment features. Though to be safe there is both the "Installer" version of the game as well as the "Zip of Files" version. The Installer version will check to make sure your .NET configuration is up to date, otherwise it will update your system and want to reboot. Most of you should be smart enough to figure out the zip file version should not want to trust a Microsoft Installer.

Still have at and feel free to comment. It isn't really anything exciting as a game other then being something that I created. I plan on giving the code a rest for a day or so before moving on.

Thursday, May 13, 2010

I Are Game Programmer

As of this point, I am now a Game Programmer. Connect Four is complete and it does everything that the basic game does. It allows players to take turns and figures out who wins and ends the game. Sure the indication of "End of Game" is the background going from white to blue, and you no longer see a potential chip, but there is a change in how the game behaves. I will be a Game Publisher later this weekend when I put the release up for download.

There is still a list of feature enhancements I could implement, like adding sounds, animating the dropping of the chips, and adding more feedback on the current state of the game. Not to mention I could spend some time adding some details to the various graphical elements. Right now it is just a lot of circles of single color. And there is adding a "computer player." I would not really call it an AI since it would be fairly simple, but it would at least be an structured algorithm.

If I were in a team environment, I would submit what I had for code review. Not because it is "perfect" but more to get an opinion of what would be more important to refactor and make the code better.

Today's coding insight was dealing with creating a state variable to determine if particular procedures should run or not. Now I am working with a fairly simple but clear game loop:

Initialize Game components:
Run Loop while game window is open:
Get Event from Input
Process events
Apply game logic
Draw/Refresh the screen with updated state of game
Clean up and end program

Since this is constantly iterating many times a second, I don't want the game to check to see if there is a winner every refresh, only once after a new chip is added to a column. Also when the game is "over" but the window is still open, though it should not handle any game related input events.

There are two procedures in the game object that were conditional on the state of the game and if there was a chip recently dropped. I only wanted to check to see if the game is over and change players if there was a new chip to consider. chip_added was a flag set so that both procedures could run. At one point I had the chip_added flag complete modifiable by the main loop and not by the game object. This broke the level of abstraction I was trying to maintain. Not to mention having a publicly modifiable attribute from a class.

My problem was not in setting the condition, that was easily done in the event for adding new chip. But which of the other procedures should reset it. The final solution was to change the name of the flag to player_added_chip. This now makes is consistent that NextPlayer() should be the one to reset the flag.

In the end it was just simply rethinking the name of a variable that makes the logic of the program flow consistently.

Wednesday, May 12, 2010

Can it be a game if no one wins?

The Connect Four game is moving along nicely. I will hit my goal of having a complete game by Friday. Though it may not be up on Sourceforge as a Release Download till the weekend. For now it will just be a .zip file of the executable, .dll's, image files. But I need to test it one of my non-development systems to make sure it works.

There two things left that need to be done. First, I need to have the game determine any "Game Over" conditions. And then I need to display some sort of notification of the Game Over condition. The sophistication of that display will depend on how much time I have left after the logic is done.

In other news, I have been reading Code Complete and I am about a quarter of the way though. It is an 800+ page text and I get though a chapter or two a night. Depends on what is on TV. I really like it. In away, I have already experienced a good deal of what he talks about in the book. But it puts all the little tid-bits of programing wisdom I have gathered over 25 years in one place. Also it defines terms to concepts I already held and giving me more to consider. It is now giving me a vocabulary to better describe the issues that I see with my own code.

For example, right now the main class in the Connect Four game seems to be doing too much, I am worried about its level of abstraction. Also, looking at how I wrote some of the earlier functions, I am making assumptions about data structures that are mostly valid, but ones I should not make if I were to consider each class more isolated. I already have a decent list of things I would like to refactor but I have my deadline to make. Thus it is with any software project, "It is never complete, only released."

You can always refactor a program to bring it inline with a different set of coding ideals. Most of the time, it is because you can do something one of two ways that would still be considered "Best Coding Practices." Though I suspect that one could even constantly refactor "Hello World" till the cows came home.

Tuesday, May 11, 2010

Having an Apostrophe

One aspect I love about programming, as well as systems administration, is the "Ah Ha!" moment of getting past some really challenging problem. It is that moment of clarity that everything else falls into place and the rest of the solution just falls in to place.

Now a days these moments are getting rarer and rarer in my primary career. It has to do with the fact that, as an industry, IT just knows more now. So the boundary of uncharted/unknown territory is seldom challenged. Also my current company is in an industry that doesn't require leading edge technology to be competitive. The last time I did anything "radical" in the IT industry was about 10 years ago. That isn't to say I am not learning new things. But they are already established ideas that are just need to be implemented.

I still deal with interesting problems from time to time, like how to avoid reconfiguring 500+ devices in 10 different cities that are connected via IP address instead of hostname and had no remote configuration ability. But for the most part everything works, or if it breaks the fix is fairly well documented.

But with programing, there always seems to be some challenge or wall to run into. Today I was figuring out how to best store the state information of the chip locations on the board. I wanted the Board class to really just be aware of itself and how to draw itself. The chip states are best stored as a two-dimensional array, but I did not want that also to determine where to draw itself. Lastly which object should handle the user inputs.

So I was thinking "I need something that is a board that contains the chip states."

Hey, that is an inherited object! This actually makes me kind of excited. This way I can extend the Board object here to deal with the connect four chips and then extend it again in Maze Mover to handle collisions with the movable token. I was not thinking toward code reuse at this moment, but it just fell out. I will redo the Board class after I am done to make sure it is general.

I expect that over time, I won't be hitting a wall every day. Or at least completing more development between walls. But I hope that it will be frequent enough to keep me excited.

In other news, you can see that I have been playing with the blog template. I like the three column approach only because I tend to have quite a few "side bar" objects. Also I have been giving though to my marketing strategy. What good is writing a quality game if no one knows about it? Right now going with online networking and "friend of a friend" approach.

Working with my Limits

I make no pretense to be any form of a graphic artist. Hence the simplistic look of my games. This is also why I have never gotten in to the Mod Community of games. I can structure story and dialog paths, as well as crunch numbers for encounters, but I must rely on stock images. I can get by drawing maps with pre-gen tiles, but I would not create new tiles.

When it comes to image manipulation in memory, sure no problem. Blit and flip, bitdepth, and refresh rates are easy for me. Even reading up on 3D graphics, I can figure out some simple equations for doing projections to a 2D screen. Object transformation and spatial manipulation is my thing. Collision detection is a relatively easy concept to employ. Even animation is simple for me. It is just a bunch of images that you cycle though. frame = (++frame) % MAXFRAMES

To create those images, that isn't me.

The interesting thing is, I see that a lot of people think game design is all about the graphics. Many interesting games are being developed in the indie/small press community, but they get panned because they looks dated. The YAR Project will be one of those "dated" applications. However, the trick will be to still make it look professional. Simple but professional.

Monday, May 10, 2010

Striving for Perfection

So it was a fairly productive day. The Connect Four Project as officially started and at this point I can create a the board of yellow plastic. As from before I have the image files for the checkers and for now that is all I will do for graphics. For this week my goal is just to get the basic game play for two human players taking turns and able to recognize when the game is won, or board full and thus a stalemate.

Today's dilemma of programming came from trying to do everything "correctly" right now. For example, I am reusing a the code I put together during the tutorials as a base, but I made fresh copies to edit instead of true code reuse. But I have decided to go a little further with the smaller projects before I start building a library of reusable objects. It is recommended that you design anything "new" for the project at hand with out worrying too much about reuse. You should still use good coding style and practices, but wait till after the project is done to determine which objects are good candidates for reuse and then redesign those objects as their own mini-projects between software projects.

Rest of the day was spent tooling around with more features of SourceForge. I started the Wiki documentation and created a few project milestones for the next few weeks as well as putting a line in the sand for the main project itself. The first key milestone is the formulation of the design document itself by my 40th birthday. Although "development" has really started with all the exercises I am doing now, this will be a formal document. And thus by my 40th Birthday the project will be underway in earnest. Proposed dates and milestones should be in place by then as well.

It Is What Got Me Started

So now that I have finished with the tutorials, time to give a bit of a sum up of my experiences at Lazy Foo' Productions. I found the site though various iterations of google searches. Between "Game Design Tutorials" and "Game Graphic Programing" it seemed to pop up a few times. So with a few clicks and away I went.

My first hurdle was getting used to working with Visual Studio 2010. It just released and I decided to jump right in with the express version. So it took some time to figure out how best to download and configure the SDL libraries. But that was not a fault of the tutorials. If anything they did a good job of showing me where I would need to set things in Visual Studio.

So here I am ready to become a master game programmer and this site will tell me how to do it. Aside from his tutorials, he does have a nice set of article as well and from this one on Starting out in Game Development he had a very nice idea bout "Jumping In." It is worth the read so I will not quote it here. But I do still have a hint a fish about me.

The tutorials gave a very nice overview of basic gaming mechanics and how the SDL library can help solve them. The code provided is very useful and I have based a good deal of my personal libraries on his work. In his examples everything is in one large source file and he makes use of many of his structures being global. So as a personal exercise, I broke classes out to their own header and code files as well as relying more on passing information by reference then by using global variables.

At this point I have heavily modified most of what he presented for my own use. Though I do need to give him credit for the Timer class. I think I will be using that almost exactly as presented, except for a few typographical changes for my own personal style and variable notation.

The information presented definitely gave me enough tools get started on my own projects. It starts with just the quick basic screen drawing and image mapping. Then gets in to topics of collision detection, camera panning, scrolling and other basic gaming topics. There was some advanced items on multi-treading that I did not review since that is an advanced topic in general programing let alone game programing.

The tutorials gave me some context to start going though the various SDL documentation and see what else I will be able to do and create. I am at this point ready to start my first design project and see where I end up.

Sunday, May 9, 2010

90 Minutes to Make a Circle

So it is the weekend, but there was still work on the project. This time, its was creating following three images for the Connect Four game:

Board TileRed ChipBlack Chip

All told, it took an hour and a half to do these simple drawings. I started off opening paint and every time I tried to draw a circle it ended up slightly flattened, and I could not just modify the circle properties itself by dragging them around. Not to mention trying to get these to a 100x100 pixel size tile. Okay, so I download GIMP. And I am now even more confused on to how I do I make a circle. One last try for something in the middle, Paint.Net. Between flailing with GIMP and a little of of previous knowledge on layers an what not, I get the above images created Friday evening.

After a good dinner and some rest, I head over to B&N to peruse the Computer Graphics section. And yes, for those that were saying to yourself, why were you using those programs in the first place, I now understand that I was using the completely wrong type of tool for this part of the project. I was using raster-based image manipulation tools when I was thinking in vector-based terms.

Suffice to say, I was never really a graphic artist of any sort, so I was not aware of the difference in tools for computer graphics. I can barely draw a straight line with a ruler. Which could have been a problem since I wanted to go in to mechanical drawing, when I was in High School. Fortunately for me, that was also the beginning of AutoCad, so I did not really need to master drawing with a pencil. There I created a 3D wireframe model of the Space Station, but never did any surfacing or animation. Back then it took long enough to render the complete model as a wireframe.

Since then I think that all graphical drawing programs are based off of AutoCad and as such, I should just be able to tell it to create a circle and place it where I wanted it. Not go and center it pixel by pixel and hope both sides look right.

I plan on spending more time working on my digital graphic skills, though I plan to keep it mostly 2D. Third-person Isometric games were good enough for Diablo, so it is good enough for me.

Friday, May 7, 2010

It Isn't All Coding, You Know

So today was a productive even if very little coding was done. I did a few tweaks to the ImageSheet and finished the Tile Class. I created the base of my Mob Class (for Mobile) which is based of the various Dot, Square, and Sprite classes from Lazy Foo'. For now I am done with his tutorials. I have some ideas for other exercise projects, like a simple maze game, which will deal with MOB-TILE collisions, scalable windows and camera movement.

The Connect Four project will cover mouse event handling, simple collision detection, layered graphics, and some basic animation. At first it will be a "two-player" game but I do intend to create an AI for it as well.

Today was a Project Management day. Aside from planning on what my next little exercise projects will do, I spent time figuring out what Revision Control System I am going to use. Sure, for now I am the only working on all of this, but even now getting used to some level of control. Not to mention, I would like to keep "older" versions of the classes as I work though them.

I also gave some thought and planning to how I will promote this project as I get more and more familiar with what I am doing and have some actual code pieces to show for it. So after a some time not making any sense of Microsoft Documentation on its version control system, I had my "Well, Duh!" moment, and remembered Sourceforge. I wanted some external hosting of the files anyway, and this does SVN (as well as other forms of source control.) A quick google to get the SVN plug-in for Visual Studio and I was golden. All the working files I have are now uploaded and under version control. Now I can easily move between computers and even change my IDE should I feel the need. (Like if I want to do some cross platform compiling in Linux)

The link over in the Current Status section to the project page. Not much there right now, but over time I will flesh it out. I thought about moving the blog over there as well, but it will be easy enough to cross connect here and there.

So here is what is coming up next:

  • Connect Four: this should take about a week to get something fairly basic up and running. I expect most of my time to be dealing the graphics and animations. The logic of the game is fairly straight forward. However more time will be spent in the "Make it pretty" category.

  • In the queue (Not necessarily in this order):

  • Maze Game: Something to do random map creation, mob-tile collisions, scrolling screens and some more interactive issues.

  • TIE Fighter: One of the first games for my Apple II was a simple X-Wing v TIE Fighter game. Basically it was try to shoot the moving TIE fighter while it move about the screen.

  • Space Invaders: A fairly basic game that needs to deal with collision and destructible environments

  • Missile Command: Another Arcade classic with a good deal of randomization, delay, chain events and collisions.

  • Castle Wolfenstien/DOOM: Granddaddy of FPS. But also a start in to pseudo 3D. I might even make the jump to OpenGL and do some more in depth 3D work at this point

  • There will be other exercise projects as well. Also I will be finding some books on some more advanced game design theory. This should keep me busy for a few months. During which time I will slow put together my design doc for YAR.

    Thursday, May 6, 2010

    The Old Masters

    I finished a pass though the old classic The C Programing Language by Kernighan and Ritchie. It is a fairly small text coming in under 300 pages with index, prefaces and other such things. Even C for Dummies comes in over 400 pages and doubtfully has the same meaty-ness that is in good old K&R.

    The second edition came out in 1988, and there has never been an update. My particular copy was acquired around my time in college in the early 1990s. Back in the day, it was the book. Well it was the only book. I would not recommend this book to learn C. In fact I had a very hard time making sense of it back in college as well. But now after 20 years of systems administration, study and practice in to the UNIX kernel and structure, the book is crystal clear, almost.

    At this point in time, the book is very academic. It shows you how to do things if all you had was a small Swiss Army Knife. Now MacGyver has shown us that one can make great things with just a small Swiss Army Knife, but there are much better tools out today. For example, K&R shows you how you can make your own string library with nothing but character based I/O and pointers to characters. This is a very fine academic exercise. But even if you wrote your own, you should be using the standard string library from C++ since it is commonly used and well tested.

    I was recommended this book with "it has the best treatment on pointers." And on that I would agree. I still plan to go back from time to time and re-read chapters 5 (Pointers) and 6 (Structures). The denseness of these two chapter alone take time to digest. I also read it because I still had my own copy from way back when.

    C is a very powerful language, and K&R shows you all the fundamental tools that make it so powerful. But with great power comes great responsibility. Just because you can do something "very clever" in C does not mean you should.

    In summary, any one who is serious about being a real C programmer, should be able to master the information in this book. But I would consider it an advanced text, and not for those that do not already have some understanding of programming, C, and even the UNIX operating system. It is still a good reference on the low level workings of the language.

    As a bit of a side note, I suspect most of the books that I will use and review will be more "reference" in nature and not as much "tutorial." Or they will be in depth on particular topics, like Game AI design. Still, I will endeavor at least comment on the usefulness of any text for me on this project.

    Fighting Elegance

    So instead of doing lesson 29 on top of what I have already done, I decided to clean up what I have already done to make things more uniform. My realization is that sprite sheets, animation sheets, and tile sheets (not to mention font sheets) all share a lot of similar properties. You take an image file and show only a section of it depending on external factors. So it is time to combine as many of the common attributes and methods in to a single class.

    In the process I am looking at my wrapper functions and wondering how I can make them more generic. Right now I have the following functions:

    SDL_Surface* load_image(std::string filename);
    TTF_Font* load_font(std::string filename, int fontsize);
    Mix_Music* load_music(std::string filename);
    Mix_Chunk* load_chunk(std::string filename);

    Each of these takes regular SDL load function for each data type, traps any errors in the process and then returns the pointer. Also each one adds the pointer type specific object array so that I can close all objects with one generic close_all_objects() function.

    Here is my dilemma. What I have works, but it lacks a sort of elegance, that I think could be achieved. For example, I would like have a load_object() function that would determine the type of object and do the correct loads. One option is just to do a set of overloading functions like:

    void load_object(SDL_Surface *surface_ptr,std::string filename);
    void load_object(Mix_Music *music_ptr,std::string filename);

    But this leaves me sort of where I was before. I just have this feeling that I can make the code more "elegant" and "concise" by generalizing even the common structure. I suspect I am falling in to the fairly common trap of "over-elegance." I am not adding any more functionality. Not mention I now spending more time anguishing over this little task, other than making actual progress on fundamental components for the games.

    Wednesday, May 5, 2010

    Big Jump Before the Wall

    Today I got up to lesson 27. Though I sort of did skip lessons 24 (Game Saves) and 25 (Joystick Controls).

    Lesson 24 was basically simple file I/O. I am very familiar with the concept but I have not done it in C++. However I will come back around and look at the fstream class later. Actually, I sort of need to do a nice tour of the C++ standard classes anyway. Vector was used in one of the tutorials and it seems it will solve my "list of stuff of unknown length" dilemma of yesterday.

    Lesson 25 is more event handling. But for the most part the only difference is they are "joystick" events instead of "keyboard" events. The handling is pretty much the same:

    if (event.type == EVENT_DEFINE) { do suff; }

    For the most part you end up with a fairly extensive elseif structure. To fully build an event handler will require spending time with the SDL_Event structure and all its sub structures.

    At this point I think I will take a look at Lesson 29 (Tiling) then start work on my Connect Four program. The Particle Engine lesson is on the list, but I will spend some time making it into a independent object class. Bit Map Fonts (30) and Pixel Manipulation (31) seem to have some more useful information, but I am not that sophisticated graphic elements yet. I should go find a nice 2D computer graphics/animation source. Frame independent movement is simple, move object/animation inversely proportional to the time between the last frame.

    The last sections are on multithreading. Programing threads is an advance topic on its own. Independent of gaming. This, too, will require more dedicated study independent of game design. Let me get a few single threaded games under my belt first before I worry about this topic.

    What is a Programmer?

    One of my math professors in college once was asked "What is a mathematician?" He then wrote the following on the board:

    Then he said, "A mathematician is someone who knows that the answer to this equation is square-root of pi." This is the Gaussian Integral and is fundamental to most of probability. The trick to solving this is to making it look more complicated to make it easier. In the end, the additional "complication" really was just a means of making the solutions much easier and more elegant.

    I have found the similar type of situation for a C programmer. Here is a line of code that I have been staring at for over a day:

    qsort ((void**) lineptr, 0, nlines-1,
    (int (*)(void*,void*))(numeric ? numcmp : strcmp));

    (Those of you playing at home, this is on K&R p. 119)

    Pointers to Functions, casting void pointers to pointers and cryptic single line constructs. (Okay the ": ?" notation isn't that cryptic, but that is another post.) In short a C Programmer is some who not only knows what is going on in the above snippet of code, but can create similar code when it is needed.

    I like C because of pointers. Tough it was in PERL that I personally understood how and why they work. There have been many times with other languages that I went, "I wish I had pointers."

    Tuesday, May 4, 2010

    Aminmation and other forms of Movement

    Today was lessons 20 to 22 at Lazy Foo'. Animations and scrolling backgrounds. Most of my time was spent breaking out the Animation lesson and creating my own robust Sprite Object. Also I cleaned up some of the SDL wrapper functions and put them in their own header/code section.

    Today's limitation was trying to create arrays of undetermined sizes of things. My pointer-fu is still weak. Right now I am still doing:

    SDL_Surface* ObjList[MAXOBJECTS];

    as my method of creating an array of pointers to structures. I did not have my K&R book handy so I had to settle here for now.

    The concern is for my Sprite object. A Sprite Sheet may contain different sized animations of the sprite depending on the "state" of the object it is representing. For example, the animation for a standing figure may not use the same dimensions of that the same figure laying down. So right now I have to assume the same frame size for each version of the sprite.

    Personally, I am not too worried about this for now. That is the one of the points of this project. Learning how to do things. Last night I stopped just before the Pointers to Structures section. So I will go over that tonight.

    I have been pondering taking a few classes, but what I don't need or want is a "Programming in " course. The language syntax is rarely the problem with me. But that is most of what is offered in various "Continuing Ed" type classes. I would like to take upper division CS type classes, but I don't really care to spend a few thousand dollars a credit. I don't need the credit, just the information. Not to mention I suspect I know a good deal of the information in scattered form. So I would spend most of my time waiting for the rest of the class to catch up. So Books and the Web will be my school grounds.

    Monday, May 3, 2010

    The Frist Step

    To become a game programmer, one must first learn to program.

    I am not sure exactly when I started programing. My first projects were typing pre-written basic programs from this yellow book of "Computer Games in BASIC." I was fairly young at that time and I could understand the structure and read the code, but I was not really developing it. My first formal programing education was learning Pascal in the summer before my freshman year at high school. Concepts such as flow control, variables, and even recursion were fairly straight forward for me. In college I learned FORTRAN and C.

    But even knowing already four different programming languages, I still never considered myself a programmer. I was an Engineer and used them as tools to get my own projects done. I never thought about developing software for others to use.

    Now the interesting thing is that after about 30 years of "Not being a programmer." I realized that I have a decent amount base knowledge. So after talking with one of my software developer friends, I have decided to start the project with bringing myself up to speed C++. After a few google searches on "Game Programing and C++" I found Lazy Foo' Productions. A quick download of Microsoft Visual C++ Express 2010 and away I went.

    Right now I have just finished with Lesson 19. So far this has been good for me to relearn C++ as well as start understanding some of the basics of game programing. One of the things I have been doing is rewriting some of the code to my personal style and sense of re-usability. I expect to be done with his lessons some time next week. Then after that I should be developing my first game. I am thinking of doing a "Connect Four" game first, maybe "Battleship" after that. The nice thing about my "misspent youth" is that I have quite a few games that I can recreate myself as a starting point.

    The Spark of an Idea

    So here I am, starting a new project and seeing how I will change my life this time. Who I am is fairly simple, just another geek with a goal to make a living being a game designer. I have been playing games of some sort all my life. I had one of the first "Supper Pong" game systems (Four Games in ONE!) and my family got one of the very first Apple II's out of someone's garage, long before "Computer Store" was even an idea.

    But my history and enthusiasm for gaming will not land me job. I have no real credentials in my CV for programming. At best I have a set of shell scripts that have been in production, mostly unmodified, for over 10 years that run a simple but critical service over at Qualcomm.

    My current professional position is, "Systems Architect" for a regional retail company. Which is really just a very fancy title for "Senior IT Geek Who Isn't the Manager." And since the company isn't that large, I do everything from swapping back-up tapes to project managing the roll out million dollar software upgrade project. I have a few useful pieces of paper, like a B.S. in Engineering, a MBA, as well as a PMP, that keep me employed as is.

    I am not doing this for the money. If I were in this for the money, I never would have left Wall Street.

    "Why another Rogue Game?" Simple, I like CRPGs. And Rogue is the Granddaddy of all CRPGs. And that is where I would like to end up. Also there is a nice diversity of components for me to learn, including networking, client-server architecture, database design, AI programing and level design.

    So here I am taking my first step on this thousand mile journey.