Over the past few days i have been working on two things within the game as shown in the YouTube video:



The first thing i have been working on is the input system, which handles buffering and processing of input. After some discussion on the forums, i had come to the conclusion that the following things were needed:

• The input system needed to seperate the incoming messages from the game loop, so they could be processed on the game's terms, not immediately
  
• The input system needed to be able to rate limit the number of events per second, so that people with faster or slower PCs did not have an unfair advantage and that the game played the same everywhere.
  
• The system needed to retain a buffer from which events could be read
  

For the most part this new input system does exactly what it set out to do - the unfortunate side effect of an input subsystem is that it isn't something you can show to people who have an interest in your game. People making games like ourselves will look at the code in the thread above, understand what is going off and understand that a lot of time and effort has gone into it, and it has been made better. Normal users however, game fans... Let's just say they would be quite unimpressed.

With this in mind i also set out to properly load the level files which should be automatically loaded and parsed from disk when the game loads.

The level files are simple text based files, which will eventually be stored within a "pak" style archive. Each of them has a set number of instructions as shown below:VerticalConveyors 3 7 10HorizontalConveyors 3 7 9Machine 3 0Machine 10 0CrateExit 7 11OutSequence 0 mortar 1OutSequence 1 mortar 5OutSequence 1 dynamite 1CorrectOrder mortar dynamite mortarIntroTextStartWelcome to the firework factory! I am your new boss, Mr Seafor. For your first task,simply move those firework crates off the production line. BE very careful not to break any...They are a little ... volatile!IntroTextEndEndTextStartWell, all looks in order here! Congratulations on a job well done, maybe I should give you apromotion to something a little more challenging!EndTextEndFirstCrateSeconds 4TimeLimitSecs 60Music 1Pass 10
The VerticalConveyors and HorizontalConveyors fields indicate at which X and Y columns and rows there will be a horizontal or vertical conveyor belt. The game automatically places junctions at the intersections where they meet.
The Machine lines indicate the X,Y 2D coordinates of a machine on the playing field, from which crates are emitted.
The OutSequence lines indicate which types of crates come out of which machines and when, and the CorrectOrder line indicates what order the crates are expected to reach the exit. The IntroText and EndText are quite self explainatory (shown at the start and end of the level, spoken by the 'boss' character). FirstCrateSeconds indicates how long the game waits at the start of the level before producing the first crate.

I load these with a simple text file parser, which places them into a quite straightforward object:class OutSequence{private: int machine; std::string cratetype; int nextcratesecs;public: OutSequence(int mach, const std::string &crate, int nextcrate); int GetMachine(); const std::string& GetCrateType(); int GetNextCrateSecs();};class Level{public: // Position of vertical conveyor belts in the level layout std::vector VerticalConveyors; // Position of horizontal conveyor belts in the level layout std::vector HorizontalConveyors; // Positions of machines on the end of conveyor belts std::vector Machines; // Crate exit point - there can only be one in the level D2D1_POINT_2U CrateExit; // Output sequence of crates from the machines std::vector Sequence; // The expected correct order of the machines through the exit std::vector CorrectOrder; // Intro text spoken by the boss before the level begins std::string IntroText; // End of level text spoken by the boss on successful completion std::string EndText; // How long the player gets before the first crate is produced int FirstCrateSeconds; // Time limit to complete the level int TimeLimitSeconds; // Music file to play as background music std::string Music; // Percentage completion needed to pass int PassPercent; // Parses an on-disk level file Level(const std::wstring &levelfile, const int levelnum);};
These are then placed into a std::map where the key is the level number and the value is the pointer to the Level object:LevelManager::LevelManager(){ const FileList levs = Util::ReadDirectory(Util::GetExePath() + L"\\Levels\\*.lvl"); for (FileListIter f = levs.begin(); f != levs.end(); f++) { std::wstring filename = Util::GetFileName(*f); int level = _wtoi(filename.replace(filename.find(L".lvl"), filename.length(), L"").c_str()); levels[level] = new Level(*f, level); }}
Once all the levels are loaded, the system simply draws the level according to this layout, and produces the crates as specified in the configuration. These levels are entirely data driven, and a new level can be created by simply dropping a new numbered file within a directory.

Some of you may be asking why i didn't just define a two-dimensional array for the level layout, as this would be what you would usually see for a game design of this type. There are a few answers to this:

Firstly, the levels are adapted from the level design of the first game, which also did not use an array of sprite types. Due to wanting to re-use the data and designs, I decided to keep the same layout.

Secondly, designing the level in this way means that there is less chance for an error in level design. It is not possible to place a junction where there is no conveyor, or place a conveyor that ends abruptly without exiting properly, or anything of that nature. The system smartly places the conveyors and junctions just based on the one position.

As i plan to eventually let users design their own levels and publish them online, this is an important factor, the simplier i can make the level editor, the better as I want this to be something any gamer can just pick up the game and do, not someone aspiring to make games who might already be a bit technically minded.

As you can also see from the YouTube video i have added the animation now for the crate exit. Unlike in the 2D version of the game, where the crates simply dissapeared on contact with the exit, in the 3D version of the game, the exit transports the crate away off-screen, accellerating quite rapidly, then returning. The idea is that any crates left waiting at the exit whilst the transport plate is "away" will queue up in a line, which should add a bit to the challenge and add an interesting gameplay mechanic.

Next on the list to code is dispatching of crates, and crate movement around the level.

As always, comments welcome!