Sign in to follow this  
MikeRasicci_176717

Bad solutions and how you handle them

Recommended Posts

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?

Share this post


Link to post
Share on other sites
inavat    317
[quote][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[/size][/color][/quote]

Those two sound equivalent. What's the difference?

Share this post


Link to post
Share on other sites
Telastyn    3777
[quote name='A Brain in a Vat' timestamp='1306968345' post='4818445']
[quote][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[/size][/color][/quote]

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.

Share this post


Link to post
Share on other sites
Dunge    405
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.

Share this post


Link to post
Share on other sites
DarklyDreaming    367
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 [i]or[/i] when you know it will be too cumbersome to work with eventually - doing things the 'nice' way is a fast track to never finishing [i]anything[/i]; 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 [i]might[/i] just slow you down enough to get discouraged with the lack of progress.

Especially when you do it [i]all the time![/i]

Share this post


Link to post
Share on other sites
Postie    1559
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.

Share this post


Link to post
Share on other sites
rip-off    10976
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.

Share this post


Link to post
Share on other sites
inavat    317
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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this