For a while, I've been looking for an easy way to add lighting to my games. Well, I stumbled across Light There Be Light (discussed here Sourceforge project here) and I've found what seems to be a really simple lighting library, used with SFML.

Using this library, I've added a Fog Of War element to the game. Basically, I'm just assigning a view range for my soldiers/towers/bases and making the lighting reach that radius:

I don't have time to do an extensive update, but I have one team's soldiers moving towards the opponents base and, when in range (or contact if melee class), begins to fire upon him. The enemy base can die, and then...well, nothing happens as there's nothing else to do.

Next I need to add some simple UI for the player to choose what Unit to release (currently it only does 1 type per run).

Here are 2 images, one with a group of archers firing on the base, one with simple foot soldiers shooting the base (using temporary images for now...you can see the tiny swords from the big swords...well, imagine a someone swinging that sword):

Well, I've started my next little game, currently called Attack and Defend. I plan on it being a single player or multiplayer game which is part League of Legends and part Tower Defense. I'm planning on using my Escape Entity System mentioned in my last entry.

Basically, 2 (or maybe more) player have bases at opposite ends of a map. They have a starting amount of money, and they can release their own "Soldiers" and build their own "Towers". Each Soldier and Tower (both of which will have multiple types) cost some money to create. You earn money by destroying your opponents players, and getting a certain income every so often. To win, kill your other players base.

Each soldier can go down one of the multiple paths between bases. There will be a fog-of-war detail so you can't see what the enemy is doing unless you have soldiers around the area.

Work Currently Done So far I've got the main skeleton for the code down. The 1st pieces Iv'e done are create some components and an entity factory.

A typical Soldier entity will contain a Physics, Graphics, Health, and Soldier. When it comes in contact with something it's concerned with, a Collision component will be added (and removed when separated). You'll also have the ability to individually control a Soldier. this might be good for the more powerful soldiers, for the player to have detailed control over. Which brings me to...

The EntityFactory. This will create all the entities for the game. When it loads, it should read from some xml files that details the entities. For example, here my current Soldiers xml data file:

Footsoldier.png 40 10 600 Sword.png 50 0 10

Knight.png 70 30 800 Mace.png 100 0 30

Archer.png 40 15 700 Arrow.png 40 200 25

BlackWizard.png 40 30 750 Fireball.png 40 250 50

When the player creates a soldier, the entity factory will know what it's default values are.

That's basically where I am. I plan on working on some of the systems next time.

It's been a while since I last updated, and I had just recently implemented a Component Based Entity System. However, while it was great fun working with the components, and having the events passed between them all, I think there's a better way. The better way is how the Artemis System works.

The main idea behind it is having Components contain ONLY data no logic. Instead you have Systems which operate on Components. Entities are basically a unique value, which binds the Components together.

Escape Entity System from a Users Perspective In the ECS (Entity Component System) I've designed, named Escape System (since I kept typing Esc instead of Ecs while developing it, I named it Escape), it holds to this premise, with only the slightest exceptions. You can check out the source by by Github repo, Escape-System (TestEcs.cpp/h are the example files). the files in the include folder are the public ones.

From the User point of view, you have your components (which inherit the Esc Component). Here's a Health Component, which would go in any entity that has health and can die:

You can see I cheat a little having the little bit of Logic in my class. I could've called GetHealth, addded the Damage, and SetHealth, but I see no reason. And, here's an example Damage Component. which goes into any entity that can cause damage on collision.

Before anything else, Initialize will be called, and it calls it's parent class to describe what kind of entities it wants to be called Update on. In this case, we only want entities with a Collision Component (added to a component when it collides, and removed when it separates) and a Health component. Then, Update is called every tick on any entity with those components. This only happens when entities are colliding, so it happens rarely.

Systems can be setup to be called at certain timed intervals as well.

