XianForce's Blog

Hey guys =D. Yesterday I didn't work on Charge at all. I was playing around with some stuff in PAlib and made a quick game as a 'joke' to enter a compo. So I got that done, and didn't really care to do any more coding for the day, so I just went to bed at that point.

Hey guys, just wanted to let you know that the first video of Charge is up, it shows all I've gotten accomplished so far. Here's a link:

I'm very sorry, I know it's been a few days since I shared an update, but I have gotten quite a lot done.

So I said I'd be working on the quad tree decomposition... and I did. I implemented it and everything and the way I went about it just made it completely suck. After that failed real hard, I thought about how efficient it really was, I figured that every collision is one check, and the work to update the section each frame is significant compared to that, so I've decided to scrap that.

So instead I created a simple particle engine. For the most part, I just took LazyFoo's particle engine and slightly modified it to fit how I wanted it to react. I may expand it a bit but at the moment I'm only worried about one thing: The colored surfaces.

So the problem is that there is 4 surfaces that are used in the particles. LazyFoo has them as global variables but I doubt he'd do that in a real project. It's bad practice because the entire game doesn't need it. The only thing that actually needs it is the levels.

So my problem is that I have to display the surfaces in the particle class, because if I declare them in another class, then they can't be accessed. I don't want every particle I create to create 4 surfaces because that becomes real inefficient, real fast. The solution is supposed to be static variables.

I admit I forgot what the keyword was. I knew what it did though. As of now the variables aren't static, it's getting late so I'll fix it up tomorrow.

The big problem is that static variables can't be initialized in the class they are created in, nor in header files. Not initializing it isn't an option because that causes static variables to not be in scope. So what I'll have to do, is initialize them in the play state, and see if that works.

Well for now that's all I got... so I'll be back tomorrow for another update.

Well This isn't the actual development post for today. I woke up about three hours ago, and got to work. I finished everything I wanted in the rewrite. All my code is finally nicely commented and it's real clean and organized, the task now is to keep it that way. So as I go along I'll have to make sure I'm keeping those good habits. Anyways, this post is just about the day void of development, and the post I made like at 2 AM this morning that had no screen shots. I decided to make up for that with 3 screen shots. The first shows all 5 enemies and the player and bullets within the level. The second is after the player has been destroyed, and one enemy destroyed. The last is 2 enemies alive and the player alive.

Anyways, I fixed the collision glitch. The problem was the rendering. The collisions were completely fine.

So down in the code I had something like this:

//Note: This is a function from LazyFoo's tutorials, so if you want more information on how
//it works, check out LazyFoo's site.

apply_surface(circle.x + circle.radius, circle.y + circle.radius, surEnemy, surScreen);

So now what's the problem with this... In my Circle struct, (x,y) is the center of the circle. Surfaces are applied from the top left. Adding the radius to x and y means that the bottom right corner of the actual graphic on the screen will be treated as the top left when calculating the collisions. This meant that sometimes the bullet could completely miss it, and the collision would turn up true. It also meant that the bullet could go right through it and the collision would turn up false. The latter is how I found the glitch. I shot the bullet so perfectly that it went through the center of the first enemy and nothing happened
and it continued up straight through all the enemies and the collision never registered. I just did a little searching and found the problem pretty quickly. Subtracting the radius instead of adding it completely fixed it.

Well that's all I wanted to talk about. Today I'm gonna take a shot at the quad tree decomposition, so I'll make a post tonight about how it goes. Ciao!

I know there's a day that's not counted for. I didn't get anything done yesterday, so I hauled butt today.

So the game actually compiles and works except for one collision glitch. Sometimes the bullets don't kill the enemy... it's weird.

Anyways so what I've gotten done since I started rewriting the code two days ago. I've almost finished the rewrite. It's in a compilable form, but there's still a few touch ups to be made, including fixing that collision glitch. Its real late, and I haven't the slightest clue of where the glitch is coming from, otherwise I'd fix it now. The only 'new' feature, is that the player can shoot up to 5 bullets now, and there are now 5 enemies in my testing level.

I made some nice hierarchies, but I think the inheritance needs some work. The biggest problems I had on this rewrite all seemed to do with inheritance. The first errors I was getting were because I was trying to directly access private data in the base class from a derived class. I decided it would be best to use protected data instead of private in these cases. It's like the best of both public and private. You get the data encapsulation of private member data, while being able to directly access them in a hierarchy. The second thing that really got on my nerves was the bass class not having the functions that the derived classes have.

A great use of inheritance is how you can use a pointer to generalize. So if I wanted to create 5 enemies, but didn't know what type of enemies, I could make an array of pointers like:

