Thursday, October 29, 2009
Working on graphics upgrade.
While attempting to make my engine as flexible as possible, I have been trying to imagine what a user would need should they decide to write a 3d graphics module for it. As I pondered, I came up with a slew of things needed to make it 3d capable. Looking at this list, I have decided to try to write my own 3d module. The draw back: I've never done anything 3D, so, I am now teaching myself 3D programming, and modeling. This will take some time, so I will be posting updates of my progress.
Sunday, October 11, 2009
A quick overview of what I am attempting to accomplish with this project.
Why another game engine? With all of the game engines out there, why am I writing a new one? The answers to those questions and more may take a bit of explaining.
First of all, finding an engine that is geared to roguelike style role playing games are difficult to say the least. Why roguelike? Well, to put it simply, roguelike RPGs can be unpredictable. With most RPGs, once you have solved the game, replaying it again can be boring. It is predictable. You know where to go next to solve the next part of the game. With roguelike, the levels are generated randomly, and in some cases, the quests as well. To me, that is far more enjoyable.
Okay, we've established that, so what am I going to bring to this engine?
Obviously I will be making the levels randomly generated. In the generation, the levels should be done in a logical manner. For instance: a level representing the dungeons below a castle should be arranged with small cells, a main corridor, with a spattering of guard rooms and other utility rooms. A cave should consist of caverns and tunnels, and look cavern-like. There should be a randomly generated world that looks realistic, with logical placement of cities and towns. The territories of different nations and races should be logical. The player should automatically be away of the region where they grew up. With my generators, they utilize a variety of methods for generation along with patterned randomness and include analyzers to determine if it was generated correctly and how to place objects, monsters, NPCs, etc....
To make the game more random: the quests, including the main quests, are generated randomly. Once again, the generation should be done logically as well as pertinent to the character. One way I will achieve this is by defining a variety of possible quest goals using scripting. The script will only be a skeleton of the quest, with the details filled in by the parameters of the script as well as the needs established by the engine.
To add to the replayability, the engine is being designed in a modular fashion. To explain: the generators for the different levels are designed to be dynamically detected and loaded as plug-ins. This allows others to develop different type of generators and include them in the game. The game it self is run by a main script, with helper scripts to handle the details. The scripts can be modified or new scripts written to include the new generator. Also, the module that handles how the game is displayed can also be custom, as it too is a plug-in. Currently there is only one graphics manager and it is designed to use the traditional ASCII characters for the art. Other, capable users who wish to see better graphics may write their own manager and plug it in.
For more expandability, most of the operation of the game will be handled by user customizable scripts. I will also include the ability to package user created scripts and modules with the appropriate data files together to form a module (Mod). As previously mentioned, most of the flow of the game will be handled by scripts, other scripts will manage things like: races, character classes, world history, AI, actions like spells and special attacks. There will be scripts to handle how the dungeons are created and populated. There will be scripts to handle quests, both main and secondary.
That is a small summary of the things that will be in the engine.
First of all, finding an engine that is geared to roguelike style role playing games are difficult to say the least. Why roguelike? Well, to put it simply, roguelike RPGs can be unpredictable. With most RPGs, once you have solved the game, replaying it again can be boring. It is predictable. You know where to go next to solve the next part of the game. With roguelike, the levels are generated randomly, and in some cases, the quests as well. To me, that is far more enjoyable.
Okay, we've established that, so what am I going to bring to this engine?
Obviously I will be making the levels randomly generated. In the generation, the levels should be done in a logical manner. For instance: a level representing the dungeons below a castle should be arranged with small cells, a main corridor, with a spattering of guard rooms and other utility rooms. A cave should consist of caverns and tunnels, and look cavern-like. There should be a randomly generated world that looks realistic, with logical placement of cities and towns. The territories of different nations and races should be logical. The player should automatically be away of the region where they grew up. With my generators, they utilize a variety of methods for generation along with patterned randomness and include analyzers to determine if it was generated correctly and how to place objects, monsters, NPCs, etc....
To make the game more random: the quests, including the main quests, are generated randomly. Once again, the generation should be done logically as well as pertinent to the character. One way I will achieve this is by defining a variety of possible quest goals using scripting. The script will only be a skeleton of the quest, with the details filled in by the parameters of the script as well as the needs established by the engine.
To add to the replayability, the engine is being designed in a modular fashion. To explain: the generators for the different levels are designed to be dynamically detected and loaded as plug-ins. This allows others to develop different type of generators and include them in the game. The game it self is run by a main script, with helper scripts to handle the details. The scripts can be modified or new scripts written to include the new generator. Also, the module that handles how the game is displayed can also be custom, as it too is a plug-in. Currently there is only one graphics manager and it is designed to use the traditional ASCII characters for the art. Other, capable users who wish to see better graphics may write their own manager and plug it in.
For more expandability, most of the operation of the game will be handled by user customizable scripts. I will also include the ability to package user created scripts and modules with the appropriate data files together to form a module (Mod). As previously mentioned, most of the flow of the game will be handled by scripts, other scripts will manage things like: races, character classes, world history, AI, actions like spells and special attacks. There will be scripts to handle how the dungeons are created and populated. There will be scripts to handle quests, both main and secondary.
That is a small summary of the things that will be in the engine.
About Documentation and code clean-up
I am certain that a lot of you who see my code and my svn comments that I have a lot of commits stating that the purpose of the commit is for documentation and code clean-up. I will now attempt to clear up what that means:
Documentation: Going through the code line-by-line and adding summary tags as well as commenting sections of code that may be harder to follow then others.
Code clean-up: Going through the code line-by-line and determining what areas are not essential and which ones could be improved. This is also when I run the FX-COP and Style-COP on the code and make the necessary corrections.
Documentation: Going through the code line-by-line and adding summary tags as well as commenting sections of code that may be harder to follow then others.
Code clean-up: Going through the code line-by-line and determining what areas are not essential and which ones could be improved. This is also when I run the FX-COP and Style-COP on the code and make the necessary corrections.
A new blog for an active project.
Due to the fact that I find myself often wanting to describe the process by which I write my code, I have decided to start a blog. Here you will find my thoughts and reasoning for the current course I have set myself on while I develop my project.
Subscribe to:
Posts (Atom)