Escape System Internals Internally, the Escape System handles all changes to the World (or items living in the World) before an Update. So, everytime you add, remove, or change a System, Entity or Component (assuming they are in the World), the Escape System tracks the changes in their order. When World::Update is called, the 1st thing it does is applies all the changes. This helps alleviate any conflicts. Here's the beginning of the World::Update code:

Every time a Component is created, it gets assign a Component bit. The same Component types get the same bit, and the entities hold a bit map of all the components it owns (using boost::dynamic_bitset) These bits are what the Systems use to determine which entities/components need to be called. Here's a what happens when a System is added.

Each System can Overload the PreStep() function which will get called once before a round of Updates. This allows Systems to preload any content they might need for every component/entity called in Update.

Each Entity can belong to a group, and anyone can get a list of all the Entities in a Group. I use this for a Tagging system as well, by just assuming only 1 entity will be in that specific group.

Also, the User can assign a Local ID to the world. This will allow the entities to be truly unique if playing a multi-player game. Typical Entities Id' use an uint64_t, but the top 32 bits are reserved for the LocalID (which could be the IP address, or a User ID assigned by the networking system used).

So, using this System, I'm planning my next game. Hopefully I'll have an update on that soon. Please add any comments or questions you might have.

For anyone checking, my attention is being held by Star Wars: the Old Republic right now. I find I don't have time to play games and write games. For me, it's one or the other. I will get back to it as I have some cool ideas, and I want to experiment more with the Component Based Entity System.

As the last part of describing my Component Based Entity System (CBES), I'll show how we tie all the components to entities, and the Entities into a game.

Again, you can get the code here: SmashPCComp-12-23-11 and the Component System library: ComponentSystem-12-23-11

I won't go over the specifics (you can find them at my old blog), but I have some xml files that I define the different bullets, items, levels, etc. I use these as my basis for defining the entities. In reality, I should use xml that are tied very closely to the components, and how they are defined, but, being lazy, I'm using my old defines, and just shaping the components from that.

Basically, just setting up my SFML window, and when I instantiate the SmashPCData variable GameData, it loads all the xml files and holds the properties. We load the 1st level, then pass that GameData variable (as well as the SFML RenderWindow and the chipmunk physics 2d space) to the SmashPcEntitySystem (which I'l get to later).

We then get a spawn location from the GameData, and call AddPlayer from the EntitySystem.

The main functions are the Event callbacks: These are notified from the different entities. The main events the EntitySystem is interested in is DEATH_EVENT's, so we know when a player or an enemy dies, EVENT_DATA_EVENT's, so we can give components the SFMl RenderWindow (for drawing), and ADD_ENTITY_EVENT's, so we can add an Enemy to the system when an EnemySpawn item generates one.

The Constructor does some initial setup. 1st we want to make sure we're registered for the events we want, which happens in the Reset() function:

// We want to get the message for dead events mpEntMgr->RegisterForEvent(SmashPcEntitySystem::OnDeadEvent, (void *)this, DEATH_EVENT);

// We want to get the message for our location from entity manager mpEntMgr->RegisterForEvent(SmashPcEntitySystem::OnEventData, (void *)this, EVENT_DATA_EVENT);

// We want to know when we shold add an entity mpEntMgr->RegisterForEvent(SmashPcEntitySystem::OnAddEvent, (void *)this, ADD_ENTITY_EVENT);

LoadLevelData();

}

You can see we 1st check if we need to save the player specific into; this is the current health, armor, and weapons. This is used for changing levels, which we basically wipe clean all Entities, and start over.

We then register for the events we want to be notified (as mentioned earlier).

The 2nd thing we want to do is load the level data; this is mainly the walls, but there are also items in the level, specifically, EnemySpawn items (but others could be there too):

We begin by looping through the list of walls, and for each wall, we create an entity. The wall entity only has a PhysicalObject and a GraphicsShape component. We generate those 2 components, add them to the entity, and then add the Entity to the EntityManager.

