Bad solutions and how you handle them
Author
Sometimes when coding games, I feel like the way I do something isn't really the right way to do it. I know there isn't actually a right way, but it feels like theres a better way to do things. For example, my title screen was done by first displaying the background image, drawing the text to the screen and then displaying a sprite that looks like an arrow next to the text. Instead of just moving the sprite, I had the Up and Down arrow keys redraw the sprite at the new position next to a different piece of text. When you hit enter, whatever text you were next to would do what its supposed to, exit, start the game, open options etc. I feel like clearing and redrawing the sprite is a bad way of doing that. Obviously I did it because it was the only thing I could think of with my limited knowledge of the API I'm using and I'll find different ways, but should I really avoid doing things like this in the first place? Or do you think as long as it works and it isn't using the entire systems resources it isn't a big deal how it gets done?
[color=#1C2837][size=2]Instead of just moving the sprite, I had the Up and Down arrow keys redraw the sprite at the new position[/quote]
Those two sound equivalent. What's the difference?
[color="#1c2837"]Instead of just moving the sprite, I had the Up and Down arrow keys redraw the sprite at the new position
Those two sound equivalent. What's the difference?
[/quote]
Instead of moving the sprite's position he's destroying the one and making a new one in the correct place.
For the OP: Does it work? Is it preventing you from realistically finishing the game? Just leave them.
Especially starting out, the urge to fix stuff with lessons learned/more knowledge is strong. But it's important to finish the game. The further along you get, the more complex/different problems you encounter. Spending a bunch of time fixing something that essentially works prevents you from getting the game done (what matters) or learning the other lessons.
In the first game you do you'll encounter hundreds of these situations and most of the time you'll hack your way through doing it "not cleanly". Just think about them, and learn from them. Next time you create something from scratch, you'll think your architecture much differently based on the problems you encountered before.
What isn't broken isn't worth fixing. Spend your time on developing and learn from your mistakes and make better of it next time. Only refactor when something is too hackish to be viable for long or when you know it will be too cumbersome to work with eventually - doing things the 'nice' way is a fast track to never finishing anything; there is always a nicer way to do things, live with it! Easiest way to do this is simply making a plan and sticking to it. Don't fool yourself; making that mapping tool just a tad bit faster, or fixing that annoying bug that happens every so often, is not very likely to do much for your project - but it might just slow you down enough to get discouraged with the lack of progress.
Especially when you do it all the time!
Especially when you do it all the time!
I normally write a short "TODO:" block near the offending code with ideas for future enhancements, and then periodically I do a search for all TODO blocks and see if there's anything there that I feel like addressing.
That way if I don't feel like working on a totally new feature, I have many options for improving existing code.
That way if I don't feel like working on a totally new feature, I have many options for improving existing code.
If you have a deadline you'll end up doing this from time to time. The trick is to know the difference between "it would be nicer if" and "this is wrong". In this case, it would be nicer if you didn't have to recreate the sprite, but it doesn't affect the functional menu so its a very low priority. In other cases, you'll end up putting in hacks or shortcuts because you don't have time, these will need to be addressed eventually, so they have a higher priority than the former.
A TODO: or something similar that your IDE can highlight is nice for the former kind of cleanup job, but the latter should be in your bug tracker or similar.
A TODO: or something similar that your IDE can highlight is nice for the former kind of cleanup job, but the latter should be in your bug tracker or similar.
I guess I'm a little confused. If you're bothered by the fact that you are destroying the sprite rather than moving it, why don't you move it instead? How much work could that possibly be?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
