Pandora's Box project

Notes and thoughts about game engine development.

Friday, January 13, 2006

First changes

I have many issues with memory and resource managers.
I'd like MM to provide basic memory managed Object, which is identificable and shareable. Resources, inherited from Object, would provide a serialization mechanism for loading and saving from memory/disk. But serialization is used engine-wide; almost all objects are intended to be serialized at any time, even objects that aren't Resources, like vectors or matrices. So, I decided to pull up Object at resource level, incorporating serialization and making an identificable, shareable and serializable abstract object. All engine resources are built upon this base object.
We will have a helper class that makes the dirty job of serialization. Object-derived classes will use polymorphism to implement it, and other structures will have their functions hard-coded in serializer itself.

Tuesday, January 10, 2006

Need some input?

Design of my input system will be reused from my last project. It's made up by an event generator and an event dispatcher. It also features an event receiver manager, which manages registered receivers.
For receiver design, I use the Chain of Responsibility pattern. This gives a clearer view of the event dispatching concept. The event generator simply generates events based on previous and actual state of input devices.
I think I could have different receiver chains for each type of event. On the other hand, I don't think many input events are generated each frame, nor many receivers registered at that moment. It only adds complexity, and it's my project main goal: to avoid it.

Monday, January 09, 2006

Give me some foundation

File Manager. Wraps OS file management functions. Loads and saves data from files.
Memory Manager. Wraps memory management functions from OS. Provides standard reference counted objects, shared pointers, (maybe) garbage collection. Nothing very complex.
Resource Manager. Loads/saves resources from disk. Basic resource interface for Scene Database.
Input System. Message-based user input events dispatcher from mouse and keyboard.
Timing. Main application time management and high-precision custom counters.
Settings Manager. Data-driven module that manages constants and variables used over the engine.

This is for the Base Layer. More details on Scene Database on next post. Time to go home.

I am the architect

I have splitted the whole project architecture in hard and soft architectures. At a glance, hard stands for actual game engine, and soft is game-specific code that’s built on hard architecture.
We can get a good insight from this concept. Game engine abstracts general game requirements from platform, giving soft architecture a resource oriented interface and tools for easy constructing the game logic. This improves design and module reusability, even making hard architecture redesigning only a technology-upgrade task.
But I don’t want to make an over engineered project, so I’m aware I’ll make some changes to it. This is only the first iteration of the design process.

As you may state, AI and Scripting aren’t connected in the system. Timing, Logging and Settings Management are modules that many others use, so I don’t think it’s necessary to draw lots of lines…

Here's the hard architecture diagram. Next post I’ll write each module’s responsibilities.

Hard Architecture

Saturday, January 07, 2006

Cleanup and restart

Hello again, dear blog. It's been a long time since I last posted (now there's no trace). Just got a new project on mind and wanted to use this old blog. I like it's name!

A few weeks ago, during an AI class at college I decided what should I do with all the knowledge about game engines being accumulated (and not being actually used) in my brain. So I said "I'm gonna make a game engine".
After teacher stopped staring at me, a mate asked what I'll use it for. Obviously, for a game. But this is not a clever answer, I need to specify genre and topic. Later I was ready to answer correctly, I would make an engine for simple arcade/platforms 3D games. I thought it's something I could achieve, needed to test myself as a software engineer, coder and the most important: as someone that can actually finish a project.

From then until today I've thinking about the design, looking for zillions of threads on various topics, inspecting lots of papers and reading some excerpts from design books to help me set things up a bit before I start.
But yesterday I bumped into something in a book that made me want to continue with this blog experience. You have to be careful in research or you can be doing so until the end of days. Definitely you have to research, but you have to start someday or you'll never do anything. There's always time for researching. That's what's brought me here. So, hello again dear blog.