Finally an Update on the Quest System

So, after taking a break from the engine work (due to classes, personal life, etc), I've finally made some substantial progress on the Quest System. The basics of the quest system is as follows:

• Objective - Represents some objective object for a quest. An objective, in short, is more like a single action quest. However, using extensions, a Quest can hold objectives that are really more quests, which allows for powerful and strong chaining. Each objective has its actual objective control, the reward for completing the objective, whether it is completed or not, and whether it is "required or not" (used for larger quests).

• Quest - This is a sub-class of an objective. This represents the actual container used for a quest. This stores a series of Objectives, keeping track of their state. Whether the quest is completed or not is determined by whether or not all of the internal objectives are completed, as well as any overhead the Quest itself requires.

• Reward - This represents the reward object for the quest. This can be customized into storing anything, which is useful for any type of game.

• ObjectiveControl - This represents what is used to actually check if an objective is complete or not. This is a control which is dependent on the actual state of the system in the game. Each Objective has an ObjectiveControl, which itself monitors the state of the game system, characters, etc to distinguish if the Objective has been completed or not.

Right now, I'm working on building a simple system that generates quests using these, based on the parameters of a simulation. The simulation will be a simple 2D world, in which stick figures will move over the land, altering it in some way. Based on the state of the simulation (allocation of resources, number of people / mobs, etc), quests will be generated. A list will contain the quests available and from it, a user can take a quest at a time and "complete" the quest, allowing them to see how the simulation progresses. Once the core system has been built and verified, I will move on to seeing what it can be used for in more classical games.

Finally Have DirectX 9 Working

So, after struggling with Visual Studio 2008 on a bug that is generated when doing a batch build of the engine and its subsidiary libraries, I have finally gotten a basic library built for encapsulating DirectX 9.0 in the engine. I am looking into fixing the build error (I may need to disable incremental builds and instead make it an all or nothing thing... That could be the source of the error, as it seems to malfunction with the libraries whenever it is recompiled after a previous failure).

I am now working on a proof of concept application, a simple game, that uses the current state of the library. It will do basic content loading and management. The entities in game will utilize state and action objects during play. The basic game will be a 2D vertical rail shooter. The following actors will be made:

"PlayerShip" - Using the generic actor, this will have the following states and actions.

• PlayerControllerState - This state acts as the controller for the player. This will be in charge of determining the actions the player's ship performs, based on input information, provided as an action from the system.
• HealthState - This state is the amount of health the player's ship has.
• WeaponState - This state is the currently equipped weapon of the player.
• FireAction - This is the action which the PlayerShip performs on its parent. This action calls the ship to fire, telling the game world to generate the current weapon effect on screen.
• CollisionAction - This is the action the PlayerShip performs on anything it collides with. It damages the target by a certain amount.

This is the basic idea. Enemy ships will have similar controllers, controlled through simple AI and the like. Likewise, they will have their own actions and effects.

I will update once the prototype game is out.

Dynamic Quest Generation

So, while I'm thinking about it, I'd like to talk about something called "Dynamic Quest Generation". Many people have heard of it. Many others have asked for it. I'm here to discuss why it is feesible, and why it is not.

So, as far as making a system to do this, I can say with 100% certainty that it not only is possible, but it could be programmed by an undergrad student at university. In fact, a group of students in the CS Department here did do just that. I did that at one point as well. The core of the system was these classes:

1. Quest class - Represents a quest, its goals, its preconditions, postconditions, rewards, etc. Can also encompass multiple quests (quest chain, etc).
2. Goal - Represents an abstract goal type for a character to achieve. Can encompass complex goals, such as doing multiple parts of a quest, etc.
3. Precondition - Any precondition required for beginning the quest (level, certain item, etc).
4. Postcondition - Any artifacts that occur in the world as a result of the quest (level, area change, changes in people, etc).
5. Rewards - I made this separate of postconditions, in that rewards are what only interact with the completing characters. This includes things like experience gain, item gain, alignment shifts, etc.

Now, using these, it is possible to create a completely random and logical quest system. But does anyone see the main problem with this? If you look hard, we have everything to dynamically create quests, except for one thing: Dialogue, Narrative, etc.

So, you may think that is the easy part. But in truth, for a system like this, that is the hardest part to accomplish. For example, it is very easy to create something like this:

"Go kill ten flying monkeys. Then fetch my ruby slippers. Then come back to me. I'll give you ten gold and a shovel. Then help me bury Toto. I'll join you."