Enemy* enemy[5];

So after I declare that, I can store any type of enemy in there as long as the enemy inherits from the Enemy class. That's exactly what I did, but when I needed to call some functions in it, like when deleting the bullets, I'd call a destroy_bullet() method, but destroy_bullet() isn't in the class Enemy. This caused me to use a lot of pure virtual functions.

The first bit of research I want to get done, is to find a better way to control enemies with their projectiles and players with their projectiles. I want a way so I'm not stuffing base classes with pure virtual functions.

Once I get this stuff figured out the next thing I'm going to add is quad tree decomposition... otherwise known as the section system! Once all that is done, and I'm satisfied with it, we'll move on to the fun stuff, AI and new types of projectiles =D.

Well that's the update for yesterday, technically, so I'll try to post another tonight.

I'm not sure how to describe today. After many unsuccessful tries to get the enemy to shoot how I wanted it to shoot, I finally had it. It shooted exactly how I wanted it to. As I looked upon the code, I saw horrible practices everywhere. I knew I could make my life easier if I had just done many things differently. I decided to use the sections thing which I found out is actually called quad tree decomposition (thanks avansc!). Anyways I've decided to use that with circular collisions.

I also looked at the enemy and bullet classes and saw that it was going to suck when I wanted to create different types of enemies/bullets, so I grabbed a pen and paper and planned a lot out.

I decided that since I'll be changing so much, I might as well rewrite it, and comment more of it, and make it look better overall. So most of my day has gone to that, I'm nearing the end as I'm typing this post. As of now it won't compile so no screen shots today.

I'm camming the entire process with Camtasia and I'm goina to speed it up really really really fast and add in some touches and make it my intro video for any other videos I post.

Well that's what's going on. I can't wait to finish because it's going to make many things so much easier.

Hey guys, today it seems I got less done, but I still spent about the same amount of time I think. Today I created a simple block enemy that moves side to side for testing purposes. I then added in a collision function for collisions between enemies/bullets and players/bullets. I think, since it will be like Galaga, I can skip the collisions between enemies, as they will probably just move side to side, and I'll have some sort of path function that they can randomly execute. So in short, collisions between enemies won't be necessary.

I want to optimize how I check the collisions though, because checking all the enemies every frame just seems inefficient. At the moment I'm thinking of splitting the screen into 12 sections, and each object will have a variable to hold it's section. Each section would be 40 x 40 pixels, so I think that would only leave a couple checks, considering the sprites are 16x16 (bullets are 8x8).

I haven't added the sections yet, because I'm waiting for some opinions from other people to see if there's a better way to do it, but as of now, I think that's how I'll do it.

For all the games and demos I've made so far, I've always used bounding box collisions, its simple, you check 4 sides and your done. But I'm starting to find a 'bounding circle collision' detection might be more efficient. Instead of checking 4 sides, you check 1, it's all done with the radius. So I'm looking into that and maybe in the future I'll switch over to that.

Now that we've gone over the things I've been thinking about, let's see what was actually done.

The collision system has the capability for collisions between enemy/bullet and enemy/player, but it technically only handles enemy/bullet. The reason being the enemy moves left to right, as does the player, and the enemy doesn't shoot yet. But it's handled to where both objects involved in the collision are destroyed.

