XianForce's Blog

Another Long, Unannounced Hiatus?

Monday, July 18, 2011 11:29 AM XianForce
, 0 comments

Yeah, I seem to do this a lot. I get really excited and dive into programming something. Then I start hitting a few road blocks, then life picks up and I get busy, and soon programming gets quite left in the dust. It's Summer now for me, and while my schedule is still a bit hectic, I have actually been getting work done. Nothing visible, yet, but I'll talk about what I've gotten done so far, and what my plans are next.

I've been working on a component entity system. With some help from GyroVorbis, I've actually laid out quite a flexible system. Considering that I used many of the ideas from Component Entity System discussions on the Elysian Shadows forum, I imagine mine may resemble the ES team's system, except much less elegant.

So basically, every Entity is simple a collection of Components and Behaviors. A Component is more or less a package of data, which have functions that a corresponding system calls in order to update it.

So as of right now, I have an EventSystem, which handles passing corresponding SFML events to EventComponents (Will be used for GUIs for the most part).

I have a PhysicsSystem, which manages RigidBodyComponents and CollisionComponents.

I have a RenderSystem which manages RenderComponents.

As for RenderComponents, there are 3 different types: Sprite, Shape, and Text. Since each of those respective SFML objects is based off of the SFML Drawable class, it's quite simple :).

RigidBodyComponents are responsible for managing movement. As for now, the motion is as complete as I want it: acceleration, velocity, and a damper used as friction.

CollisionComponents just hold the bounding box for the entity, and are used in collision checks.

Lastly, I have a BehaviorSystem which manages Behaviors. Behaviors have an update function, and as such can do certain tasks every loop, although they can also respond to triggers. I currently have 4 triggers programmed in: OnCreate, OnDestroy, OnMove, and OnCollide. When any of these events occurs, the TriggerSystem is called which in turn calls any system that needs to know about the event. This is NOT a dynamic trigger system. The events are hard-coded. The events are going to depend on the TYPE of game I make, not necessarily the game itself, so a full fledged dynamic trigger system isn't required.

I'm moving toward making a simple game with this structure. Once I finish making a simple game, I'm going back to the drawing board to find the things I do and don't like about the component entity system, and make changes. Then go back and fix it, and prepare it to make another game. This way I'll get it to go through a few iterations before I use it to make an RPG in the future :).

So the next task on my list is to code in a system for creating entities. I'm going to make entity templates (not as in C++ templates), so that I can store the information for a certain type of entity in code. Later, I'll add dynamic entity creation from file, so that data will be read from a file, then stored in a template.

Well, that's all for now. Once I have this next item on my to do list done, I'll actually begin programming the game. It's going to be a simple game, just to test the system and see what works and doesn't work.

Hopefully I can have a video up soon :)

Unity

Well, today, I finally got around to trying out Unity... and to be blatantly honest, I love it! This doesn't mean I'm going to go and do only high level development now; my heart lies within the lower levels of C and C++.

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

Tuesday, August 17, 2010 9:05 AM XianForce
Labels: Charge , Code Refactoring , Component Entity System , 0 comments

Well, I figured the more I post, the more I'll inspire myself to get some work done :D. I haven't really finished anything that I can show off yet. I've been digging through and refactoring code. With all the work I'm putting in, it would seem Charge is going to be practically rewritten by the time I'm done with it.

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 :/

Long time, No Post?

Sunday, August 15, 2010 12:54 PM XianForce
Labels: Charge , Daily Update , Portable Framework , Super Card , 0 comments

Well, I apologize for my lack of posts in the last month or so. I've been quite busy rambling about. But now I have tons of inspiration built up inside. I'm finding I have a big issue balancing game programming with gaming. I love programming, but I don't play games often. I believe as I program games, it's equally as important to play them. Playing games is what sparks the desire, and inspires, so without it, I burn out quite fast.

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!

New Great Book =D

Wednesday, July 21, 2010 9:19 AM XianForce
, 1 comments

Well I'm now reading a book called Game Coding Complete. It's about 900 pages or so, and I love it. Lately I haven't really gotten anything tangible done, so I haven't been posting =/. I have been writing down a lot of different ideas to implement AI in Charge, but theres a few kinks I can't seem to get around. There's a chapter on AI on Game Coding Complete, and I still have about half of Programming Game AI By Example to read, so I'm hoping between those, I'll find some intelligent solutions.

