the unbroken beam

thanks to all around awesome smart dude scott hanselman for pointing out that i am not blogging enough. the idea has reinvigorated me to write more. even if no one cares, its a nice way to put it all somewhere before twitter, facebook, and eventually my ancient dimensia-ridden brain disappear from existence someday.

so, what the hell was i thinking?

one day i wanted to play a game. after looking around on the internet for a while, i couldn’t find it. there were no flash games that did what i wanted, and all games on all phones sucked.

i’ll make it then, says i. it’ll be fun. a game about reflecting light beams that doesn’t suck. i play a lot of games, and i bet i can make a great one. it turned into this by the way (it’s awesome i swear).

from that initial plan, one of the earliest design decisions i subconsciously committed to was the idea of following the same beam of light from level to level as you solved puzzles. after solving a puzzle, the the player follows the exiting beam onto the next level. cool right?

it was nestled in the back of my head, long before i added it to any ‘to do’ list, before targets became gates became orbs, before any semblance of the gremlin or a light engine. it’s not even part of the gameplay, it’s an aesthetic choice.

no single design decision has caused me more headache. the first flash version lacked a unbroken beam concept because i was mostly concerned with getting the engine mechanics working, and i was disappointed i had abandoned the idea. when i started work porting it to XNA, i saw the opportunity to make it happen since implementing a camera object in XNA was essentially a necessity.

the lonely time sink

i don’t want to even think about how much time i sank into the unbroken beam idea. the whole concept of loading and completing levels had to be designed around it. this is one of those design decisions that i think proves (at least to myself) that a ton of time was sacrificed for artistic pride. i had to make it work, i had no choice in the matter.

the easy way out? fade out, load level, fade in, done. pick a puzzle game – they do that. at any time, i probably could have just scrapped the unbroken beam in an hour or two. every time my math didn’t work out, every time i forgot to apply the correct transforms (in the correct order), every time a new level loaded sideways, my scrambled brain would throw its hands up (or ganglia, or whatever) and ask itself why i continued to drag its gray wrinkled mass through this crap.

it definitely inflated development time, introduced insane drawing bugs on simple stuff, and indirectly led to GPU memory leaks which were essentially invisible in my environment, besides a super detailed error that said ‘dude you’re out of memory’.

but i never did, and honestly it shocks me, now as i think about it, that scrapping it was never a real option.

so what whiner?

i survived, and for the very first time in the history of me, i brought a side project to life at a quality that is worthy of wide consumption. sure it took awhile to get it right, but in the end, it made my game more robust. it revealed everything i was doing wrong with my camera math. it extremely restricted level design, which forced me to put serious thought into how to link levels together.

but so what? as a calculator, i have to ask my self now, what was the boon? a more robust game engine, ok that’s nothing to upturn a nose to, but the end result is ultimately for the player.

and from the handful of player’s mouths thus far, its a cool swipe. maybe not the reception i was hoping for, but i must admit, almost everyone at least notices it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.