Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


it seems i may have discovered one of the biggest flaws i've got in my programming brain-chemistry. i, like many others, like to be able to have something palpable as i work along with a project. i code something i can see right away, and then proceed to add to it and change it until its closer to what i want it to be. code, compile, run. code, compile, run. and so on. sometimes you have to break apart what you had so that you can extend it more easily - hopefully there's no visual change, other times its enjoyable new additions. pretty obvious stuff, nothing bad there. so what's my problem?

i'm too focused on pretties. i code something and right away, as i look at it, i'm wondering how to make it look better. forget about the code, i mean visual aesthetics - what many people would want to leave until the machine itself is in a decent state, i tackle long before i should. i've been moored because i couldn't figure out whether i should allow for 8 directions or just 4. i've been stumped wondering about how i'd do graphic X with api Y. why can't mario be an unanimated solid-colored rectangle? as i code, it feels unacceptable to have to look at that when i can have something a little more mature.

programmer art exists because that aspect isn't important when you're doing your back-end. it'd be nice, i suppose, to have an artist churn out graphics that you can use as you build - but i'd say that was a rarity. i get too excited about how its gonna look, WAY too early. making animated gif mockups took longer than it should have because i got too distracted about making them look good. i spent 2 hours last night creating an animated coin box gif. was it because i had trouble finding the graphics to rip? no. i took 2 hours to figure out how to create a parabola function out of known roots and max. i wanted the coin path to be pretty. 2 hours lost, for nothing.

after i got that in my head today at work, seperating the logic from the graphics THE OTHER WAY seemed to make more sense. until now i've been writing logic that included graphics work to update animations, as an example. why can't the graphics module do that work on its own? of course it can. sure, that means that the graphics objects will have to have their own state information - but WHO CARES. maybe i'm still stuck in the days of DOS, where you had very limited memory constraints and had to share as much info as you could. saving memory is still an issue today, but for simple things like 2d sprite/tilemap games - you're pushing your luck if you say you've gotta worry about things like that.

i feel renewed.
Sign in to follow this  

1 Comment

Recommended Comments

for anyone curious about the coin box anim, here's what i wasted the two hours trying to make look good:

was it worth 2 hours? well, i did it when i was starting to get tired, so i suppose i wouldn't have gotten any good work started - and i hadn't come across my new thought today... so i suppose i'm glad i did! at the least, its pretty..

Share this comment

Link to comment

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!