For this week’s Thousander Club update:
Game Hours: 238.25 / 1000
Game Ideas: 507 / 1000
Target: 966
I managed to add the ability to shoot a weapon in my Space Invaders clone. As of now, if the bullet collides with the enemy sprite at the top of the screen, the enemy disappears.
Yes, that orange thing at the bottom is the player’s ship. Hey, it works.
I am giving myself permission to stop every so often and plan my next move. Getting this far was actually simple since I had a fairly good idea what I needed to do. My next moves are not as clear. I think I will work on abstracting the interface. Right now, I have code that looks like “If Space is pressed, then make the bullet move up”. Everything is hard-coded, and I think at the very least the aliens can be made into a more abstract entity. In fact, I should be able to take my one alien and give it some friends. Otherwise, it would be a very boring game.
Also, I am not happy with the speed. It runs very fast, and I think I can experiment some more with the delta code I am using.
I don’t want to try to abstract things too much. I have already been down the road of abstracting too much, which resulted in not getting anything concrete accomplished. I don’t want my code to be completely hard-coded, either. If I keep doing small changes, though, I should be able to mold the project the way I see fit.
7 replies on “Thousander Club Update: December 11th”
Glad to see the game is coming along 🙂
What’s the speed issue?
Actually, I fixed it last night. At least, it seems fixed for now.
Basically, it was running way too fast, and I thought I would have to change the way my delta is calculated to do frame-rate independent movement.
It seems that I already had a line to delay: SDL_Delay(1);
I just changed it from 1 to 10, and it slowed down to a sane, playable speed. I imagine the same thing could be done with my Pong clone. B-)
IMHO, the only way to really know where the right balance is between overly hard-coded and too much abstraction is experience. My advice would be to just hard-code the heck out of it and see what you end up with. At that point you’ll be able to identify the bad parts and refactor them into something better. Then on your next project you’ll have a better foundation to make decisions from.
Do the simplest thing that will work and if it stops working, refactor.
Thanks for the advice, Ken! I’ll try to remember it when I am sitting in my code and thinking, “Well, I don’t want to do this the ‘wrong’ way”, which usually means I end up doing nothing productive.
btw, ken and I aren’t the same person 🙂
But I do notice that you two have never been in the same room at the same time…
Do I sense an Indie-SuperHero in our midst?