I've also been talking with my partner about our framework, and once we finish all the cores, we're going to extend it to make it more of an engine to power the games we create. We're going to follow the engine structure set forth in Game Coding Complete. I must say it seems to be a very flexible way to set up an engine.

Well that's it for now, I'm out.

Forgot to Post About Some Stuff!

Wednesday, July 14, 2010 1:48 PM XianForce
Labels: Charge , 0 comments

Well I'm pretty sure there's some stuff I forgot to mention in my last post!

So I made two new videos, but here's the problem: They are too long! Your probably thinking, "Well trim them?" but I can't find any (free) software to edit a video that doesn't ruin the quality when it's rendered. One of them is the next SDL Video Tutorial, so I just need to get a chance to trim it, and it will be up (I've had this done for quite some time now!). The other video shows off the new stuff in Charge.

So I've implemented a skeleton of each enemy, so now I just need to program some specific AI. Right now, I'm still planning groups out. I started implementing them, but the implementation was getting real ugly, so I wiped it out.

So onto what I HAVE done. I made a Health System, so now the player has a health box, and lives system is in place (but has no effect for testing purposes). Also, I have a power up system. Currently there is only health and weapon powerups, but the system actually works well.

So now I need to put a lot of work into this AI. Really this is going to be the hardest part of the programming.

Honestly though, I can't wait to finish it. I'm excited to get some experience with AI =D.

Well that's it for now =D.

AI Design

Wednesday, July 7, 2010 9:49 AM XianForce
Labels: Charge , NDS Development , Portable Framework , 0 comments

Well I've been thinking a lot about Charge, and I think I'm finally starting to get to a good point with the AI.

So my StateMachine holds 3 states: Current, Previous, and Global. The global state is going to handle shooting and a few state changes. The global state is where the shared memory will be mostly utilized, but shared memory will definitely be utilized in some current states as well.

Another thing I've been planning out is Enemy Groups. So an Enemy Group will hold a few Enemies (let's say 5 for example), and will control the behavior of the Enemies within the group. In this way, the Group can examine the shared memory, and act upon it.

I also plan to have a SetFormation function. This function will most likely take an enum as it's parameter that describes the type of formation. As of now, I'm thinking horizontal, vertical, V, forward slash, and back slash. I may create more as I go along, but I think this is a good starting point.

I've added a 'destination' for each enemy, and this will make it super easy to set formations. So when the formation is set, it will use the first enemy as a reference point. Then it will make a few calculations to find what the destination of all the other enemies should be. If any points are offscreen, each destination point will be offset to make sure they stay on screen. After the destination point is set, the state will be changed to a "MoveToDestination" State, which will handle moving to the destination.

At the moment, I'm unsure of whether I should then go to an Idle state, or Revert to the previous State. I'm leaning towards the former, because the previous state may be a state that was only meant to be temporary, and shouldn't be reverted back to. It's an easy change between them (only a single line of code), so if I decide to switch, there won't be any problem =D.

The only thing I really need to work into my systems, is the Groups. When planning for AI, I never really thought about groups. It will be easy to insert, I'm just unsure as to whether I should make a separate system/handler for the groups, or just make it a part of the EnemySystem. I'm leaning towards the former on that as well, because, I think it will provide more flexibility.

So now that my AI stuff is out in the open, I guess I should talk about my other project(s).

So I'm like 99% sure I've mentioned the cross platform framework a friend and I are working on. We've just come out of the design phase, and I'm just basically making the virtual classes. Since there are no implementations with this, and all functions are pure virtual, it's really pointless to make any actual code files (.cpp extension). After I finish all these headers, I'll review them with my partner, and then he'll start fleshing out the iPhone implementation, while I work on the Windows/Mac/Linux implementation.

Right now, I want to propose a new 'core' to be added to the framework. I haven't talked to him about it yet, because I just thought of it last night (which is going to lead me into my next 'project'). I want to make a sort of Resource Core... I hesitate to call it a Core... In fact, I'm just going to refer to it as Resource Management System (RMS for short). The reason I think this is a very important addition to the framework itself, rather than just something that is separated from the framework, is because we're geared towards embedded systems. Just last night, I purchased a new DS Flash Card (the Super Card DS Two). For systems such as the DS, I'm not too certain if it's plausible to add them to the framework. One way to help this along though is an RMS. Many embedded systems such as this have much less RAM and VRAM, so it becomes very important to manage resources differently. For example: On a PC, you can probably load hundreds, perhaps even thousands, of different images. The DS, works very differently though. It supports up to 128 sprites, not including backgrounds. For backgrounds you can have 4 (one to be used for text). So it would be beneficial, and probably necessary, to free resources at different times on different embedded systems.

