Week 3: Design Patterns

This week our class focused on design patterns that are commonly used in software design. We covered the factory, facade, state and singleton patterns. 

Factory Pattern

The factory pattern is basically the idea that you have one place where you can create your objects. All it requires is for you to pass in an ID indicating which object you'd like created and the factory will create it for you. This design pattern is especially useful in terms of implementing support for scripting. As opposed to having a user explicitly instantiate objects, we would simply have them call the factory and ask for the factory to create the object for them. This simplifies the process for the user of the script, as they don't have to worry about what is going on in the background. This also gives control to the engine programmers as they determine how objects will be instantiated through the factory.

Facade Pattern

The facade design pattern simply involves taking a collection of related classes and giving them a single interface to communicate with a the interface of a different system. If we think of our code as a store, and objects as employees, these would be the managers of a specific department. Managers of different departments communicate information about their own individual apartments to each other and/or to their managers. 

This also keeps each major component of a framework independent of another. If your graphics and physics systems must communicate but are tied together, then you won't be able to change one without affecting the other. Using the facade design pattern we would have them communicate from a single interface, and if say we wanted to update the physics system because it was poorly designed on the first pass, then we would only change that system. This design pattern keeps communication between systems clean, avoiding the messy practice of unnecessary interdependent systems.

State Pattern

Having used states in the past, and experiencing first hand the nightmare of maintaining all those states, I can only thank the software design gods for revealing this design pattern to humanity.

Thank you Software God for revealing these design patterns to us.
And ye

This design pattern involves creating a state manager that handles the logic and switching of states in an object. The use of a manager also allows the code to be shared between functions since it is not hard coded into a single class. This design pattern makes state hadnling a much more managable, clearer and cleaner process.

Singleton Pattern

The singleton pattern basically limits the instantiation of a class to one object. Put simply, you would use the singleton pattern in situations where you only need one of that specific object. Some examples given in class included only requiring one renderer or one mouse. This is implemented through a class that contains a static data member, and all instantiations of that class point to the same place in memory. 

The most obvious example of where this design pattern should be used is in something like a Game class, where your main game loops are; you don't want to open multiple instances of a game at the same time! Although I've never heard of anyone doing this, I'm sure it has somehow happened before. Any manager of a system or subsystem should also be a singleton. The idea is to have just one.

This design pattern is one that I've actually used before. Although I didn't really use it for the important things, like renderers, physics managers, animation managers and the like - I used it for storing mesh information and texture information.

Our second year game, a bullet hell shooter titled The Next Dimension, had to render several enemies on screen at once. Initially, we had set up our classes such that each enemy object stored all the information necessary to render it, which was really just a mesh and a texture. The problem with this was that we were storing the same texture and mesh information, about 100 times. When we realized this, it was a simple solution really; all we had to do was make sure that the texture and mesh were shared across all instances of the objects such that they could be accessed and drawn 100 times, whilst only having to store it once.

Singletons mostly seem there to protect the dynamic loading of objects in code, as you never know who might try to instantiate more than one instance of an object.

Week 2: Engine Design Plans

This week we had a class on modularity. The class was enlightening and got me thinking more about the design of our engine for this year.

Last year our 'engine' - if it can even be called that - was fairly modular compared to what we had done before but that's not saying much. The components weren't exactly designed well in and of themselves, but most could be dragged and dropped into another project and be used there (although there was some dependencies on the math libraries). Our biggest problem was actually that it was difficult to manage all the code. We didn't implement any managers. We didn't really allow for communication between systems and so code that should have been encapsulated within a manager class ended up all over the place. We also had no tools, which made designing levels and particle systems difficult as they were had to be hard coded, and everything always had to be recompiled.

Bottom line is development tools were non-existent last year in our engine. The code was messy and difficult to manage, and even though our game turned out fine, it really could have gone more smoothly.

Based on the design of the game described in my previous post, the lower level functions such as the physics, graphics, animation, collision, artificial intelligence, audio, input systems and the core gameplay mechanics will be built into the engine itself.

The game modes will all be done using scripts which will allow us to quickly test game modes and re-balance them without having to recompile the engine. I also hope that our development tools will include at the very least a level editor, a particle designer and a menu creator.

Week 1: Game Idea

Starfish: Battle Royale (name subject to change)

Introduction

Starfish: Battle Royale will be a party fighting game in the same vein as games such as Rag Doll Kung Fu™: Fists of Plastic, and the Super Smash Bros. franchise. The game will feature several traditional multiplayer game modes such as King of the Hill, Capture the Flag and Team Deathmatch. The game will be geared to more casual audiences and will be easily accessible to most age groups.

Gameplay Overview

Starfish: Battle Royale will feature simple gameplay; players can move, jump and hit each other with a stick/sword/lightsaber. Items in the future may have on-hit effects such as freezing, slowing or burning, however, at this time we will be focusing on the simple mechanic of players being able to hit each other. In the future we also plan to introduce hit-streaks such that if a player gets several consecutive hits without a miss, they will be rewarded. Levels will feature deadly obstacles that players must avoid, and levels will be designed to accommodate as many game modes as possible.

Game Modes

All game modes feature the same gameplay. The only difference will be the win condition and rules for each game mode.

Capture the Flag

Capture the enemy team’s flag and return it to your base for points. First to X amount of points wins.

Survival Zombie Tag

One player starts as a zombie. All other players are trying to survive until the end of the round. When a player is hit by the zombie, they also become a zombie. If all players become zombies, the zombies win. Otherwise the last surviving player wins.

Deathmatch

All players are trying to knock each other out for points. The player with the most points wins.

Hunter

A team of players are designated as hunters who hunt the opposing team. The opposing team’s objective is to survive or eliminate the hunters, while the hunters’ objective is to eliminate the opposing team.

Protect the King

Two teams of three or more each. One player on each team is designated as the King of that team. The opposing team must kill the king, although they do not know who the king is until the king is hit. First team to eliminate the king wins.

King of the Hill

Object is to stay on top of hill the longest. Other players try to knock each other off the the hill to become king.

Project Scope

The game's design is very simple at its core. The reason for this is because we really have to limit our scope. In the past we have designed complicated games that had to constantly be redesigned. This game is very basic, and we can always build up on it later on as opposed to completely redesigning. 

In terms of the design of the engine, the only thing that seems to be an obstacle at the moment is learning how to use the TwoLoc framework. This will obviously change in the coming weeks but at the moment I only have a basic understanding of game engines and I hope that what we're planning will work. More on the engine design in the next post.