Jump to content
  • Advertisement


Sign in to follow this  
  • entries
  • comments
  • views

The Arena Update

Sign in to follow this  



The Arena (YAAG) has turned a corner in development that I wanted to document for other developers who have started their own new project.

The Beginning

Every project I have started the beginning starts out quickly and things seem to build quickly. This stage is full of great ideas, new experiments, and a host of thinking how great this game is going to be. But yet it is still in the idea and planning phase which I like but can't wait to start laying down some code. The foundation of the new idea is important because later stages will depend on the organization of the starting point. The Arena was developed based on a book I was reading and I wanted to try out the new ideas presented to me from the book. So for this project I spent a lot of time thinking about how the game engine was going to work and with my past experiences traps I wanted to avoid.

The Middle

At some point the development turned from planning and more focused towards development. This phase seemed to move slowly because there was a lot of foundation code that needed to be developed before being able to focus on game play and game design. Many of the releases on the surface seemed to have little or no difference but the underlining systems were starting to take shape and provide the power needed to make the game more functional and easy to manage.

The problems I ran into in this phase was man of the planneded features require systems to help handle the different game design needs. During the middle phase I noticed several issues that were difficult to manage so breaking them out into their own system made more sense then trying to make one system handle everything. These parts are as follows:

  1. The Game Engine
  2. The Entity Manager
  3. State Management

The Game Engine

The core game engine was designed to manage most of the games looping needs. I used the Update pattern that would allow the entities to run an update process every frame. Once all updates completed and if there was enough time left over the engine would then run the graphic routines to draw everything to the windows console screen. For the most part once the core game engine was completed I rarely ever touched the core code which to me seemed a good initial design.

The Entity Manager
Yes the game engine is also responsible for simulating the entities in the game but I found that expecting the game engine to do everything would limit its design. So the entity manager is used to handle the creation of game objects like all the monsters and the player. I also added the combat field to the entity manager for simple collision detection. Hooks were added to this system that allowed the game system to validate movement. There are several interfaces used to help trim down and make the entity manager accessible in several location of the game.

State Management

Originally I was trying to implement this in the Entity Manager but it started to get convoluted so I moved it to its own system that would handle all the game states. At this point the game went from one state to about 14 different states. Think of a state like a menu in a typical Windows program. One of the major design decisions was to enable the manager to overlay different states so when one state was done it would be removed from the stack and the previous state would be active again. I used an array as a stack so that it handled the different states as they would be added and removed from the game.

The original design of the state manager was to help with in game menus but as I created it the idea started to percolate in my head to use this for managing all the different screens of the game. For the latest release it integrated all the login, create account, death screens, and anything else that would be needed as a screen for the player. During this process the game started to take on a whole new feel for me on how it played. Instead of just now randomly being attack constantly by the game players now exit after each battle. Can select a new monster or exit and return to the home screen.

The one last thing I would like to say though about the state manager, it has been probably the most boring and tedious part of the development process. I spent many hours programming UI code then I would like to admit but the final design has made it fairly flexible. Now I know why many project include a dedicated UI programmer and if I could afford this luxury I would.

The Next Stage

At this point I feel the middle stage is complete and now I'm going down a new section of the project. Many different doors have opened up and the game doesn't seem so limited. Players can make a few choices that helps them focus their character on their personal play style. Most games I have worked once they entered this stage of the project I had a few weeks to do all the clean up and push the project out the door. But on this project I plan on spending as much time on this phase to add as many refined features as I possible can.

It is also important for me to also include as much testing on this current build and to do some balancing to make the game seem a little more challenging as players progress up their levels.


It has been a short development cycle for this game. I've spent maybe a few months to get the game to this point and will probably spend a couple more to finish the game. The one thing I learned and need to be careful of is how addicting the development has been to me. I've found myself spending way to much time working on this game then I should of but it has just been way to much fun! Getting to where the current state of this project has been a massive amount of work but well worth the effort.

This project has been a major learning experience for me. The first thing I have learned is how important a good foundation is needed to keep the game easy to develop. This doesn't mean I didn't run into some difficult design decisions but I did find having a solid foundation is very helpful. Next has been to not tie myself into one design decision or think that one object can do everything. Breaking complex parts of the game into more manageable pieces has been on of the biggest learning experiences for me.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!