Finally, we tell the Wall's PhysicalObject component it wants to get notified when an Entity of type "Bullet" collides with it, and to remove the other entity upon collision (in this case, the Bullet). No component in the Wall's Entity wants to know about the collision, so it will basically just delete the bullet entity.

We then loop through all the items in the level, and add them to the System.

After loading the level data, we'll get notified to Add a Player to the system:

A Player Entity is made up of these Components (information about them listed in Part 3): Health, Armor, Timer, Player Logic, Camera, Input, Sound, Physical Object, Graphics Object, and Weaponry Component.

First, we check if we're adding a player after he's died, and if so, we store off his old Weaponry Component (which stores what weapons he has), and delete the old dead player entity.

Then, we check if we have a saved Health Component; if so, that means we've changed levels, and we want to load the player with his old Health and Armor; otherwise, we gets default 100 Health, 0 armor.

Next we add all the simple components that don't need much external data.

When we load the Physical Object component, we have to tell it what general shape it is (rectangle, line, or circle) the dimensions of the object, location, angle, maximum speed, and the collision information. There are other optional attributes you can load into a PhysicalObject, but we don't need them for a player.

We tell the Player's Physical Object component that he needs to be notified of colliding with Bullets, Armor, and Weapons. This will generate collision events when the physical object his entities of those types, and different component will be register for those collisions (Armor component wants to know when it's entity acquires armor, Health wants to know when it's entity hits a bullet, and Weaponry wants to know when he hits a weapon).

Finally, we check if we have a weaponry component saved; if so we use it, otherwise we load the default weaponry component, with all the weapons in the game, but only make the 1st one available (the PeaShooter).

All we do is tell the EntityManager that a frame tick occurred. The Entity Manager will tell all the Entities of the Frame Tick, and the Components who are registered for the FRAME_UPDATE_EVENT will get notified.

So, when the user pressed a movement direction, the Input Component, when it gets a FRAME_UPDATE_EVENT, will see a movement key is pressed, and will SetEVent() with INPUT_EVENT. The Player Component gets the INPUT_EVENT, see the user presses left, and sets it's entity's Physical Object's Force, so it will start moving. The Graphics Object will draw where the entity is, based on the Physical Object's world location, and the location of the Camera in the world.

What happens now is the EnemySpawn items (loaded from the level data) timer will expire, notifying them to release an enemy. That will generate an ADD_ENTITY_EVENT with the filter "Enemy" (see function TEnemySpawn::Timer(TEvent &Event)). The EntitySystem will get a callback (since it registered for the ADD_ENTITY_EVENT) to add an Enemy. So, it will call AddEnemy(), which basically does the same thing AddPlayer did, except the Enemy uses these components: Health, Timer, Sound, Enemy Logic, Graphics Object, Physical Object, and Weaponry Enemy differs from Player by swapping Enemy Logic for Player Logic, and it doesn't use Input, nor Camera components.

An Enemy will set a timer to move towards the player. When it expires, the Enemy Component will ask where the Player's Location is. It will then tell it's Physical Object component to change it's angle to be towards the player, and give it a force towards the player. Also, the Enemy has a separate timer for firing bullets, and, when it expires, the enemy will ask where the player is and fire a bullet in that direction (via the Weaponry component).

When a Bullet hits an Enemy, the Enemy's Health Component will get notified of a COLLISION_EVENT (because the Enemy's Physical Object component was told it needs to generate a collision event when it hits a bullet). The Enemy's Health Component will subtract the damage of the bullet (retrieved by getting the Value from the Bullet Entity's Value Component) from it's health. If it's 0 or less, it generates a DEATH_EVENT. The SmashPC Entity System will get a callback telling it the enemy has died, and it will remove the entity form the EntityManager.

And, that's, basically, how it all works. You can look over the code for more detailed information, but that's the basis for my CBES. I'll try and use it for my next project and see how much it helps (or hinders). I'm fairly happy with it, but, I know there are some efficiency issues I could improve. I won't truly know how much it helps until I try and make a different game.

