The scripting for this particular scene goes kind of like this (simplified version)…

function SailAway()
{
	// Load needed resources...
	local imgDash = resourcemanager.Get(ResourceType.IMAGE, "Sequences_Debut_Dash");
	local imgWestonOnFire = resourcemanager.Get(ResourceType.IMAGE, "Sequences_Debut_WestonOnFire");
	local imgEnd1Shore = resourcemanager.Get(ResourceType.IMAGE, "Sequences_End1Shore");
	local sngDetermination = resourcemanager.Get(ResourceType.SOUND, "Determination");
	// ...

	// Create a UI Scene to use
	local scene = CUIScene.Create();
	scene.Activate();

	// Create two widgets to display a background, and a front image
	local back = CWidget.Create(scene.GetRootWidget());
	local front = CWidget.Create(scene.GetRootWidget());

	// Setup the images
	back.SetBackgroundImage(imgWestonOnFire, CColour4.WHITE);
	front.SetBackgroundImage(imgDash, CColour4.WHITE);

	// Setup background and foreground images movement using some helper classes
	// ...

	//
	// First part - Weston appearing, with the "fire" background
	//

	// play introduction song as weston appears
	local sngH = soundmanager.Play(sngDetermination, false);
	TickFor(2.0); // animate everything for 2 seconds
	// starts a fade out on the song, that takes 4 seconds
	soundmanager.SetFade(sngH, 0, 4.0);
	TickFor(1.0); // animate for 1.0

	//
	// Second part - weston surprised
	//

	// Show weston surprised at shore
	front.SetBackgroundImage(imgEnd1Shore, CColour4.WHITE);
	// Play "surprised" sound
	soundmanager.Play(sndWhat, false);
	TickFor(1.0);

	// .. and the list goes on, serially showing images,
	// playing sounds, fading, etc

}

My engine doesn’t have any specific support for cutscenes, or fancy editors, so each cutscene is basically handcoded.

I do have some utility code to automate a fade in/ou, or move an image around for example.

I use mostly C++, so I’m used to strongly typed languages. Using a scripting language like squirrel is a bit painful at start, as the compiler isn’t much of a help catching mistakes. On the other hand, it does force you to pay more attention on what you’re doing.

Overall, I’m happy with squirrel. The library is relatively small, and with a bit of effort you can find your way around.

In the future I’ll probably try some other scripting languages, particularly Lua, since it’s so widespread in the games industry, or AngelScript, which is not that widespread, but has a nice feature set and it’s closer to C++.

You can download it here.
Just unpack to a folder, and run the “LaunchPH5_5” batch script. It will automatically launch PH5.5 running inside DOSBox.

I coded pretty much everything apart from a really nice graphics library I got from a book, and most of the work was done during 1998 Summer holidays. Some of the awesome features (in 1997-1998 at least):

• Runs in VGA VESA mode, 800×600, with support for Linear Frame Buffer. (Sounds like Chinese to you? If not, then you’re getting old)
• Optimized 256 colour palette.
• Coded in good old Watcom C++ for DOS, and runs in protected mode (uses PMODE/W)
• The sound system itself was quite nice, support a couple of things not commonly found:
• Critical mixing functions coded in hand optimized assembly
• Support from SB Mono to SB 16.
• Support for Gravis Ultrasound, both hardware mixing, or software mixing, to work around the hardware voices limitation.
• Mono, Stereo, 8 and 16 bits support
• Fixed point mixing
• Quite decent Impulse Tracker format support

The art was done by a friend of mine.
Music was done by that same friend, and a friend of his, whom I never met, using Impulse Tracker.
Two of the songs were mine, but not as good as the other ones, since after all I was the coder!

Just look at these awesome screen shots!
Keep in mind that’s from 1998, using a 800×600 8bits display mode

Sound Setup Screen

Coded in ASCII mode. Look at those amazing shadows

Start-up screen

The awesome start-up screen, calculating some really useful lookup tables.
Also, note the 800×600 video mode, at 8 bits. Live wasn’t easy.

User Interface (Trance Zone)

The UI was divided in two zones
The background art was indeed nice. The way everything fits on top is a bit crude without antialiasing, because with just 256 colours, it was a limited palette to choose from.
The spheres with the song names were faded in and out in a cycle.

Trip-Hop Zone

And the other zone, which we could scroll to. It had a complete different set of colours, which didn’t help. Both zone colours came from the same 256 colour palette.

Some options

I had some options for sound and the graphics. Turning off interpolation would only have an effect if using software mixing of course.

Credits

Notice the transparency of the dialog box. As all the other screenshots, still using the same colour palette.

Conclusion

That was the first project I started, finished, and released.
Also, the first project using the original czPlayer. The current version still has a bit of that code, but most of it has been refactored.
It’s an interesting experience to look at code I wrote >12 years ago, with a complete coding style.
Was an interesting thing to work on. I remember sitting down with my friend to discuss details and take a look at each other’s work.
Also, I remember a particular day I was brainstorming about display modes, and If I could go for 16bits/24bits mode, which would look a lot nicer, but would require a lot more CPU at that time.

These were the specs of the computer I used for coding:

• Pentium 233 MMX
• 32 MB
• About 20 MB of Hard Drive space, for code and assets
• SB16 clone, and a GUS sound cards
• Cirrus Logic Laguna 5464 PCI graphics card