However, it is much, much more complicated to create something like this:

"Oh, I really need your help! The flying monkeys of the horrid wicked witch have gone too far. They killed my dog, Toto! Even worse, they ran off with my ruby slippers, and I am stranded here without them. Could you please go and kill all ten of those horrid monsters and bring back my slippers? I'll reward you with all the gold I have and the Tin Man's shovel. Please, I'm begging you!"

"Oh, thank you for returning them to me. I am ever so grateful. If you could be so kind, could you do me one last favor? I was going to, but I just don't have the heart to bury Toto."

See the difference?

So, in all of those, I bolded the actions required to complete certain stages of the quest. You need to kill the ten flying monkeys, fetch or bring back the ruby slippers, get the reward, and then bury Toto. The specific objectives I underlined, as with the number and name of the creature to kill, what you needed to fetch, and what you received as a reward. All of that content could be replaced very easily in both instances. However, the problem goes with randomly creating the second piece.

If every NPC had that exact same dialogue for this type of quest, it could get really old, really fast. So, I could expand it to being 2 dialogues, then 3, then maybe X per race, Y per gender, etc. The point is, no matter what numbers I choose, eventually the system will become stale. Hence, we really need to randomly create quest narrative to solve this problem, but also do it in a believable manner.

Hence, the idea of random quest generation is really solving 2 problems:

1. The first is to solve the problem of building the quest.
2. The second is to solve the problem of building the narrative.

The harder of the two is most definitely the latter. To solve that, you would need a narrative engine for creating your quests. Even more so, you would need it to be flexible and update-able with new quest types, new dialogue and item entries, etc. Lastly, everything in it would need to make sense, contextually, for the game. And even after all that is done, you would need to update the narrative options, as any system is bound to get stale after a while. Add on top of this multi-language support, etc, and you can see the issues with this.

S, that is my rant of random quest generation. I think the idea has great promise, but at the same time, as players and designers, we need to really note what is the meat of the problem. It is not in assembling a quest, but in making the quest believable.

Neverwinter Nights Mod: The Scrolls of Taz'Azarak

So, I am officially announcing the name of the mod I am working on today. I have decided that I am going to create a mod based off a much more well defined adventure I created and played with two of my friends from high school that they thoroughly enjoyed.

The premise of the story is that the adventurer's must get back the legendary Scrolls of Taz'Azarak. These scrolls each possess an amazing amount of power, as each of them holds some of the lost wizard's abilities. The whole time, they are racing against some unknown foe who is also seeking out the scrolls, trying to gain them for himself. No one is sure what power the scrolls possess, but what history details is that the old arch-magician had gained power over shadow, being able to bend it and use it to his will. However, the power was costly, ultimately taking the wizard's life. In his last days, he wrote a warning to all, telling them that the power of the scrolls should never be used again.

And with that, I bid you farewell.

Engine Updates, DirectX 9, and Mods

So, after doing a lot of research for several days, I have had to redesign several key aspects of the bindings I use for the ILEngine for DirectX 9. Much of this comes from memory and content management, done through DirectX 9, due to the inherit connection between content information (textures, etc) and device context, which is horribly efficient for speed and drawing, but a pain for keeping references tidy when allowing switches between fullscreen, windowed, and resizing. Hence, some work on the engine has come to a crawl until I find a creative way around this. So, until then, I may just stick to creating the application framework for DirectX 9, allow for full modification of the window, and then worry about the rest later.

So, as for the mod, I have been swaying back and forther whether to continue using Neverwinter Nights 2 and its toolset, or to use Neverwinter Nights and its toolset. This is mainly because, for Neverwinter Nights 2, there is not a lot of community content and tools available while for Neverwinter Nights, there is a huge amount of custom content and tools available for creating your own mods. Still trying to weigh this decision more thoroughly on the scripting applications as well.

Game Design Patterns / Rules

Well, as with my last post, this post focuses on patterns and rules for game design. Note, that all of this in many ways is common knowledge to any decent writer or programmer, but I wanted to write something about some internet browsing I did the other day.

So here is the first of the links:

Game Interaction Design Patterns Library