I also realize I'm missing many details. For example, I can't have a glowing image around bullets, I don't have the smoke trails, nor does my flame thrower fade out before the fire expires. I'll explore those aspects for the next game.

You probably notice I'm flying through these articles. Mainly, it's because I want to get these Component articles out of the way and get to writing a new game.

So, this time I'm going to go over some of the SmashPC specific Components. You can get the full Source code here: SmashPcComp-12-23-11

So, here's a list of the components I have for the game, and what they do: Camera - This component signifies where the center of the camera should be drawn within the game world. CUrrently, it's always on the Player, but, you could do cool things with it, like moving it to a remote-controlled entity for a short time. Enemy - This component handles the logic for the enemy. It has 2 timers, one to control how often he turns towards the player, and one to control how often he fires his weapon. EnemySpawn - This handles the releasing of the enemies into the world. When it's timer expires, it creates an ADD_ENTITY_EVENT for the Enemy. GraphicsObject - Handles drawing it's entity if it's a sprite. It gets it's entity's physical component and finds the current camera location so it knows where to draw itself. GraphicsShape - Same as GraphicsObject, except it deal with entities that are shapes, not sprites. Input - Handles sending Input event to it's owner entity. Currently, only player is controlled, but, as with camera, could be moved around to other entities to do fun stuff. PhysicalObject - Handles representing an entity in the physical world. It contains the location and the shape of the object. This object is given force, angle, and location. It is this object that all collisions originate via a callback from the physics library. The SetCollision() is used to detail what other type of entities it should get notified of collisions. Player - Handles all the logic for controlling the player. It get input events and tells others where the player is (like the enemy). Sound - Handles playing sounds on certain events. This component is controversial. I'm really not sure what it adds, since I typically can just play a sound whenever the event happens. But, I added it, and I'm using it, via the SetSound(), which plays a sound on a specific event. Weaponry - Handles firing bullets, and, for a player, handles acquiring new weapons. Has a refire timer that, when expires, allows a new bullet to be fired.

Well take a look at the Input and Player Components here to get a better understanding of how it would work.

Starting at the bottom again, Initialize(), we set the event to get the main SFML RenderWindow, which generates the input. We also register to get notified of every tick.

The rest of the work is done in FrameTick(), where we check if any key is down, and check if the mouse moved. If so, we generate events saying so. If a button was down last time, but not now, we send an empty KeyMask Event.

The constructor takes the speed the player moves. The 2 main things the Player component does is gets input events, and, if it's a direction event, it gives a force to the entity's PhysicalObject. If there's a mouse movement, it gives an angle to the PhysicalObject. (Notice, it doesn't handle firing bullet, that's all done by Weaponry). It also handles events from other people wanting to know where the player is.

Finally, it tells the Sound component to play certain sounds on certain Events.

Next time we'll finish off the Component System talk when I detail how we put it all together to make the SmashPC game.

My last post was a pretty good bit to swallow. And, I realize I'm kind of getting away from the main purpose of this journal, which is supposed to show how to easily develop 2D games, but I wanted to show what I've been doing lately.

In this post, I'll show you some of the simple Components, and how they work. My next 2 posts will detail the more complicated Components, and putting it all together to make a game.

Again, using the same source code: ComponentSystem-12-23-11

All component's have an Initialize() and a Cleanup(). Initialize is called when an entity is added to an Entity Manager's system, and Cleanup when an entity is deleted.

Notice we inherit from TComponent. So, we will have access to mpOwnerEntity, which is the Entity that holds this component. The mpOwnerEntity is set when a Component is added to an entity.