I’ve been so quiet for a reason…
Last 2 months I’ve been looking for a new position in the games industry, and finally got one in Scotland-Dundee.

You can download the new version here :
Download lastest czPlayer demo

However it lacks some features:

• The quick buffer size is hard-coded in the class, instead of template-based.
• When reverting to heap based, it doesn’t use any mechanisms to minimize allocations/ deallocations, like for example (Reference counting and Copy-On-Write)

Since I’m starting a new hobby project (my own small game engine), to test ideas and learn some new things, the first thing I’m coding is my own String class, which I’m also using as an exercise to test some more advanced templates stuff, instead of the classical “container of values of type T”.

So… about my String class.

Features:

• Completely template based, using policies like described in the book Modern C++. This allows for a great deal of customization.
• Using policies, it supports multiple types of string storage. Currently it support 2 storage types:
  • Heap based with reference counting and Copy-On-Write, to delay memory allocations/deallocations as much as possible.
  • Quick buffer based (like CEGUI), but with fallback to Heap based like described above when the data doesn’t fit the quick buffer. Also, the quick buffer size itself is a template parameter, so we set the size based on the use we have in mind.
• We can mix strings declared with different policies (the ones provided), and internally it will still try to minimize memory allocations/deallocations, by using reference counting and Copy-On-Write when possible.
• We can specify our own Allocator for heap based strings
• Basic methods for manipulations. I need to implement a lot more.

Missing/Todo:

• More methods for manipulations (make it more compatible with the std::string)
• Unicode support. I’ve laid down the bases for that, but currently only works with char type

When coding it, I’ve used CppUnite2 for the tests. See this link for more information (Games from Within: CppUnitLite2 1.1).

I haven’t used this String class in a complex product yet, only in the tests during development, so I can’t talk about performance or bugs yet.

If you want to check it out, download it below:

NOTE: I’ve only tested it with Visual Studio 2005 (with sp1), so the provided project files are for that same compiler.

czString Download

If you’re one of the employers I had/will have interviews with, and you’re reading this, I really hope the site won’t offline for too long.

If so, go ahead, download the new version and give it a try:
Download lastest czPlayer demo.

class MODModule
{
	// ...
	bool m_loaded;
	bool m_playing;
	bool m_paused;
	bool m_reachedEnd;
};

What’s the problem with this approach ?
Let’s see…
Suppose I want to call methods on the MOD object (e.g: Pause(), Resume(), etc)
I need to make some checks in each method.

To pause…

if (!m_loaded || m_playing || m_paused)
	return SOME_ERROR;
m_pause = true;
// ... do pause stuff

Then to resume…

if (!m_loaded || !m_paused)
	return SOME_ERROR;
m_paused = false;
// ... do resume stuff

When the MOD finishes playing, I needed something like this…

// ... some code that checks for end
m_reachedEnd = true;
//ups... How about m_playing, m_paused?
//We need to change their values, so we don't break code elsewhere
m_playing = false;
m_pause = false;

And similar things when playing, stopping, etc.
See the problems?

• We need checks for multiples variables
• We need to make sure the variables have valid values in relation to each other
• What if we want to add an extra state? For example, “bool m_fading”. We would need to examine a lot of code to check how the other variables are used, and hardwire this new one somewhere. Every time you need to add an extra variable, you’ll need to check more and more code to make sure everything is ok.

Now look at the meaning of the variables. They are mostly mutually exclusive.

• If it’s playing, it can’t be paused and hasn’t reached the end.
• If it’s paused, it’s not playing, and hasn’t reached the end yet.
• … and so on….

The more data members a class has, the harder it gets to keep the object in a valid state, so, the less data to manage, the better. Less maintenance and less bugs.

One technique I use a lot when trying to simplify code is to look at it with state diagrams whenever possible.
Here it is what happens (kind of) with instances of the MODModule class:

I can easily translate it to code with enums.

enum MODState
{
    MOD_STATE_NOT_LOADED,
    MOD_STATE_STOPPED,
    MOD_STATE_PLAYING,
    MOD_STATE_PAUSED,
    MOD_STATE_REACHED_END
};

class MODModule
{
    // ...
    MODState m_state; // Now we have only one variable
};

This approach is a lot easier to maintain, and less error prone.
Now the code in most functions become something like this:

To play…

if (m_state!=MOD_STATE_STOPPED)
    return SOME_ERROR;
m_state = MOD_STATE_PLAYING;
// ... do play stuff

To pause…

if (m_state!=MOD_STATE_PLAYING)
    return SOME_ERROR;
m_state = MOD_STATE_PAUSED;
// ... do pause stuff

To resume…

if (m_state!=MOD_STATE_PAUSED)
    return SOME_ERROR;
m_state = MOD_STATE_PLAYING;
// ... do resume stuff

To stop…

// We cannot stop if it's not even loaded yet, or it's already stopped
if (m_state==MOD_STATE_NOT_LOADED || m_state==MOD_STATE_STOPPED)
    return SOME_ERROR;
m_state = MOD_STATE_STOPPED;
// ... do stop stuff

The code may look similar, but it’s a lot less error prone, easier to follow and maintain.
Looking at the State Diagram, I could easily squeeze in a “Fading” state and understand the conditions to enter or leave that state.

As a bonus, using enums will enforce more rules and help you out with errors the compiler might catch. Always prefer compile-time errors over run-time errors.

Download lastest czPlayer demo.