Welcome!

Hey, I'm Skylar, a kid aspiring to become a competent programmer. This blog is here to detail my dabbles in development.

My dream is to one day become a professional programmer and do some game development in my spare time.

Thanks for visiting my blog, and I hope you'll come back!

Pages

Unity

Friday, August 20, 2010 10:52 PM XianForce
Labels: , , , , 1 comments





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: , , , 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: , , , , 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: , 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: , , , 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: , 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: , 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: , , , , , 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.

Updates for UPS (and 50th blog post !)

Friday, June 11, 2010 8:24 AM XianForce
Labels: , , 0 comments

Well I got some work done on UPS, so here's what I've done:


-2 Players
-Bouncing Slimes
-Ice tiles


I posted 2 videos, one shows all of them, and it shows a glitch I was having with the ice tiles. Later, after posting the video, I realized the problem, and reposted a video showing what caused the problem, and showing it fixed.

So here's the two videos:



So the next, and final iteration, will be the last =D.

It will have music, sounds, and perhaps slightly improved graphics.

It seems Moosader may be extending the competition, though, so I may continue to add features.

But that's all for now, have a good one =D

OpenGL works 0.o???

Saturday, June 5, 2010 11:34 PM XianForce
Labels: , 0 comments

Well, someone on the Elysian Shadows posted an OpenGL app a little while back, and I tried to run it without even thinking.


So after I amused myself by running it, I realized, "OpenGL has never worked on my computer...". So I started playing around with different things, and apparently, OpenGL code compiled with the MinGW compiler works =D.

So I'll probably have to do some code porting, but I DEFINITELY want to upgrade my framework to use OpenGL for the 2D graphics.

Before I do that though, I want to wipe my computer. I'm going to back up everything soon, and wipe it. I have so much crap cluttering up my computer, and I just need to clean it. This way I can set up SDL for Code::Blocks in a somewhat elegant manner. As of now there are random folders scattered across my computer that all have different SDL and SDL extension(s) files.

So I'll definitely be working on UPS, studying up on OpenGL, extending the framework, and working on Charge!

Note: I won't extend my framework to use OpenGL until AFTER Charge, so it won't affect Charge =D.


Well that's it for now =D, just thought I'd let you in on today's success =p.

Update on UPS

Friday, June 4, 2010 9:13 PM XianForce
Labels: , 0 comments