The Value component simply holds a value. This could be for a Bullet's Damage, an Armor's protection rating, a Health Box's value, etc. And, actually, I don't need the GetValue (nor GetStrValue(), since we retrieve the value using an Event. Those are left over.

You see the OnGetData() function is static; that's because it's a callback from the Event system. We;ll see how that works in a second.

The constructor simply assigns the initial value, either a String or an integer.

Next, let's move to the bottom, Initialize(). Here we register for the Component to get notified of DATA_EVENT's. So, any EVENT_DATA_EVENT sent to the component's owner Entity will call TValue::OnGetData(), and it passes in the class as the pThis variable.

In the middle, OnGetData() check's it's an event we're interested in, then cast the pThis void* to the TValue class type (since that's what we register with), and then calls the class's GetData() function, which simply fills in the Event's Data pointer with the value.

I realize it's not the slickest piece of code, I hope it makes sense.

OK, let's take a look at the Armor Component. Armor is owned by any entity that can pick up Armor, and provides protection above the Health. Currently, only the player can wear it. So, the Player entity is given the Armor Component, which starts at 0 value. When the player's entity collides with an Armor item in game, the Armor Component gets notified, and it increases it's value to the value of the armor it collided with. The Health Component, when it collides with a bullet, will check if it's entity has Armor, and, if so, will call Armor's CalculateDamage function.

You can hopefully follow how we register for a Collision event, and filter only for colliding with an Armor item.

Health Component works by registering for Collision Events, and filters for Bullets or HealthBox. If it's a Bullet that hits him, then, he calls OnBulletHit(), which figures out how much damage thebullet will do, and subtracts health from the damage (if wearing armor, it will check with that component 1st). If Health goes to 0 or less, then it creates a Death Event, and broadcasts it to the System. If it hits a HealthBox, then it will increase the Health by the Health box's value.

And, finally, possibly the most useful of the generic Components, TTimer. The Timer Component allows other components to be notified of certain timers. We use it for when the Enemy should fire a bullet and when it should turn, when an Enemy Spawn should spawn the next enemy, when a weapon can fire again, and how long a bullet should live.

It works by calling SetTimer(), giving it a timeout value and an Event to send when the timer expires. Most often, the event is TIMER_EXPIRED_EVENT, but you can pass other events (like REMOVE_ENTITY_EVENT for when an item or bullet expires).

The Timer Component registers for FRAME_UPDATE_EVENT, which is every game tick. This allows it to accurately send it's timers out at the right time. Below is the header and source code.

As I mentioned in my last post, I become interested in Component Base Entity systems, and I decided to port my SmashPC game over to a component-based system.

Well, the results are mixed. I love the idea, and, I think, for certain game types, it's essential; however, I'm not sure it's totally worth it for a simple game like SmashPC. I'll experiment some more as I move onto my next game, and see if I can re-use much of what I've done for other games.

And, I'll also add, being my 1st ever System of this type, I realize it is lacking in many ways, but, I hope the thoughts here can help others build a better system.

Anyway, onto the interesting stuff. Let me start by saying I have some obvious efficiency issues with how I'm approaching entities, components, and the events that communicate between them. Using strings is a BAD way of filtering some events, but, I'm going to use them until I see an obvious performance hit as it's so much easier for my simple games. So, beware if you use this system in a large project.

Here's a link to my component system library I use as the basis for the work: ComponentSystem-12-23-11

This Component class is just a base class for all the specific components. No-one should invoke the TComponent class directly. The idea is a Component knows it's Entity Owner, it's Compnent Type, and it has a generic Initialize and Cleanup. Notice there aren't any template references here; Your implementation could (and, possibly, should) have them.

Before we get to the Entity, I should introduce Events. In my system, Events are what is used to communicate between Components and Entities. Two examples would be #1, the Player Logic Component needs to know when the user presses the "move left" key, so it registers for an "INPUT_EVENT" and it will give the player a velocity when it gets a left (or, more specifically, it will give the Player's Physical Object Component a Velocity). #2, the Enemy Logic component needs to know where the Player is, so it know where to aim it's bullets. So, when it's refire timer expires (notifying it can shoot a bullet), it will ask the Entity Manager to send an event to the Player Entity and get it's Physical Location.

