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

Day 2 of Charge Development




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!

0 Response to "Day 2 of Charge Development"

Post a Comment