The Z-Engine
With HTML5 and JavaScript becoming a very powerful development environment we have start working on our first publically available game engine. You can visit the website today and start learning about this exciting project and the development process.
Zax-Controls
Zax-Controls is a ASP.NET project that is open source. The goal of this project is to provide design tools to web developers so they can combine jQuery and Server Controls in web applications. You can download the source code from http://zaxcontrols.codeplex.com
Pac-Man AI
This project was designed to teach how AI works in games and was modled after the Pac-Man game of the 1980's. One of the more difficult tasks in this project was iomplementing a path finding system that would work for both limitation of the ghosts and Pac-Man himself. For this we used the A* algorithm and setup the ghosts to only be able to add sqaures that don't let them backtrack. Pac-Man on the other had used four directions in the A* algorithm to find the best rout from one point of the game field to another.
The one downside is that when a destination is not traversable then the A* algorithm has problems detecting this worse case senario. Many times the Ghost's AI would try and navigate to a square that wasn't traversalbe and the A* algorithm would do some strange things. Ultipmatly it would just crash the system because null value nodes were being accessed.
One last lesson was that it would of been nice if we had more time to work on this project instead of the two weeks diven. But then there is always the want for more time and at some point we just need to finish the project and move on. Take what we learned from it and know what we can do better the next time.
A* Algorithm
Many website have great information about this algorithm and a good AI book should explain a good amount of how to implement this algorithm. The hardest part I found about A* was knowing when to move items from the open list to the closed list. Also adding items to the open list can be tricky because it is always important to check if the new square is not on the list and if it is does it give a better score. Many times it won't for a base line which helps reduce circular or back tracking moves.The one downside is that when a destination is not traversable then the A* algorithm has problems detecting this worse case senario. Many times the Ghost's AI would try and navigate to a square that wasn't traversalbe and the A* algorithm would do some strange things. Ultipmatly it would just crash the system because null value nodes were being accessed.
Lessons Learned
Building a grid that describes how each ghosts works helped when it came to modeling the code to make them work. Creating a base ghost class that then got extended by each ghost and common features between all ghosts and then polymorphinc their unique features. Each ghosts then would just modify the needed methods of the base class to make their unique AI work. Most of the AI in Pac-Man is based around path finding between location on the game field. Planning is a very important step in AI development because it helps find commonalities between actions and helps to make more efficient code.One last lesson was that it would of been nice if we had more time to work on this project instead of the two weeks diven. But then there is always the want for more time and at some point we just need to finish the project and move on. Take what we learned from it and know what we can do better the next time.
Loki's Challenge
In this project I was the Lead game engine programmer using ActionScript as the language which was required by our college completion rules. For this post I wanted to go through many of the different challenges our team encountered and explain the difficulties we had during development.
FMOD was going to be used to handle all the sound effect and somehow bugs in the FMOD conversion didn't help which crippled the sound system. A few hours before the final deadline we had to rewrite the sound engine from scratch to make something that could play our environmental sound effects.
Waiting until the last minute to integrate a menu system. This should of been one of the first features we had done and working on the game so that we could load menus and have time to debug them. The problem with the current menu system was on the last few hours of the competition we were trying to retrofit something to make it work. Even then our credits screen got mashed to the point that only the least active members got their name on the screen.
Finding tools like tIDE that helped build the levels that looked fantastic. We learned that many times tools that have been used for a very long time may not be the best tools available. Using tools like this help the programmers focus more on the game engine and not on the tools needed to make the game.
In the end I’m still very proud of all the team members and think they all did a great job under a very stressful time. Game development can be fun but many times it is really hard work and this is especially true when you get close to the dead line.
Things that went wrong
Many of the team dropped out of the completion or just didn't have enough time to help on this project. Out of the 9 people on the team only a couple of us were active during the development process. We had to cut lots of features from the design just because of the amount of time we had to get a working version available to play and judged by industry professionals.FMOD was going to be used to handle all the sound effect and somehow bugs in the FMOD conversion didn't help which crippled the sound system. A few hours before the final deadline we had to rewrite the sound engine from scratch to make something that could play our environmental sound effects.
Waiting until the last minute to integrate a menu system. This should of been one of the first features we had done and working on the game so that we could load menus and have time to debug them. The problem with the current menu system was on the last few hours of the competition we were trying to retrofit something to make it work. Even then our credits screen got mashed to the point that only the least active members got their name on the screen.
Things that went right
The art assets started to set the tone of the game early on in the games development. Our artists kept to their ideals and gave the project 110% of their effort in the hopes that we could put something amazing together.Finding tools like tIDE that helped build the levels that looked fantastic. We learned that many times tools that have been used for a very long time may not be the best tools available. Using tools like this help the programmers focus more on the game engine and not on the tools needed to make the game.
Lessons learned
Planning is a big part of the process and on this project we had too many people trying to plan. It is great to try and involve all the members of such a small team but at some point all the team members needed to know who had the final say and when to let issue go. We had some really talented artists on the team but many times their ego’s got in the way of our final project.In the end I’m still very proud of all the team members and think they all did a great job under a very stressful time. Game development can be fun but many times it is really hard work and this is especially true when you get close to the dead line.