So the small things I had trouble with were a few segmentation faults =(. I quickly found them, but just as quickly forgot to fix others. The first segfault came from the bullet. With my collision function it returns an enumeration that I created that will tell whether the player or player's bullet collided with the enemy/bullet. The problem was it didn't check to see if a bullet was even there at all, so whoila, segfault.

The others were just the same, only with the player and enemy. They did their logic and rendering every frame, without any checks to see if they were NULL.


So today was pretty easy, I didn't code too much, and didn't have that many problems, but let's take a look into what I'm hoping for tomorrow.


So I definitely want to look into those two collision efficiency issues I talked about, but I'm not going to spend the whole day doing that. I want to start planning out more, so tomorrow I'm going to grab some paper and start drawing out the hierchies for the play mode and enemies so I'll be planning out multiple enemies. I may also work on planning a class to make paths. I'm thinking I could have path objects and have a function in the enemy class that follows the path. In the enemies logic I'd just have it randomly choose between moving side to side, or following a path, then it'd randomly choose a path. But this is all speculation, just some ideas.

But Tomorrow I'm definitely going to implement a timer and start capping the FPS. I'm also going to try to work on a system to get the enemy to shoot. If I find more positive views towards the whole idea about splitting the screen into sections, I could certainly implement that as well.

Well it's getting late and I must get up early so tomorrow's another day, and another update!

Well it's a new week and I've started a new project. After finishing Pong, I thought about what project I wanted to take on next. So I thought for a while, and thought Break Out or Galaga would be good ones, but after reading a comment on my Pong video from youtube, I decided to go with a Galaga type game. I've also decided to be a bit more 'artistic' and stray from exactly what Galaga is, so I'm calling it Charge. For now I think Charge is a temporary name, because I think all the different weapons (I'm planning power-ups, so that is plural) will have something to do with electricity. The other two games I have made took only about a week, but I am sure this one will take significantly longer. I'm excited from what will come of this game, because all the different things I'm going to work with that I haven't really worked with before.

The things I'm really aiming to implement in this right now are:

-Projectile System
-Particle Engine
-AI

Those are three huge things in game developement, and it's pretty important that I work with them. I read a little bit about particle systems, and it doesn't seem like it will be too hard to implement a simple particle engine. The AI will probably be the toughest thing, though. I don't want it to have incredibly dumb AI, I want it to actually be relatively good. Of course there will be other stuff in the game, but I don't want to blab all about concepts, so let's get onto what I got done today.

Early today, I did some set-up and created the state machine, and separated everything into files, and just made a project that compiled and created the screen. I then made some place holder graphics, one space-ish background, a red square to represent the ship, and a yellow square to represent the bullet.

I then created a Play state, but one thing that grazed my mind was how I am going to implement levels, I'm still thinking about it, but I'm sure I'll come up with something semi-intelligent. Once I had my Play state mapped out, I created a Ship and Bullet class. I'm using pointers a lot in this one so everything isn't on the stack, I'm finally starting to allocate some memory on the heap =D. I soon found that it proses a few problems, you have to be very careful in that everything that is allocated, is deallocated. When I ran the first 'build' (I'm using that term VERY loosely), the movement was out of control, and when you shot a bullet it would travel just as I had expected. I then kept pressing Space (Note: Space is the button to shoot) repeatedly to see the effect. The effect was that the bullet in the air disappeared and it seemed to revert back at the ship. I knew better than that though.

When I handled events for the ship, I had a switch block like this:

switch(event.key.keysym.sym)
{
case ...
...
...
...
case SDLK_SPACE:
bullet = new Bullet();
break;
}

See if you can spot the problem here...

The memory allocated, was never deallocated, so it just keeps using more and more memory while the old memory is lost forever. I pulled an easy fix making sure to not let the player create another bullet if another was already active, I'll be sure to add in more bullets later, but for testing purposes I'll stick to one.


The next problem I faced had me stuck for about a half hour. I could shoot, and it wouldn't let me shoot until the bullet was NULL. I assumed when you use the keyword 'delete' that the pointer is automatically assigned the value of NULL, I guess not though.

So what actually happened is the bullet would travel outside of the room, get deleted and now I have a stray pointer, then I have a statement that says something like:

if(bullet == NULL)
{
bullet = new Bullet();
}

So pointer doesn't actually equate to NULL, because I didn't explicitly set it to NULL. After I figured that out, I set it to NULL, and now the projectile system somewhat works.


So that's what I got done today, here's what I have planned for tomorrow:

Add in stationary enemies (So Enemies with no AI)
Add in collisions between the Bullet and Enemies
Add in collisions between the player and enemies

At the moment I'm thinking that a collision will result in destruction of both objects, and if at any time there is no player, the game will end, but when I get further in development to create a lives system, I'll just have a life be subtracted.


But another little thing I've had my mind on is how I'm going to handle collisions, I'm going to have to look into it a bit more, because there's going to be an abundance of enemies in the actual game most likely, so I don't want to check for a collision between every object, so I'm going to have to find a more efficient way to do so.

Well after that long vacation, I should have something to show for it, and I do =0. I ended up actually finishing Pong, I accomplished everything I wanted in it, so I'm ready to move onto something else.

So at the bottom of this post, I'll have a link to the video of Pong, so if you want to watch it, go ahead.

Anyways, at the start of my vacation, the regular 2 player mode worked, except there was no system to keep score. I had a little bug on displaying the score, I was keeping track of the score in an integer called points, and I used a little C to display the integer as a string. so I was doing something like this:

void add_point()
{
++points;

char pointAmount[3];
sprintf(pointAmount, "%d", points);
surPoints = TTF_RenderText_Solid(font, pointAmount, textColor);
}

Since pointAmount is an array of characters, its passed as a char* into functions, which should satisfy the the function. Problem is it didn't. Later I found out, I had forgot to declare it as an array, so it couldn't convert from char to const char*. After that was fixed, the regular 2 Player Pong worked fine, the next step was to create so I could actually play alone =p.

Now I haven't the slightest clue what I did wrong in making the CPU. I made it and I looked over it quite a lot. And after it was done, it was the buggiest thing I had ever seen in my life. The thing looked like it was on speed, bouncing around like no tomorrow. The more I tried to pin down what was wrong, the worse it got. I decided it was too horrible to even use, so I took it out and decided to start from scratch.

Before I re-started the CPU, I implemented a pause feature. It sucked, but it worked for the time being. I just used an SDL_Delay after rendering if a pause flag was true.

When I remade the CPU system, it worked completely how I had planned, so that portion was done with.

I then upgraded the pause feature to what it is now, I had no problems with this, it was actually really simple.

After that, I just wanted to add in sounds, change the graphics a bit, and add in a challenge mode. So the first thing I did was add in sounds, all the music I used was created by Rachel J. Morris (LussikkaMage) and were taken from her public domain sounds over at Moosader.com. The sound effects were just some other public domain sounds that I got from a random site that isn't really important.

I made the graphics myself (hence why they suck), but it is a little more interesting than the black and white it was before.

The challenge mode became a problem when I failed at making a timer. I screwed up the timer's pause and resume methods, so the score would go out of wack when the game was paused. I found the problem, I forgot subtract the current time, from the start time when I assigned the value to the ticks when paused.


After all that was done, I took a 3 day break and got some nice relaxation. I also made a little bouncing ball demo while I was up there, because I was bored, and wanted to play around with some gravity effects.


Well that's the end of Pong development, soon I'll start my next project and will document everything about it.

Pong Video

Important Links/References: PAlib, Elysian Shadows, LazyFoo, SDL, Moosader

The links I have posted above are things worth checking out =p.




Hey guys, I doubt any of you know, but I had another blog prior to this blog. Due to difficulties with Google accounts, it had to be deleted, and thus a new one made. I'm not going to go back and re-make all my posts, I think it will be better and easier if I just completely start anew and perhaps just bring up small details from previous posts.

Now that all that stuff is over and done with, let's get on to the real introduction.

I'm Skylar, and I'm a novice game programmer, and I have been programming for almost 2 years now. Up until this point, I haven't been real sure of what language/API I wanted to use, so I had a lot of mixed knowledge, and little to no experience. I finally got tired of it so I looked around, and decided to use C++ and SDL as my language and library, respectively.

This blog will detail the different challenges I come across, how I solve them, and it will also cover what progress is made. I hope to be able to post something relevant everyday, except for this week, because I'm on vacation and won't have internet for much longer.


At the creation of this blog, I have my first game with SDL finished: Tic Tac Toe, and I am working on my second game, Pong. I know these are beginning projects you generally see everywhere, but I'm trying to give my Pong clone some extra features that make it stand out from the rest.


Now I guess I'll talk a bit about my inspiration for getting into game development. As a kid, I always had the dreaming fantasies most of us have about making our own game. We get great ideas and we don't think much about how hard game development actually is. Well a few friends and I got a bit overambitious and detailed a large game out, I still can't even remember what genre of game it was. Well through a friend, I stumbled upon Game Maker and used that quite a bit at first, but I didn't like it so much, I used it for school projects to score some extra credit, but I hardly used it.

Then I bought a flashcart for DS. After searching through Youtube videos of how to set it up, I found a video about a DS homebrew project; Super Smash Bros DS. I watched the video, and even though it was only a simple demo, I was absolutely amazed. I thought, "I wish I could do something like that!" and through the comments box on that video, I found PAlib, a library for programming DS games. I found I would need to learn a programming language and I chose C. I then went through simple pieces of the library and had a lot of trial and error.

I didn't understand a lot of key features of the C language, things I would need to understand to get anywhere with game development. For example, the first game I made with it, was a copy of Bowman for the DS, it had no menu/title screen, and it only had birds that could be shot. The graphics sucked, everything was either a line or a ball, and the programming on it was just horrid. When I would clear the screens, instead of making a function to call the 6 functions to clear the backgrounds and sprites from both screens, then reinitialize text on both screens, I just called the 6 functions everytime the screens needed to be cleared.

After all that epic failure, I found another homebrew project that looked very interesting: Elysian Shadows. The project looked amazing, and they had a video series titled "The Adventures in Game Development." Falco (The leader of this team) also had some videos on how to get started on Game Development, I watched them and it completely changed my perspective on what I needed to do. He really laid it out. He didn't obscure anything, he told it like it was. So the next day I went out and bought a nice big book on C++, and after reading most of I started to learn the API, SDL. I found Lazy Foo's tutorials and I must say they are amazing.

So that's how I got started on game development, hope any reading this make the jump into it as well.