XianForce's Blog

I think it's important though to use something such as Unity. Although the thing I love most about game development is getting down and dirty with the technical aspects, I think Unity still deserves a bit of my time.

Since I began programming, I have not gone back and used anything that'd pre-built. In fact, the only portions of code that weren't my own were the code of the APIs I used (mostly just SDL). The problem with this, is that I've been coding tons of low level stuff. The problem with low level stuff, is you don't often 'see' the fruits of your labor. I can spend hours refactoring code, or adding in a new manager, but as far as the gamer is concerned, none of that exists. In this way, I have become burnt out, which is why I take frequent and long breaks. I think using something such as Unity will allow me to quickly piece things together, so that I can get a lot of fruit for a small amount of labor, which will balance out the technical aspect of lower level programming.

I showed Unity to my younger brother today, and he's learning to use it too. I think this can also be something my brother and I can use together to make simple prototypes to play together. So my hope is that my use of Unity will give me inspiration in my technical programming endeavors.

So, just a few things I want to point out in the screenshot of my Unity Scene. Firstly, I made a 'car'. I only used the textures that were in the assets provided by Unity. I am just slowly learning how things work in Unity. The car is composed of 5 objects: a cube, 3 cylinders, and a particle emitter. The cube is the body, 2 cylinders are used for wheels, another cylinder is used as the exhaust pipe, and the partile emitter emits steam from the exhaust pipe. I packaged all this up into a prefab and put 2 of them in the scene.

Next, you see all those blocks on the ground? Those are 'bullets' I made a small script and attached it to the main camera (which is part of the First Person Controller prefab), and it creates a bullet and adds a force to it when you click.

The random staircase thing in the background is just something I used for testing platforming...

Besides those, the only other thing in my scene is a textured plane (as the ground), and a spot light source.

So I learned quite a bit about Unity today :D. I'll be gone for the rest of the weekend, and school resumes Monday, so I don't know how well I'll be able to keep up with programming. This year I toned down my schedule a lot, so I should have a lot more free time.

With that, I bid you ado :p

So I've been looking at the structure of my Entity System, and it is horribly ugly. I'm like halfway between a Hierarchal and Component Entity System. So I'm going to revise the Entity System into a Component Entity System. One huge thing that I've found to be a problem, and what I've been working on the most, is making sure projectiles don't disappear when the entity that fired them is destroyed. When that entity is destroyed, it's weapon system is destroyed, along with any bullets it fired. I'd have to set up a system to handle the destruction and creation of the bullets, and have the weapon system have a dependency on it.

Well my new Entity System will solve these issues and others :D. My abstract Component class will look like this:

class IComponent

{

private:

std::string mComponentType;

Entity* m_pOwner;

public:

IComponent();

virtual ~IComponent();

virtual void OnUpdate() = 0;

virtual void OnSerialize() = 0;

virtual void OnDeserialize() = 0;

virtual void OnDebug() = 0;

std::string GetComponentType() const { return mComponentType; }

void SetComponentType(std::string compType) { mComponentType = compType; }

Entity* GetOwner() const { return m_pOwner; }

void SetOwner(Entity* owner) { m_pOwner = owner; }

};

I may add Init and Quit functions depending on the components I'll need, but that will be later.

So each component will derive from this interface and implement all these functions. Each frame when an Entity is updated, it will iterate through all it's components and update them. If I want to access debug information, that's what OnDebug will handle. Serialization of a component will basically 'save the settings' of that component'. With it, I can Serialize all of an entities components, so that I essentially have that entity saved, and can recreate it. Deserialization reads this information. So it can be thought of as a 'Save' and 'Load'.

This all sounds fine and dandy, but how exactly does this help solve my dependency issues? Well I'm going to create a few 'Factories'. Factories are basically objects that help construct complex objects. With this Component Entity System, I'll have a Component Factory and an Entity Factory.

These Factories will have dependencies on every major system (and perhaps subsystems) of the game. So construction will be something like:

EntityFactory->ConstructEntity("ThisEntity");

//In the definition of that function...

Component* transformComponent = new TransformComponent();

Entity* pEntity = new Entity();

transformComponent->SetDependency(Camera);

