Today I'm going to give the broad overview of the architecture. In following posts, I'll dive down in a little more detail on the responsibilities of the various subsystems, and how they work. The source code to my engine is not available (sorry, I'm a greedy, hoarding bastard), but I will give little snippets here and there to illustrate my points.
The SENG engine is a game engine designed to play a specific type of computer role-playing games. The salient points of the engine are:
- A single player controls a party (one to four, currently) of characters.
- Gameplay is real-time but pausable; orders can be issued while the game is paused.
- Gameplay takes place primarily in areas. The party can move out of an area into another area, or into a map which supports selection of available areas to enter.
- Areas are defined by a 2 dimension array of tiles. A tile is 2.5 feet square, and an area will typically be tens to hundreds of feet per side.
- Dialog with non-player characters is an important part of the game, allowing for rich, tree based interaction.
- The SENG RPG system is designed to be a deep, balanced RPG system supporting many options of character development and specialization.
- The SENG game engine is tightly tied to the RPG system. However, customization in terms of skills, spells, character classes, items, etc, is well supported by both the engine and the RPG system.
- The graphics engine supports fully 3D graphics with smooth animation.
- In addition the graphics engine supports mix-and-match character graphics (so adding a sword to a character isn't a whole new graphic), along with color mapping and sizing. This allows many characters and tiles to be built out of a smaller set of art assets.
- No multiplayer, network support.
- SENG written in C plus plus. Most of the code is very Windows dependent, using the Windows API and DirectX 9. An exception is the RPG engine, which is basically platform independent. (More on that later.)
Whew... I hope that's most of the details. A lot of the inspiration for the SENG engine is from the old Infinity Engine games from Bioware and Black Isle. A lot of the newer RPGs in the world look a lot better, but seem to have regressed from the gameplay that made those older games great.
You can check out a demo of the SENG engine in my demo game "To The World Tree" (http://www.prankster.com/ttwt). I have made quite a bit of progress since then; the UI in particular has been revamped and looks nicer and more modern.
So, to move on to the architecture overview. Let's start with a picture:
There are five major subsystems in the SENG engine:
- "RPG Engine" - The RPG engine is in control of all gameplay; movement, combat, inventory, dialog, everything.
- "UI" - The UI manager is responsible for drawing UI widgets on the screen, and for turning Windows mouse messages into events recognizable by the SENG Application.
- "Graphics" - The graphics manager is responsible for drawing the in-game graphics. It knows how to load graphics into memory, and then looks at the game data (from the RPG Engine) to know where and when to draw the graphics via DirectX.
- "Audio" - The audio manager knows how to take events (generated by either the RPG Engine or UI) and play sounds associated with them.
- "SENG Application" - The SENG Application is the Windows application that ties everything together. It knows how to manipulate all of the other subsystems to run a game.
An important philosophy is that the 4 underlying systems are independent systems, able to be replaced with no modifications to the other systems. For instance, I have gone through 3 separate incarnations of the UI manager in the course of developing SENG. The SENG Application has to deal with changes, of course, but the other systems should be blissfully aware. I will admit that I haven't been completely perfect here, but I have been pretty good.
There are a number of advantages to keeping these systems independent and self-contained. First of all, my brain is pretty small, so being able to work on the systems in isolation, without worrying too much about the others, is definitely helpful. Second, revamping something, like the aforementioned UI manager, doesn't end up cascading through the whole code; instead the change is keep contained to just one aspect. And third, the systems can be developed and tested independently.
As an example of this third point, when I set out to write the SENG engine, it was a pretty daunting prospect. So, I started by making a text-based application, capable of playing a full game of SENG with a horrible, text menu based interface. Of course SENG isn't fun (or even really playable) in this manner. However, I then set to making the interfaces and then filling them in, for the RPG engine. So, before I even started writing the "real" application, or UI manager, or even a line of graphics code, I had a fully functional and (mostly) tested RPG engine. And, instead of giving up on my project because of the overwhelming size of it all, I was able to see visible progress even in the first weeks and months of development.
So, that's it for the overview. I'll dive into the RPG engine next time; how it interacts with the other systems and SENG application, and how it functions internally.
