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

Configuration File Added to the Framework!

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




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

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!





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!

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!




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

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

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

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

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