Event Logging Forever

I’ve been working on my event logging class for some time now, indeed remarkably long for something so simple. So, why is that? Well firstly it’s because I want to get it right – logging is a really important feature for helping bug testers provide me with diagnostic information. Secondly, it’s because of all the various stages of design and development and repetition I’ve been through. That’s what I’m going to be talking about today.

So when I started, my log was a class with a single std::ofstream to which you could write lines of text. This gradually gained features: sections and indentation, error reporting, timestamps, multiple output streams, and eventually a message priority system. And I finished the log with these features a long time ago, as part of one of my first attempts at game engine creation.

However, since then I have several times restarted my engine development, whether due to a long period where lots of programming was impossible, or due to the discovery of new libraries. Well right now I think I have basically conceived a log design which need not undergo any more drastic changes.

I have at last decided on the following features:

• removal of logging at compile time (with macros)
• support for multiple output streams: files, std::ostreams and custom classes
• control of log verbosity at runtime globally and per stream
• printing of messages
• messages which wait for a response
• error messages (with message boxes)
• memory dumps
• indentation and sections
• XML logging

There might be one or two extra things, but that’s the general idea. The plan came through a lot of iterations to get there, and there are in fact hidden depths. For example, priorities of messages are just integers, but  priorities of streams have the following form:

typedef unsigned int __Priority;
struct Level {
 __Priority Priority, MaxIndent;
 bool ErrorOnly;
};

Not only do stream priorities (“levels”) have an actual priority value, they also have a maximum number of indentations they allow, and a flag to mark whether they only accept error messages. This immediately makes the concept of which level is ‘higher priority’ than another slightly trickier. Nonetheless I worked it out and abstracted the user from it via operator overloading. Hopefully I’ll be able to show you how I did it when I finally get the change to release my logging code to you!

Introduction to Resource Management

So what is the idea behind resource management? Well we’re writing a game, which as software goes, has rather a lot of resources to be managed. Textures. Models. Sounds. Music. Player save files. It seems to me that we have three options, and here they are in order of increasing usefulness.

1. Manage all resources as we go: if we need an image, type all the loading code for an image; if we need another, type it again. This is the easiest solution, and might be fine for small projects. But since we’re trying to write a reusable engine which is hopefully applicable to larger projects, it just won’t do. (Also, we’d have to be very careful to be sure we unloaded all the resources at the end when we’re done with them.)

2. Write manager classes: one to manager images, one to manage sounds and so forth. Clearly, this is better than option 1. We can save on typing by putting the loading code into a reusable member function. We can also add some nice extras like prevention of multiple loading of the same resource,  referring to resources by string IDs, and automatic unloading of resources at shutdown time.

3. Number 2 is nice, but there’s still some code redundancy remaining. What’s the difference between managing sound resources and image resources? Just the loading (and unloading) process. All management that goes on in between is pretty much the same. Thus our final option: a generic resource manager – a single class which can be used for managing images, sounds, music, you name it! If it can be loaded and unloaded, our manager will handle it!

In fact, there are going to be several resource managers, since I have two designs in mind, along with a subtle tweak to one of them. But more of that in the next post: for now I just wanted you to know the motivation for generic resource management methods.

There’s one other thing I just want to remark on now: the structure of my posts regarding each engine component. For each one, I shall release the following components in this order:

1. An article discussing the features of the component, without any actual code
2. A “code summary” post showing some or all of the header file for the class, to demonstrate its intended public interface
3. An “implementation” post in which I not only provide all the code, but also detailed descriptions as to how it works
4. A “usage” post, with a simple (but often contrived) example to show you how I intend the component to be used
5. A “testing/debugging” post in which we write another sample which tests the component’s behaviour in every different situation we can think of
6. A “samples” post in which I give some more useful examples of usage
7. A summary post, with a brief textual summary of the component’s purpose, plus a copy of it’s public interface

That’s all for now. The next post on resource management will be an article on my first resource management construct, but before then there might be some posts about video tutorials and setting up SFML 2.0 in various IDES.

Structuring an Engine

So, I have previously mentioned that we’ll be making a game engine, and I have put some resource management code up as well.

Now I don’t want to get into too much detail with the engine until we’ve seen a little more of SFML, but perhaps it would be nice if I gave you a vague idea of what I’m planning.

Well the first version of my engine will contain the following components:

• system
• graphics
• audio
• input