An Event can be tied to a Component or an Entity, depending on where it is created.

The Filter is used to filter out different types of events.

SetData() is used to store the data that will be written to for certain events (like the before mentioned Player Location) and GetData() is used to get the location for where to store that data. Now, I'm using void * for this, and I'm not real happy about it. I probably should have used templates in this case, but, my familiarity with void *'s make it easier for me to do. I do come from a strictly-C background.

TEven.cpp is exclusively setting and returning values, so I won't list it here. It probably could have all been done in the header file.

Next, we'll look at our Entity class. An Entity is comprised of Components, and it also keeps track of many of the events certain components want to be notified of. More on that soon. First, the header file:

// a map using the type of event as the key, and the value // is a list of pairs which could have a sub-type it is filtering on // and a event handler struct TEventCbInfo { TEntity *pEntity; TEventCB EventCB; void *pThis; };

First, you'll notice we define TEventCbInfo outside the class; this is because the EntityManager will also use this structure (since things can register for event callbacks with the whole system, and not just a single enity).

The enum TUpdateOrder, mainly helps detail when entities should be updated. For example, you typically want your player to be drawn last, so he doesn't run "under" a health box, (if he's at 100% health), and you probably don't want any "decoration" items to be drawn over enemies, etc.

Add and Remove Components is useful if you want to move some components out of one entity to another. I use it when a player dies. I remove the Weaponry Component (which knows which weapons the player has), delete the dead player entity, and create a new entity with the previous Weaponry Component (so he keeps his weapons). Another example could be to move the Camera Component from the player to a bullet, if the bullet could be controllable by the player, kind of like how the unreal controllable rocket is. That way, the camera follows the bullet, not the player, for a length of time.

The big piece here is the Event system. SetEvent() basically sets an event for that entity, and any components who's registered for that event will get notified. RegisterForEvent() tells the entity that a component wants to be notified of certain events, and UnRegisterForEvent() removes previously registered event.

The idea here is Entity Manager holds all the entities in the system, and allows entities and components to set and register for system-wide events. It's the interface for adding and removing entities to the system as well. It is a singleton, and can be accessed via the TEntityManager::GetInstance() call.

In the AddEntity() and DeleteEntity() calls, we have a bImmediate parameter. This basically allows the EntityManager to Queue up Entities to add or remove until the next system tick; otherwise, an entity might get removed while the EntityManager is looping through all the entities, and it could corrupt the list.

So, that's the basis for my system. There are some obvious faults with it, not least of which being my games probably don't need this, and could be over-kill. But, it's been a really good experience so far, and I'm going to be curious how it will help me in future games.

Next time I'll get into specific Components I use for SmashPC, and their interactions.

Remeber, you can see my old blog here: 2dGameMaking It has the details about the SmashPC game.

Since my blog is specifically a game making blog, I decided it should be here, at GameDev.

For those that don't know, my previous blog was the 2D Game Making Blog. I created a simple game on that blog, but I didn't really like the blogspot interface, especially for code. So, I'm moving it here.

What to expect form this journal in the future? Well, I've re-written my SmashPC game to use a Component-Based Entity System. I'll be posting much of that code here. I did it just to experience it; the game is really too simple to require it. But, I may look at continuing to use it in the future.

I'm thinking of making trying a multi-player racing game. I really like writing multi-player games because you can just make a few levels, no AI to worry about, and, in general, it's more fun to play against other people.

I've also thought about a Bionic Commadno-type game as I loved that game as a kid, but, again, it will take developing levels, enemies, etc. which can kind of be a drain. maybe a Multi-player Bionic Commando game? Hmmm.

Anyway, I hope you follow along. I'm sure I'll be linking updates on the forums here.