Well, I got the bouncing working right (or wrong I should say, because it's 'unintuitive'), and I also successfully created two players.


I've decided that for every Slime that's grabbed, EVERY player will have the held effect. So that just gives more room for hectic game play haha.


I would post screen shots, but there isn't really any much to show at the moment. Tomorrow I have to take my SAT test, but afterwards I'll try to work on the slippery tiles. Once I have those done I'll post an update.

Well I gotta go to sleep so I can wake up early enough. Peace out =D

Last Day of School

Thursday, June 3, 2010 6:43 AM XianForce
Labels: , , , 0 comments

Well, today is the last day of my Junior year of Highschool, I have a Spanish 3 final to take, and then my Junior year is officially over.


I had great times this year.

So, over the summer, I'm going to be running, playing tennis, and working out every day, and I'll also be programming a lot.

I hope to finish Charge early on in the Summer, and begin something bigger and better.

This year, a lot of time went into school work to get a 4.5 GPA, but next year, I'm going to tone it down a bit, to give me more time to program.

So this was just a quick update to let you know that I'll have more time soon.

Also I want to remake all my SDL Video tutorials this summer =D!

UPS Iteration 2

Monday, May 31, 2010 10:09 AM XianForce
Labels: , , , 0 comments

Well here's a video of Iteration 2:



Look at the video description for more information!

UPS Iteration 1

Thursday, May 27, 2010 9:18 PM XianForce
Labels: , , , 0 comments

I just posted a new video on youtube showing Iteration 1 of my entry to Moosader's Unintuitive Physics Competition. Hopefully soon, I'll have iteration 2, which should have much more to show off =D!


Anyways, here's the link.

Charge On Hiatus Temporarily...

6:40 AM XianForce
Labels: , , , 0 comments

I'm starting to work on my entry for LusikkaMage's (AKA Moosader, Rachel, etc) Unintuitive Physics competition.


The reason I won't be working on Charge, is because every time I have a project using my framework, I tend to change things with my framework to improve it. If I do that with two separate projects, then there will be problems because I'll have two separate versions, which both have important changes that the other doesn't have.

I really want to avoid this, so I'm just going to try to as quickly as possible get my entry done, then move the changes back.

But rest assured, I doubt this will happen again. As soon as I'm done with my entry, I'll begin working on the MusicBank, and Text System. Once those are done, I'll compile the framework into a lib.

So my entry, for any that don't know, is going to be called Unintuitive Pickin' Slime. It's nothing special. Basically, every 5 seconds a new slime will spawn. For each slime you collect, you get a point, but each slime has an effect. Gravity will change directions, your controls will be swapped, directional speed will change, etc.

The graphics will suck. As of now, the player is only a simple ball. And I probably won't do anything else with it graphics wise. I would love to add animations, and the like, but I'm imagining the problems, and how much time I have to complete the game, and I don't really want to go that in-depth for something such as this.

Once I finish the first iteration (hopefully today), I'll make a video. But that's all for now I suppose, later.

New Video

Sunday, May 23, 2010 6:03 PM XianForce
Labels: , , 0 comments

Just wanted to say that I uploaded a new video =D!


It's a bit long, but here it is:

Configuration File Added to the Framework!

Friday, May 21, 2010 3:08 PM XianForce
Labels: , 0 comments

Well, for the past few days, I've been trying to get my framework to support reading in an ini file for configuration properties such as window width and height.


I used minIni, and compiled it into a static library. When trying to put it into play, I kept getting a strange access violation.

After much code reviewing, I found out that I had used or, instead of and (|| vs &&). So when one thing became true (in which I wanted EVERYTHING to be true), it short circuited and returned a true value, and didn't even run the other functions.

This caused a lot of things to not be initialized when they were used, and that's what caused the access violation.

So to go back and touch up on the ResourceSystem, I'm going to actually flesh out the SoundBank some time in the near future, then add a MusicBank, and a FontBank. The former two will be quite easily implemented, but I need to put some thought into the latter. To make a font bank, I need to make a text system of sorts.

With the text system, I REALLY want to implement a system so that I can confine the text to a box.

Once I'm done with this, I'll clean up the framework, and perhaps release it =D.

But anyways, onto Charge... The next thing for Charge is to finish up the WeaponSystem, so that different leveled weapons work right. I also need to fix the bullet speed and direction, which will allow some more interesting weapons. After that, I want to create power up system, and sync it with the weapon system and EnemySystem.

I'm still unsure of how I should make my LevelSystem, but I definitely need to put some more thought into it before I jump head first into it.

Once I have these 3 things done, I'll begin fleshing out each enemy, then programming their specific AI. That's probably what will take the most time, because I'll have to implement some sort of shared memory probably, but that won't be too hard to do, due to the flexibility of the 'engine'.

Well that's all for now, I have to research a college and work on a Calculus project, so peace out =D

Resource System Mostly Done =D

Sunday, May 16, 2010 1:21 PM XianForce
Labels: , , 0 comments




So really, the Resource System is just a front to access the ImageBank and SoundBank. I've finished the ImageBank, and have it exactly how I want it =D.

So basically, when you want a surface you do this:

FF::Surface* pSurf = FF_ResourceSystem->GetImageBank().GetSurface("Ship");

So then I have it loop through each file extension I support, in a certain order. If the load fails, then it moves on to the next one.

If it happens to get through all the extensions, and doesn't load any of them, then instead of returning you the image you probably expected, it will give you a bitmap that says the word "Error".

So this ImageBank guaruntees that only one of each image is loaded, and that it's all cleaned up =D.

Oh, it also has a cap of 100 images as of now. But that can be easily adjusted =D.


The SoundBank isn't finished yet. Really the code will be the same, I just need to look at the Mixer Documentation and find out what formats I need to support.

The only other thing I really think I may need, is something to manage Music. I'm not sure if it needs it's own bank, because there can only be one piece of music playing at a time. But then again, when music changes, I don't really want lag from loading the new piece.

But that's yet to be decided. At the moment, I'm thinking I'll make a bank for it, but with a much lower cap, like 25 or something.

But all I have to say is, it may have taken a while to get this resource management stuff figured out, but it is WELL worth it =D.

So now to explain the picture really quickly. Well I added another player character, but purposely passed in an image that didn't exist. So it returned the Error surface. It may be hard to see, but the Error is right next to the red star.

Well, I believe I'm going to make a video, hopefully it isn't super laggy like the last one I made =D

Resource Management

Friday, May 14, 2010 6:26 PM XianForce
Labels: , 0 comments

Well, since you couldn't tell from the last screen shot, I'll tell you that it was starting to get laggy. Every new bullet, and every new enemy each had it's own surface, which is quite ridiculous I must say. So right now, I'm adding a resource manager to my framework.


I'm thinking that the resource manager will have a graphics and sound component and will work something like so:

ImageBank->GetSurface("SomeImage");

So what I want it to do from here, is search to see if it has that image, if it does, return it, if not, I have it return NULL at the moment.

Ideally, I'd like to be able to not have to specify the extension, and write some code to search through the directory to find the file with that name, grab it's extension, and then load it in, so I don't have to worry about extensions and such. I'm finding this to be rather hard, as I want to maintain my code's portability, but any method I've find to search through a directory is platform dependent.

So I'm working on that now, if I can't find a good solution, I'll just skip it, and leave it as is, but for now, I'm determined to find a way!

CollisionSystem + EnemySystem Done!

Saturday, May 8, 2010 1:29 PM XianForce
Labels: , 0 comments





Well, I told myself on Thursday, that I would finish programming an enemy, and then make a post. But then I realized, I might as well make the EnemySystem real quick as well. Making the EnemySystem carried on into Friday, and I thought to myself: "I want some collisions before I make a post!"

So I started creating a collision system. I had a few issues with iteration. I was removing elements in a iteration, making the iterator invalid.

So I finally fixed it all up and now it works wonderfully!

To make the enemy, I also made a StateMachine, and base state template.

So as of now, there are two simple states for testing purposes: MoveLeft and MoveRight.

Oh yeah, you can also press 'e' to add new enemies, which helps testing some =D.

So my next task is to make a LevelSystem. The LevelSystem will be able to Load levels from a file. I'm generally thinking the format will be something like:

Background filepath

Count 5

Enemy 4 100 20
Enemy 3 100 40
Enemy 2 200 60
Enemy 5 300 50
Enemy 1 120 50

So I'll be able to retrieve the background, the number of enemies in the level, and each enemy will be created based on the information in this. The different TYPES of enemies will be hard coded in, and so I imagine that there will only be 3 pieces of data needed: AI level (which determines the type), x and y coordinate to determine it's position. The LevelSystem will render levels, and scroll the background image =D

So after the LevelSystem is finished, I'm going to adjust the WeaponSystem to make it easier to create different weapon types. Then I'll create a Powerup System to work with the WeaponSystem to adjust it to different weapons.

I imagine I'll create some sort of life system for playables. I'll also have to sync that with the CollisionSystem to create Life, and Lives. Then I'll probably sync it with the power up system to add health power ups.

The last thing (programming wise) that I want to worry about, is the AI. I just want to get everything framed up, so I can go in, and not focus on so much speculation, and just worry solely about the AI. Because of how I want the game to play, I'm thinking of implementing some type of "Shared Memory".

So for those of you who don't want to go back and find out how I want the game to play, here's a little explanation.

There will be 5 enemy types:
-Grunt
-Drone
-Revenant
-Protector
-Mother Ship

So basically, the Grunt will have incredibly low AI. Most of what it does will be entirely random, but it will be so random that it can actually be slightly dangerous. The Revenant will have the highest overall AI, with bullet dodging, shooting, path execution, etc. The Drones will have AI in-between Grunts and Revenants. Basically some things it will 'intentionally' do and some things will just be random.

The Protectors and Mother Ships will have a sort of 'team playing' together, so I'll have to implement a way for them to work together. But basically, each Mother Ship will hold a timer, and when that timer goes off, it will create an enemy. It will be able to create any enemy type excluding itself. The Mother ship will NOT be able to shoot, but it will be able to dodge bullets like no other.

For the Protectors, my idea is to have them sense a player's bullet through shared memory, and then calculate who's closest, and calculate a velocity that will get the Protector to take a bullet. Aside from taking bullets, I suspect Protectors will be somewhat like Revenants.

So the object of each level will be to get rid of all enemies, so you must take out the Mother Ships. As the levels progress, more Mother Ships will be there, and they will create enemies faster.


So I think with all this, it will provide for some interesting game play... But for now, I've done what I need to for the day... Time to get ready for Prom tonight =D

I haven't forgotten!

Saturday, April 24, 2010 9:38 PM XianForce
, 0 comments

Well, I've been terribly busy this week, and I probably will be all of next week, but even if I don't have time to code, I do still think about how I'm going to implement different things all the time.


So as I think I have said I want to implement the EnemySystem next. But to implement the EnemySystem, I need to implement an Enemy base class. But the Enemy base class needs to have a StateMachine, and the StateMachine needs to have a base state.

So For now, I'm reviewing Programming Game AI by Example to get ideas for a 'universal' base state class and state machine. Once I implement these, I need to think more about how AI will work before I implement the enemy base class. I'm thinking that I'll just have States made specifically for each type of enemy, so that lower leveled enemies can't use them, OR make universal states for each type of enemy, and then have a specified AI level for each enemy.

But that's what's going on now... Life's real hectic with the band, Prom, SATs, standardized tests, and everything else I have going on... But I'll definitely be putting a lot of thought into it, so that when I DO go to program, I get a lot done =D

Coding Has Commenced!

Saturday, April 17, 2010 1:59 PM XianForce
Labels: , 0 comments




So, I've gotten through tons of design and now I'm ready to start coding.

Instead of creating my ApplicationSystem inside my main function, I have now made it global. This way each Entity can easily get the dimensions of the window, so that they can check for themselves, if they are outside or not.

So I have an ActorSystem, which holds the PlayableSystem. The PlayableSystem updates and renders playable characters. The Playable class holds an array of 5 SDLKeys, so it's easy to define another player =D!

As of now, the WeaponSystem allows 10 bullets (I haven't programmed anything besides normal bullets).

My next task that awaits is to create the enemy base class, and create some type of enemy. Then I will code the EnemySystem and make sure everything works with some sync.

After that, I will need to make a CollisionSystem, which will take a reference to the PlayableSystem, and EnemySystem (both contained in the ActorSystem), and check for collisions between them.

I'm thinking I'll check collisions in this order:

-Playables vs. Enemies
-Playable Bullets vs. Enemies
-Playables vs Enemy Bullets
-Playable Bullets vs Enemy Bullets

After that, I'll probably shape the LevelSystem which will be real simple. I plan for it to have a background, and scroll that background, to give a nice little effect. I also want it to load in levels from files, which will contain the background, and information regarding enemies.

I definitely want to start extending the Playable Class after I make the LevelSystem. I'll make health and/or lives, not sure which yet.

Then I'll start creating different types of weapons, and make sure it's all compatible with the WeaponSystem.


So that's the only update I have for now! Until Next Time!



A Post Where I Ramble On About Ideas...

Saturday, April 10, 2010 11:00 PM XianForce
Labels: , , , , , 0 comments

So maybe you noticed, I changed the blog template. I got sick of the dark theme of the last one, so I chose one that was a bit lighter.

Anyways, the current ideas rambling around in my head are regarding Players and Weapons.

First of all, I'm now using a position vector + width/height variables instead of a rect, which makes a few things a bit simpler.

Also, I've removed the IDs from Entities. Seeing as I'm using a list (No random iteration) to hold the entities, the ID would become virtually useless, and would serve no purpose.



Anyways, so onto the rambling thoughts. So I'm at a friend's house right now, and don't have access to any IDE, and I don't feel like downloading one on his computer. He's playing Call of Duty MW2 at the moment, and I'm rambling on =D.

So with players, I definitely want to make it at least two player co-op, but I may add more. To do this, I wanted to make it quite easy to create player control schemes. In my other games, I simply hard coded the different controls in, and it wasn't the slightest bit graceful.

To accomplish this, I'm going to have the player hold 5 SDLKeys, 4 for the standard directions, and the 5th for shooting.

I'll of course have some keys blocked such as ESC and 'p' (which will be used for exiting and pausing). So with that I'll be sitting pretty.

The other thing I've really been thinking about is the WeaponSystem, and how it will work. I've decided that all Entities will be registered into the EntitySystem. The EntitySystem will Update and Render everything. Alongside the EntitySystem will be the PlayerSystem, which will handle input for any players. The WeaponSystem will be invoked via the PlayerSystem or AI. When invoked (e.g. when player or enemy decides to shoot), the WeaponSystem will initialize the bullets, based on a flag. This flag will dictate what type of weapon that Actor currently holds, and will create the correct bullets/weapon accordingly. Then the bullets themselves will be updated/rendered via the EntitySystem.


So I'm really excited for this, since everything seems to be falling into place nicely =D!

The "Revival" of Charge

Friday, April 9, 2010 9:23 PM XianForce
Labels: , , , 0 comments

As I said, here's the post where I'm going to talk about my second attempt at a shooter (quite the same one, really).


I'm still in the planning stages, and I have spent quite some time there, but I also want to invest a lot more time into it still.

What I really want to focus a lot of time into is System access. Since I've quite literally depleted my use of Singletons/globals, I have to make sure each System has access to any other Systems it needs to use. The biggest problem I'm finding with this is with the ApplicationSystem. For playing audio or rendering a class needs access to the ApplicationSystem. But I don't want every single object that needs to be rendered, have a pointer to the ApplicationSystem.

Really I'm trying to find an elegant way to handle rendering. Because as of now, here's what I have been thinking:

-Render method from current state is called
-Current state calls render method from ActorSystem (Actors can be NPCs or Players)
-ActorSystem iterates through it's list of Actors, and grabs it's surface, then renders it


Now this is all fine and dandy, but the kink I'm hitting is the ActorSystem itself. So what about rendering the bullets? Then I thought, hey, I can make it an EntitySystem instead (Entities are anything that moves). But then I would be updating/rendering from the EntitySystem, and the Actor would have little control over it.

I could just make a 'WeaponSystem' and call an accessor to it from the ActorSystem. But what if the Actor doesn't have a WeaponSystem?

So through this, I'm finding that in many places where I would 'just do it' I'm starting to think ahead at the consequences, to find the best method of implementation.

As I'm typing this, I'm actually starting to like this idea:

-Create a weapon system
-WeaponSystem would dictate what weapon the holder has currently
-Through this, the WeaponSystem would set up the children bullets, which would then be
registered into the EntitySystem.
-Everything is actually Updated + Rendered through the EntitySystem


So through this, anything that is NOT player controlled is all nice and set up. So for Player controlled, I will need to create a PlayableSystem or something of the sort.

Lately, around the ElysianShadows forum, many people have been posting about developing an Engine, and I'm so happy for all the great information I've gotten from them (Notably GroundUpEngine and GyroVorbis - I'll have links to their Youtube Channels below!)

But this whole idea of Systems came from something GyroVorbis said. He was talking about how everything is handled, like a CollisionSystem handles collisions, and needs access to an EntitySystem and TerrainSystem which control Entities and Terrain, respectively. That's when it really hit me, I need to stop being such a dip, and actually get something like that going. Albeit, I probably followed the same form in a MUCH LESS elegant way.


So, that's just what happens to be rambling around in my head regarding Charge at the moment. As for now, I'm going to get back to studying, and maybe some more design tonight.

Hopefully I'll remember to update again next week!

As I said: GyroVorbis and GroundUpEngine

Be sure to check both of them out if you haven't already, they are both AWESOME projects =D

Terribly Sorry for Lack of Posts

5:48 PM XianForce
Labels: , , , , , 0 comments

Well, school really picked up again, I'm trying to maintain that 4.5 GPA, and I just have a lot to do. But I keep coming back, because I want to maintain this blog in some way.


I know I probably have a lot of downtime, and then make a lot of posts quite frequently, but I'm going to try to at least post something each week, even if it isn't programming related - Starting with this post.



So I have been working lately, on many different things, so I'll try to cover everything I've done since the last post.

So since the last post, I cleaned up my framework real nice, and started making a few small demos to test every piece of it. Then I created a breakout game. I left it unfinished purposely, because I have a Software Engineering club that wants to get into game development. So In this breakout game, I've tried to implement a little bit of everything, and I'm going to run them through it after they make a couple simple games/demos and then have them finish it (really the base of it is done, only thing left is polishing really).

I thought it had some cool effects, like the blocks decrease in color intensity every time they are hit, and burst into particles when they are destroyed.

But as I was making this game, there were two things I noticed. Firstly, I found that I need to start planning things out more, and start using Systems (or 'Managers') to control everything, and have all those systems access each other.

The second thing I noticed, was that my framework actually had some inconsistencies that really really bugged me. There were also some excessive singleton use that just didn't need to be there, so I removed it. The only singleton in the framework now, is the debugger, but I have plans to make States singletons, just because it makes it much easier.

So after fixing all that framework stuff, the structure of it starts with the ApplicationSystem, which holds a pointer to a VideoSystem, AudioSystem, InputSystem, and StateMachine.

I'm quite digging the new structure of it, so I'm excited to continue. So I am now *officially?* reviving the Charge project, but I have now planned it out so much more.

The problem I faced with my first attempt, was that I had some very specific ideas, that, in my mind, made Charge what it was. I came across problems because my design was very hasty, so when something wouldn't work well, I'd try to recode portions. Then after that failed a few times, I'd try to make some horrible code to just force it to work. After a while, this quickly fell apart, and that's when I realized I need something like a framework.

As of now, I would definitely not say the framework is done. I have completely scrapped the idea for a GUI portion, but I still want some text stuff (I removed it because it was crap). I like the idea of having a Bitmap Font Engine along with TTF Fonts, but we'll see what happens.

So I'm going to make another post tonight talking about what I want to do with Charge, and how it's all going, but for now I want to talk about another small project I created.

I made a level editor and it works quite well I must say. There's just one problem - It has no GUI. So I'll have to find a simple GUI lib to use; I was thinking wxWidgets, or perhaps just recode it in C#, because it'd be simple... but then I'd lose cross platforming =(. Anyways, all of the features are done, it just needs a GUI lib to access them.

So the only other thing I can say, that I'm not sure that I've said, is that I want to start moving into OpenGL ASAP. I have a book that I've had for 2 years, and it is great I must say, but apparently my integrated graphics doesn't support OpenGL. So if I want to get that hardware acceleration, I need to either A) Buy a new computer, B) Use DirectX, or C) Wait for SDL 1.3 and hope it's Windows implementation uses DirectX over OpenGL. I also bought a DirectX book thinking I would like it, but I must say... I hate it. I dabbled in it, and made some small base code, and even made a small game, but I felt like it was too much work to be giving up on cross platforming.

Anyways, because I've chosen option A, I've been saving up some money. I don't get too much money, but I have saved up $300 so far, and I'll probably have $400 - $500 at the end of the year. I'm thinking I'll probably need $600 because I have to buy a monitor as well, but we'll see. Maybe I can get a job over the summer =D? I doubt it =/.

Well that's what has been going on, I'll make a post in a few hours about Charge, and talk about the 'extension' of my framework I'm itching to create!

The Framework is Most Definitely Done

Thursday, January 7, 2010 6:24 PM XianForce
, 0 comments

Well I finally wrapped it all up in a namespace, and have decided to call it 'ForceFrame'. I've been keeping up with the tutorials, and I might attempt to make another today.


Today's my birthday though... so we'll see how that goes...

Well just wanted to make a small update... later...

Subscribe to: Posts (Atom)