So for those of you who don't know, my coding started with PAlib and NDS development. I never really got far in it, and before long, I lost my flash card. A relative gave me a 50$ card, that can't be combined with any other source of money, nor reloaded. I was going to buy 2 programming books, but the total came to like $51, and I wasn't just going to buy one, so a friend told me to buy a flash card, so I did, and was also able to get a 4GB micro SD... now I have exactly $2.22 left on the card. But I figure I should use it, so I'll probably pick up NDS coding on the side.

Well that's it for now, ciao!

More Charge Development

Thursday, July 1, 2010 10:35 PM XianForce
Labels: Charge , 0 comments

So I worked again on Charge today, and I finished something =D.

Looking back at a few previous posts, I noticed I wanted to make a Level System, I had already made a level class, but no load function. So I shaped out a Load function, and then made a Level System.

I had to tweak my Enemy System to keep count of how many Enemies it had. I couldn't just get the size of the list, because some of the enemies were likely to be NULL. The reason some could be NULL is for two reasons:

1) If I remove an element while iterating, there's a high chance that I will have some access violations.

2) In terms of efficiency, it's better.

So I now have a variable to keep track of how many enemies exist. Each frame, after updating everything, I check to see how many enemies exist. If it's 0, then I load the next level.

Levels will go in an order like:

Level1.map

Level2.map

Level3.map

...

So I don't even have to specify each map, it will just continue to load them. I also have a max levels number hard coded in.

The level files are simple, a format like this:

Background: space

ECount: 2

Enemy 1 30 30 End

Enemy 1 50 70 End

The only thing I really need to do is switch to a 'transition' state, then revert. This way, it won't seem choppy.

But that's what I accomplished for today. Not too sure of what I have planned for tomorrow, but hopefully I'll get something done =D

Back from Vacation!

Wednesday, June 30, 2010 10:20 PM XianForce
Labels: More Development , 0 comments

Sorry for the delay! I was on vacation for practically two weeks. But now I'm back and refreshed; ready to code!

So I have two projects I'm working on right now:

Charge

a New Framework...

Now you might be wondering why I'm making yet ANOTHER framework.

Well this framework is different! A friend and I will both be working on it, and we intend it to be a high level library. So basically it will consist of 5 basic 'cores':

System Core

Input Core

Video Core

Audio Core

Network Core

And these cores will be virtual, so that different implementations can exist. All the base cores will be stored in a Platform namespace, and then any implementation would be stored in another namespace; Then there'd be lines like this:

Platform::BaseVideoCore = new Platform::VideoCore();

And at the top of a certain file, you'd do something such as:

namespace Windows = Platform;

So that your VideoCore class in Windows namespace can now be called through the platform namespace.

This way you can use the same code throughout.

My friend and I want to make some sort of top down game with it, and make PC and iPhone implementations.

I'll be working on the PC implementation using SDL, OpenGL, and perhaps DevIL to load images (but I'm thinking of just sticking with the SDL_image extension).

Well, back to Charge stuff! I fixed up the problems with the framework. There were just a few issues with not asserting pointers to make sure they had a valid value. Now that it's all fixed, Charge development can continue. I remember outlining what I had planned next for Charge, so I'll go back and check that out, and then start working. But for tonight I'm done, so peace =D

New SDL Video Tutorials Up

Wednesday, June 16, 2010 9:19 PM XianForce
Labels: Charge , New Project , SDL Video Tutorials , UPS , Vacation , 0 comments

So hey, go check my youtube channel to watch my new SDL Video Tutorials! I have two up so far, with a third already made. But I'm running into a problem.

I trimmed the video with VirtualDub, and Youtube will not upload it. So I need to find another program to trim it with, but that will probably not be tonight.

Also, UPS is nearly finished, I'm just looking for music now, which I'll find tonight.

I'll be gone for a few days, because I'm going camping, but I'll be sure to get all that wrapped up when I come back.

Also I'll only be back for 2 days, then I'm taking a 1 week vacation. Once I come back from that, Charge Development will start back up, along with a new project that I'm diving into =D.

XianForce's Blog

This blog will detail the highs and lows of my game development adventure.

Welcome!

Pages