This link will take you to a small and quaint page describing the basics of what the page is for. It will describe what a pattern is, etc. It then has several links. This, in my opinion, is the meat of the this small site. Each of the links (the ones which are not outdated or broken mind you) will take you to a site that discusses patterns, namely "interaction patterns". Now, for the standard software engineer or designer, this may not have any bearing to you. So, here is what an interaction pattern is (referenced from Wikipedia:

"Interaction design patterns are a way to capture optimal solutions to common usability or accessibility problems in a specific context. They document interaction models that make it easier for users to understand an interface and accomplish their tasks."

So, what these patterns often provide are common UI solutions and HCI (Human Computer Interaction) solutions for dealing with and interacting with user input and feedback. There are many more links and better resources out there for you, just read the Wiki article or visit some of the referenced sites from the first site posted. With these, common UI tasks and design you may have been thinking of but didn't know if it would work well (both aesthetically and in usability terms) can be solved for you, leaving you just with the means of implementing that solution.

So, the second site I found and got a kick out of, which is also referenced from the first site, is this one:

Current Rules Master List

This site goes over a list of 400 rules (really only 112 currently) for game design. Now, you may wonder where this comes from, and it is in fact explained very well on the site. The idea was that if 400 unique rules could be created that described everything needed for game design, then game design could be "closed" under those rules. What closed means is it could be fully described, discussed, and elaborated on, as with what closed means in discrete mathematics.

While many of these are common sense based or the basis of basic creative writing and player interactions, they are a good reference for any game designer, as they do actually cover many interesting and varying rules that can be applied to various aspects of game design.

Why Not Common Programming Patterns?

So, I was reading an article today which piqued my interest, in some ways disturbingly:

http://m.computerworld.com.au/article/314817/nicta_wins_race_secure_l4

Now, the article sites a grand achievement for a micro-kernel, especially for one focused on security. That is not my problem. The line in the article that says this was a problem for me, however:

"For example, the microkernel is impervious to buffer overflows, a common form of software attack where hackers take control of programs by injecting malicious code."

Now, I know what you may be thinking: yeah, that's great. So what?

Well, I am in many ways appalled that this is still one of the major programming security problems to date, especially since it goes back since programming first started in many ways. So, I did some research to actually see how big a problem this still is.

Turns out, if you look up buffer overflow on Google, Bing, Yahoo, etc, you end up not only getting the Wikipedia definition and status of it, but you also get tons of security firms trying to sell you solutions and training to handle this problem. And the majority of these errors comes from a single aspect of the software: lack of proper boundary checking and the size of data being written to the buffer.

Now, having gone through multiple programming courses, with focuses on Java, C, C++, and many scripting languages, this is horribly surprising that in my recollection, we never once really touched on handling a simple situation such as making sure your buffer is bounded and checked correctly.

So, this got me to thinking: shouldn't there be, at least in pseudo-code somewhere, be some list of programming patterns or such for something like this? Maybe some actual class / object patterns for this, etc?

It turns out there are, but most of them are locked in some obscure text books or completely out of the way or unrelated websites. Such as, there are patterns for a Fixed Size Buffer for Real-time Systems (example here). However, like most of these tidbits of knowledge, they are either obscured to the specific domain in which they belong, making them inaccessible to many programmers and engineers, or they are just described and no actual psuedo-code or structure is given for ideas.

So, I ask my question, why not have some common programming patterns, that everyone can find, interpret, and use?

I personally may start amassing a few of my own I've used quite often and start noting them down here and there. It may be worth someones time, and eventually, it could be compiled for more people to use.

If anyone has any ideas on some good patterns that may match this, shoot me a comment or an email, and I'll make sure to note it. I really think this is something that could be helpful to not just new programmers, but to even older programmers who often have to re-invent the wheel or remember how to do something nifty and elegant, yet simple, that they did before.

Neverwinter Nights 2 Mod - Lands of Neremier

So, I've finally gotten around to working on a mod I've been planning. I originally started the the mod concept when I bought Neverwinter Nights: Platinum Edition. However, it was a while afterward that I finished most of the design planning on my limited schedule, by which time Neverwinter Nights 2 was just around the corner. So, I waited to that I could try the new Electron Toolset. Once I got knee deep in classwork and working co-ops, this got pushed to a back burner project, which I finally started formally yesterday.

So, I've begun working on the areas for the first few areas of the mod, doing some pretty extensive design work on the first areas of the mod where the players start. I will try to post some screenshots of the current areas when I get some time and may make a section of my portfolio on my site dedicated to my Neverwinter Nights 2 mod.

New Opportinities - Working on Gaming Articles

So, in the past few weeks, I've been working on a new job I've gotten, which is for a website called FreeMMOGamer. For the site, I've been hired to work on review articles, opinion articles, and anything that comes to mind (with approval of course). Hopefully, in the next few months, I'll have several new articles published here, which will give some of my opinions on current and upcoming MMOs.

For my articles, I'm also thinking of adding a little bit of a developer perspective, to give the articles some new flare and perspective, which will be unique.

We'll see how this goes.

IL Framework Generics

So, right now I've been working on the ILGenerics namespace for the framework /What this namespace aims to do is to create a generic implementation of several entities, graphics, resources, states, and actions that are used by various possible entities and actors within a game. These generics can then either be used directly or used as the base classes for other values.

These generics are meant to be the first show of power that the framework has, in that the generics will be some of the most basic types of states, actions, and the like that a system could possibly need. What the namespace will add in general will also be very powerful, giving access to a variety of resources that can aid with making development flow much faster and more fluidly.

I will eventually post the most recent diagrams and documents, which will further explain my reasoning. I need to move the documents to a new host (eventually, probably to a web server I'll rent), which will allow for better configuration management and also allow for all of my work to be hosted from a central repository, rather than on my desktop and backed up on a separate hard drive.

Until later. After these generics are finished, I will finish up the DirectX 9 wrapper classes that allow for the easy creation and extension of DirectX applications, and then will begin on creating my first game with the engine, a proof of concept of how powerful and flexible it can be.

That's it for now.

Oh, also of good note is that I got my personal website up. It can currently be found either at http://www.se.rit.edu/~brb6127 or http://people.rit.edu/brb6127. Feel free to look and investigate my previous work.

IL Framework Progress

Well, yesterday I finished working on the basic IL framework for C++, getting it to compile into both DLLs and Libs for both Debug and Release mode. My next challenge with it is to wrap several of DirectX's files and formats into the framework. This includes but is not limited to:

* Textures (DirectX supported textures)

* Models (.X files for now... may expand later)

* Shaders (HLSL/CG files using ID3DXEffect files and the like)

By then wrapping the actual D3D device inside of the application part of the framework, it should be possible to setup and initialize a D3D application that will run and continue working until the system calls it to quit. From there, I will think about abstracting out the ID3DXSprite interface for drawing sprites to a scene. This will then be applied to a first short game, modeled after one of my Computer Graphics I projects, which will be fully 3D, use DirectX and HLSL for rendering, and finally utilize the interactions system of the framework for game play mechanics.

Looking Into Procedural Content

Well, right now I'm working on a project which will create a randomly generated graph, based on some parameters fed into the system. The graph will then be displayed and be editable by users. Next, after the graph is displayed, the system will export the graph into a format for being read.

Here comes the fun part: take the graph and edges, with weights to specify distances and values to specify sizes, and create terrain or a dungeon from it. From there, make the dungeon exportable to either Maya or 3D Studio Max.

Right now, I'm in the planning stages of developing this software. Currently, the system utilizes a rough system of vertices and edges to create the graph. However, the goal is to surpass that and allow for cycle detection and the like, which can be used for vertex reduction and complexity reduction for the graph.

Development Perspective: Graphics APIs or Graphics Engines?

In this post, I'd like to take a step back from personal projects and happenings and discuss a point of view that was raised in dialogue during a class:

Student: "Which is better: Learning a graphics API or learning how to use a graphics engine?"
Professor: "Well, what are you trying to do?"
Student: "I'm a game programmer! I want to make games with cool graphics!"

Those were words spoken and raised an interesting question which made me think about this from a game development standpoint: which is better to learn?

Well, after digging around, I came up with quite a few different answers, so here's my take on the issue and the pros and cons of the two approaches.

When we talk about graphics APIs, we assume we're talking about something like DirectX or OpenGL, at least in the games world, or whatever platform specific graphics API we're using.

What we gain from knowledge of an API is usually allot of nice information on how the graphics pipeline is handled for that specific type of system. This allows us to not only know the process of what happens when we attempt to place, light/shade, and display the objects in our scene, but it also allows to know how to perform lower level, specific calls to enhance or alter that pipeline, which allows us in many ways, a high level of customization and flexibility with our graphics.

What we often lose here though is the bigger picture. With doing low level shading designs and protocols, tweaking the OpenGL state machine for specific functionality, or making DirectX properly flush our vertices to the graphics card, we often do not gain a clear perspective of the needs for content management, scene control and organization, or gain the high level flexibility of being able to make scenes on the fly without having to specify low level constructs, prefering to develop our own methods or ignore previous methods for obtaining niche performance goals or what we consider cool graphics effects.

When we talk about graphics engines, which are often mislabeled game engines, we are usually talking about the rendering engines behind things such as the Unreal Engine (not the engine itself, but the rendering part of it), Open Scene Graph, the Irrlicht Scene Engine, and similar products.

What these offer is usually a higher level of abstraction away from the tiny lighting functions and placement functions, and give us access to many fundamental function and entities for placing and creating graphical scenes. With this comes content management, allot of extra math done behind the scenes for culling and clipping we don't have to implement, and much higher ease of use.

Here though, we lose allot of the customization and performance upgrades we can have by directly interacting with the API. Like it or not, most of these graphics engines eventually play with DirectX or OpenGL to accomplish their goals. As such, the process in which everything happens behind the scenes is often concealed from us with these engines. Because of this, when we attempt to make personal customizations for fancy or advanced graphics, we often are forced down to the API level, and usually have to conform to the order and organization specified by the engine, unless we want to get errors.

Hence, my opinion on this matter is this. For someone that wants to just make a game, without the need or want to make lots of special graphics customizations or the gut to live with what the engine offers you, then going with an engine is a much easier and faster way to get your game running. However, if you want to learn the ins and outs of how the graphics pipeline works to streamline the graphics performance and be able to eventually create more advanced graphics effects, learning an API (or multiple) is a much better approach. Personally, I choose a little of both, liking to delve really deep into the specifics of an API to pull out good performance or awesome effects, while developing those skills to fit into an engine like construct.

Working Architecture

So, finally now that classes have died down and I'm on the last stretch of my BS degree in Software Engineering, I am going to cover future plans and the system I have been devoting some of my spare time to, the Inferno Game Engine.

I will be finishing my BS this fall, in November 2009. Following, I have decided to enter into the MS in Game Design and Development, with a focus on Game Engine Architecture and Design and Creative Narrative / World Creation. Instead of going straight into industry, I decided that I really needed more projects under my belt, which RIT's GDD master's program offers. However, I'm still skeptical to a degree about the prowess of such a program, as often academic programs for games do not produce the best game designers, programmers, architects, and the like. For that, I will rely on my SE background.

Now, to get to the meat of this post, I have been working for the past 3 years on a game engine primer, as I like to call it. What the primer does is specify the core classes and interfaces for making a game system which revolves around having in game entities communicate with one another, how they store and track their arbitrary state information, and how they act on one another. While I could have slapped something like this together easily without much forethought, I've decided that I really need to design it out and weigh all design decisions properly before just allowing the system to be programmed. For that, I've gotten quite a bit.

Below is the basic flow of the primer (If the diagrams don't appear right, try clicking on them to get a better view of the diagrams):



The above image gives an overview of the idea of the primer, and how it can be used to create bindings which are then used for making game or simulations, ideally.



The above image here represents the basic class structure of the primer. The movement from left to right moves upwards in the chain of complexity of the different class elements, as it is in short, a large class hierarchy of increasing complexity, to allow for the most dynamic and flexible interactions and storage of entities possible.



The above image here was playing around with how the concept of updating would work for the system. It appears like a standard update loop. The design here is not final.

My reasons for posting these diagrams is because, eventually, I am planning on making the primer and the related bindings open source. Currently planned are Irrlicht Engine bindings and XNA bindings, though more can be added later. The reason for this, as specified, is to create the means by which entities can interact and control themselves. I feel, personally, that there are not enough powerful open source tools for the game community and that powerful, great tools should not be limited to the powerful or those with millions of dollars of funding. While this may not control the quality of games directly by limiting only to those groups, what it does do is provide better tools that will support burgeoning game developers.

And with that, I will leave it for now. I have more work to do, but these should help others to get a better idea of what the engine does, and what I am engaging myself with. Until the next time.

Requirements, Maintanence, and Games

Looking back on one of the first game projects I worked on, I realize now, more than ever, how important good requirements are, how important good communication and best practices are in designing and developing a software system. My words are not to reflect badly on my employer or the state of their work, as all of it was student based and originally done by one person. It is to instead talk about what was wrong, why it was wrong, and the outcome because of it.

When I started work with the company, it was to focus on the implementation of a centralized game for their project. This game was already planned and was supposed to have good documentation. The first ten weeks of work was to be developing the game, while the last ten weeks was to be polish and maintenance, with extended testing and development as could be offered. However, after coming onto the project, it became quickly evident that the project was not as well planned as we had hoped or thought it would be.

The project had been written mainly by a single programmer, who also was responsible for most of the artwork. For the application, there was very little use of the XNA framework, as when the application was originally made, XNA did not have nice features such as model loading, texture loading, etc. Because of this, it had a very interesting architecture, based around working with the loading of COLLADA files and their only implemented game, a space shooter where you shoot meteors and protect friendly ships. While there did exist an architecture to extend the game, to allow for the centralized colony simulation and other mini games to come on, everything was so tightly coupled to everything else that working off of that base would have been, for lack of a better phrase, nigh impossible.

So, what should have been simple development and integration became the designing of and implementing of a game architecture that would allow for mini-games, a centralized game, and ways of communicating information between them. Along with this, it had to support the original mini-game and also somehow incorporate the particle engine that had been written for the mini-game. This process took approximately 5 weeks to build, and over the course of development for the last 5, the whole time to check maintenance-wise. And with that, came the game development.

Now, there were many ideas for the mini-game the side team was developing, and many ideas for the main game. However, there were no true requirements as to what the games should be. Some said "like SimCity, but in space!". Others were more like Railroad Tycoon in the way the transport systems should work, but they failed to mention what should be transported and how this related to the game system and mechanics. This led to what was, more or less, 5 weeks of prototyping with trying to find the mechanics and requirements that would match the game that our producer wanted, while allowing for what could be a fun and reasonable game. Looking back on this, we could have probably used the full 10 weeks just to get nice requirements and create a strong architecture, but often in industry there isn't that sort of time, nor that kind of foresight.

A result of this process, or lack thereof, has led to many problem during maintenance. Many issues that were not covered have come up, leading to some people implementing improper quick fixes. Another serious issue is, as things have built up, the lack of communication has created severe issues with how issues are handled, which has resulted in some less than sufficient or necessary changes to the project, which have further delayed the beta release.

All in all, requirements, nice, solid, good requirements and good communication would have solved many of these issues. With games, as with any software, the gauge of success and problems often can be traced back to the requirements, or lack thereof.

School and Work

On 12/31, I ended my 6 month co-op with the Autism Collaborative. However, I promised to stay on working on a few minor details that needed polishing and provide support where I could for the project.

The project was a game project aimed at Autistic children, between the ages of 10 - 14 (if my memory serves me), with symptoms similar to but possibly greater than those with Asperger's Syndrome.

The game followed a structure in which a large scale game, called the Colony Simulation, served as the center for a set of other "mini games" or "missions" to branch off of. The Colony Simulation would allow players to build a colony in deep space, allowing them to mine for ore, build residential (housing, entertainment) and commercial (stores, factories, mining plants) structures, and link them via a series of "tubes", one for each type of structural connection. This was designed this way based on our producer's experience with Autistic children and their fascinations with machines and mechanical structures. Hence, the simulation was to act like one large machine, when connected.

Each of the mini games or missions are accessible within the Colony Simulation. They can either be selected or they are generated for the user to play. The missions encapsulate many typical and interesting Autism tests, which are used within both a lab setting and data collection setting to collect information about the player.

During this period, I participated in the design, development, and currently the maintenance of the Colony Simulation. My roles primarily included task tracking, completing various tasks, and requirements elicitation (getting ideas and feedback from our producer and my co-workers). I became responsible for many of the user interactions, especially those through the GUI, which I ended up designing the framework and specifications for, since C# does not have a natural GUI implementation for XNA.

Overall, I found the experience very rewarding. Not only does it look great on my resume, but it has helped me figure out many "dos and don'ts" when it comes to games. Also, it's nice to know that what you worked on will help people.

Aside, the maintenance side has come at a hefty price, mainly personal patience and frustration. Since December, I have been enrolled back in school, finishing my Software Engineering degree. It has been difficult to perform maintenance functions, as I have been overloading for the past two quarters (20 credit hours), in order not to only finish my degree, but to also take some of the classes I want to before I graduate.

Overall, the passed several months have been hectic. We're finally at a mid alpha-beta release for the full game, which makes me happy. I am finishing testing on part of the game I have been touching up (score screens and in game artwork). I will post something when we have a release, as well as a means on how to download it.