pEntity->AttachComponent(transformComponent);

EntityManager->AttachEntity(pEntity);

The actual code will be slightly different, but the idea is still there. In this example, the Transform Component has a dependency on the Camera. Which will actually be a dependency in game. The Transform will be a 4x4 matrix which represents an Entity's position, orientation, and scaling on the screen. It is in Screen Coordinates. The Entity's world position will be handled by another component, the LocationComponent. This means that the TransformComponent also has a dependency on the LocationComponent. So how do we solve this? Well thanks to a few posts from GyroVorbis, I've thought of a system that is likely similar to their's (probably less intense though...).

So basically, Entities will be a container of Components, and will have all the virtual functions that Components have (which will just iterate through and make the call to each Component). It will contain a map of Components with Strings as the key. Since each component holds a pointer to it's owner, it can do something like: m_pOwner->GetComponent(). The GetComponent function will take in a string that represents the type of component. Then a handy dandy find algorithm (courtesy of STL) I can see if that type exists in that map. If it's there, return it, and it's now a happy day :D.

So I think this will definitely be an improvement in code structure, which will help development along once I'm finished :D.

Just so you have an idea, these are the components I plan to have in Charge so far:

-WeaponComponent

-AnimationComponent

-MovementComponent

-LocationComponent

-CollisionComponent

-RenderComponent

-HealthComponent

-InputComponent

-AIComponent (This will very likely be broken down into multiple components...)

Well that's it for now, back to refactoring :/

So just a little update on what I've been working on...

So, I haven't really started DS Development... But I plan to in the near future, just not specifically on the DS. The Super Card team has released an SDK, which I applied to receive... It seems it's quite easy to get, so I'm sure I'll receive one. With this, I'll be helping a friend of mine develop a small library to make things a bit easier to develop with. I hope to make small games and applications with this.

My portable framework has finally had a bit of lift off. For the most part it's finished. The planned networking core hasn't been discussed yet, so we're going to keep it on the back burner, and there's a few optimizations I can make.

But I really have to discuss something with my partner... I'm proposing that we entirely remove the abstract base classes. As of now, they create a lot of overhead with the v-tables, and in the end, it's not really necessary. We plan to compile this framework into a library, and still be able to use:

"namespace Platform = iPhone;"

So a quick swap of search directories to the iPhone library files + header files will allow us to recompile what we create on the PC, for the iPhone. And with this, we avoid the nasty overhead of v-tables, which is surely going to slow things down on an embedded system...

So once we get that out of the way, I'll be spending my time starting to actually develop a game with it, and when I get bored, I may pull some optimizations to the library.

Lastly, I suppose I'll talk about Charge. To be entirely honest, Charge has REALLY been put on the back burner. I had not even thought about it for the longest time.

But, last night I grabbed a piece of paper, and sorted out what I needed to do... So here's my current to do list for Charge:

*Create Process and Process Manager classes

*Sync the Process Manager with the Enemy System

*Create a Weapon Class to replace the redundant 'fire' function calls

*Sync the Weapon System to the Weapon Class

*Use the Process Manager to create AI process including allowing a lone enemy to join a group

So that's just in short... But that all gives me a lot of different things to work on, which I think is healthy in a project. Because if I get stuck in one place, I can work on a different area.

So soon I'll have about 4 active projects:

-Charge (Last game using just SDL!)

-Portable Framework (Won't be as active, just optimizations mostly... And network core!)

-First Game using Framework (Perhaps I've revealed the game already, but I won't repeat it)

-Development on the Super Card DSTWO

So I think with all these, I'll be able to keep coding without getting bored with one thing. And I definitely plan to start gaming more and more :D.

So now moving out of just my programming projects, I guess I'll talk about the SDL Video Tutorials. I apologize for slacking on those lately. I let a friend borrow my mic, and I just got it back today. 'epicasian' messaged me on the Elysian Shadows forum asking about them, and just somebody asking about when the next one will be released was so much encouragement to me, so the next two should be coming soon. But as for now, it's been a while since I've made one, so I got to take a look at the previous ones to see where I am...

Well, it has been a long time, but I think this long post makes up for it :D. School's starting in a week, so let's see what I can accomplish before then!