Justin England

For any one that is actually reading this please keep in mind that I’m writing these off the top of my head.

Lets look at our entities. First we need to clearly define our entity.

Entity Definition:

An entity is controlled by either a player or an AI and can interact with a level and its
elements.

That seams simple enough for a high level definition, but I think it still needs some work. Parts of the definition seem a little ambiguous. Lets break it down further. “… is controlled by either a player or an AI…” This can be interpreted in may ways, in fact the world controlled really widens the scope of how the entities can function. Firstly I’m thinking the name ‘entity’ really does not portray the function of the object very well. What we are really taking about here are playable characters, or just characters. Lets updated are definition a little now.

Character Definition:

A playable character that can interact with a level and its elements.

This is better, I left out the player and AI section because the character really does not care what is actually controlling it. The character only cares about it’s self and the ‘world/level’ it’s currently existing in. This means we are missing some information about the character, what kinds of abilities or actions can it do, and what kinds of attributes might it have?

Lets list off our actions first.
Character Actions

• Idle
• Walking/Running
• Jumping
• Attacking
• Climbing
• Swimming

We will keep the attributes list small for now, we can always add more later.
Character Attributes

• Health
• Armor
• Strength

Abilities are actions so we don’t really need to list them off, just keep in mind that things like swimming and climbing would be considered abilities.

Justin Game Design, Programming Game Design

Not sure where to start with this. Maybe the camera. We will need a 2D camera with pan and zoom features possibly more but panning and zooming will do for a start.
We are also going to need to rough out the basics for what a level is made up of. Starting from high level well say our level is made up of a foreground and a background. Our foreground contains the objects that our player/s will interact with.

Foreground Objects

• Player/s
• Enemies
• Collideable Surfaces i.e. Ground/Water/Platforms
• Particle Emitters (and particle of course)

Lets look at our players and enemies real quick. Whats the major difference between the two? Well let first define some behavior. Both players and enemies can move, attack, and they can die. That is simple enough. Let think about what makes an enemy and enemy. It’s really only the relation between each entity. So in short an enemy is simply and entity that takes or receives damage from another entity. Typically our enemies will be controlled by their own AI but I want to support the ability for players to play on teams, so we will treat all entities the same. This means that each entity can either be controlled by a player or by AI. So really players and enemies are all the same thing and there role is simply a matter of there state.

Moving forward we have collidable surfaces. These are rather simple they can either be movable or stationary and they can change the state of an entity. What do I mean by change the state of an enemy? Well consider a water example. When an entity collides with a region classified as water then we may changes it’s movement state to swimming or depending on your game play you may change the entities state to dead. Different collidable surfaces will have different effects on the states of the entities touching or contained within them.

Particle emitters, well these are rather complicated. I’m placing them in the foreground for the time being but they might be better suited at a lower level. The idea being that just about anything in the game should be able to emit particles.

Now there are plenty more other objects we may want to implement for our level, things like triggers and such that fire off events that affect the level but we will leave them for later because we want to start simple.

So what does our level really care about? Well it’s really just a container for our game elements. It allows us to tell the renderer and content loader what to load and render. Which makes me consider our naming of the object? I think what I have described here is a scene. Because a scene would not care about any of the game play logic it simply would contain the objects that currently need loading and rendering. The level then would contain scenes and would govern the flow of events in our game. We could have 1 or more scenes in a single level.

It’s late now and I’m hungry, so I’m done.

Justin Game Design, Programming Game Design

Testing Code Tags

using System

namespace Code
{
	public class MyClass
	{
		private string[] RandomStringArray { get; set; }
		public MyClass(int randomNumber)
		{
			RandomStringArray = new string[randomNumber];
			for(int i = 0; i < randomNumber; i++)
			{
			RandomStringArray[i] = "It's a string! " + i.ToString();
			}
		}
	}
}

Justin Programming Test Post

Well I’m up and I can’t sleep, so I figured I would jot down somethings I was thinking about.

Been toying with the idea of writing a code generator for a data access layer. Most of the work I do deals with database interaction and everything is managed through stored procedures. Building a data access layer that executes stored procedure is a simple matter, but I find that I tend to stray away from actually coding one up because I don’t want to write all the tedious code needed to implement all the ORM stuffs. Which is stupid because I need to improve my codes testability and the only way thats going to be practical is if I decouple my business logic from my data access, this is basic software design.

All I need the code to generate is:

• A interface to the business object
• A data access object with mapping to the business object
• A create method for the business object in the objects factory class

Not much to it, just base it off the table schema in the database and BAM done.
The next question is whether or not I hard code the codes text inputs or design some sort of XML template system. I may save the XML templates for a refactor of the code base because I can’t think off the top of my head how I might design it.

Looks like all call it a night for now. Laptop battery is about to die. Hopefullly I can fall asleep now that this is out of my head.

Justin Programming Data Access, Design