Data Oriented OR Object Oriented Programming?

    ^--OOP      VS     DDP--^

This topic is important when developing a game engine. Let's quickly go over the definition of both. 

So object oriented programming or OOP is a programming style that represents attributes of data as objects and  is associated with procedures known as functions or methods depending on what language you are using. These objects are usually instances of classes and are used to interact with other classes to formulate an application such as a game. Examples of object oriented languages would be C++ Java, and C#. 

Data Oriented Programming or Data Driven Programming (DDP (Not Disney's Dining Plan)) is a programming style in which the program statements describe the data to be matched and the processing required rather than defining a sequence of steps to be taken. Languages that follow this would sed and AWK. This is not limited to the other OOP languages as well

These languages that are designed for DDP are known as line-oriented languages because the data sequences are in lines as they go into the input stream.

These are two of the different programming styles we have been taught so far in my program but there are countless programming styles like the imperative style,  functional style, logic style and so on. Each style is used for different practices. 

There are benefits to both of these styles and there are some objections one might have to using one or the other. Most of the benefits for one language are the objection for the other language. For example, user friendly readability is a benefit to OOP while it becomes an objection in DDP. The reason for this is because the when data is organized in OOP it's put into objects which is easy for the programmer to read and understand. With DDP, it's a different way of thinking. The data is streamlined together. So say there are multiple enemies and they all have two properties such as health and armor. The data would be organized by a long stream of all enemies health, then all enemies armor. This becomes a little more difficult to read as a programmer. However, the benefits from this is it's more cache coherent. Being cache coherent means to be consistently store local data in the cache. This is good because the cache doesn't have to always be switching data and wasting valuable time. OOP is not very cache coherent and would be one of the objections one might have to using that style of programming. 

So far in our game we are using OOP because it is very easy to work with since we have had more experience with it than DDP. We hope to transfer our style to DDP to optimize our run times in the later semester. 

Tools For Aeolus

Here I will go over the tools and components we will be using in our engine for our game Aeolus. Really quickly our name for the game came from the Greek God of the Winds. It was initially a toss up between Fly For Pinks or Fight For Keeps because of the mechanic that will later be implemented into the game for it's online play where a player can battle online against other players and gamble the helicopter they use in the battle. The name was later changed to Aeolus because a decision could not be made at the name creation meeting and there was no dislikes for it.

Here is one of my quick rough sketches of the gameplay when playing in the campaign. In this image of the player's perspective you can see the player is trying to complete the objective to destroy a small airport using a variety of weapons that they have customized for their helicopter.  

There is a lot that is needed to have this become a functional game. Our team will have to put a lot of tools and components together to develop the game. Before I get into this, let me say a little more about the game so we know what components are required to complete such a project. So, our game's high concept is "A futuristic helicopter combat game. You’re a mercenary in an endless war. You can create your own helicopter, and gamble parts online.". That means our game will need to have a player, who can fight in this war since he's a mercenary. He must also be able to create a helicopter that he can fly and use to fight in this war. If the helicopter can be created he can probably also customize it so there will need to be a system for that too. And gambling parts online means there will be online, and another system that will handle player's helicopter's and parts. That's a lot of components.

So what do we need first? We need an engine to build this game. Which means we are going to need certain engine blocks to get this game up and running. Well it's great that our TA Saad has given us a framework to start with. This framework to the engine we like to call TwoLoc. This name came from a joke made by the previous year from us where everything can be done in two lines of code. The framework has a lot of the components we need for the game's engine such as Ogre, our rendering tool for displaying images on the screen and Havok, the physics tool used to handle all of the related physics in our game.

We still need to add other tools to this engine. One of the first tools we are going to implement is FMOD. This component to our game engine will give us the ability to play sounds in our game. We are also going to add Squirrel SQL into our game engine. This tool will allow our engine to read scripts which will be used for initializing game objects and gameplay. We hope to have as much game code done with scripts as possible. If that is done then we have successfully separated the gameplay code from the game engine code. In the following semester we plan on implementing another tool called RakNet which is a multiplayer game network engine.  

Some smaller systems that we are planning to implement into the game will include phantoms for triggers and events. The support from this comes from Havok. Another small system will be for AI which will control the steering behaviors and goals of the enemy A.I. For the first semester we will only have static AI with simple goals to try and shoot the player.

When it comes to the player, their helicopter will be broken up into different parts such as the engine, generator, and weapons. Each one of these are entities. The player can put these parts together to create a personal helicopter which is one entity that has the smaller components parented to it. The scene is comprised of scenery objects, a terrain, particles, sounds, and turrets. All of these objects in the scene will also be entities. 

This is the plan for the layout of the game. If you have anymore questions on the tools or our engine design feel free to tweet at our studio, @studio6games or leave a post on our website facebook.com/studio6games .

First Game Engines Class

Welcome to my Game Engine Design and Implementations blog posts.

I have finally decided to start writing blogs about my game engines class. For the next month I will do my best to deliver an engines blog every other day. Now that's out of the way, let's talk engines. What is an engine? Well, let's break it down further than that. What is a game? A game is a very broad term that can encompass everything from board games like Chess or Monopoly to card games, casino games, video games, sports games, the way children play together can be assortment of games. Nowadays when people hear the word "game" people often think of a digital or virtual world with a main character that's either a human, an animal, or a machine that is controlled by the player. A game has many other components to it and you can read all about those details in my Game Design blogs. Now what is an engine? When people here this they normally imagine a 4 cylinder engine within a car. The mechanical structure of a cars engine is similar to a game engine. 

The very first good reference of the term "game engine" came from the extremely popular game Doom back in the mid 1990's. With their architecture reasonably defining separation between its core software components like graphics, physics, and sound systems as well as the art assets, game worlds, and rules of play for the gameplay experience. Another great example of an early game engine would be the Quake game engine. Sometimes a game and it's engine are hard to separate. Some engines are made with a clear distinction and others, such as my game last year, had almost no attempt to separate the two. The more separated the game is from the engine to more reusable it is for developing another game. Here are some examples of games and their engines in relation to their usability:

.

So as you can see games like my Bullet Devil from last year would fit in close to PacMan. Our game this year would be more in between the Hydro Thunder Engine and Quake III Engine since we are planning to do our best to separate the game as much as possible from the engine. Since we will be working with an engine developed by our T.A Saad there is a lot of base engine framework work already completed for us. I will talk more about our game in the upcoming blog.  

A game engine will vary depending on what genre it is made to develop games for. This is why in the image above you see that an engine that can be used to develop any game imaginable is nearly impossible. The same can be applied to engines with cars again. There are different engines for different sized cars, there's engines for boats, planes, snowmobiles, and even lawnmowers. Think of all of these types of vehicles as a genre of game type. A car engine will work well for most subsets of cars but not so well for a fishing boat. Likewise in games, a first-person shooter game engine will work well for most games that will be FPS styled but will not work so well for a real-time strategy game.  

There is lots to talk about in regards to engines. In my next blog I will go over in more detail about components of an engine and talk about my game Aeolus. I will also be making lots of references to this textbook as well as the lectures from my engines class.