I'll take two

I'm chasing those ideals again. The Right Thing to do is to separate out your business logic from you interface. I read one piece of advice which stated that if you want to know if you've succeeded in separating out those responsibilities, it's the same answer to the question "is my app skinnable?"

I sometimes find it difficult judging where the line should be drawn between the UI and the underlying data. So my idea (which is probably similar to the skinnable question) is to write two applications side by side, that each access the underlying business code. If I've done the job correctly it should be obvious (or at least easier to see) where the shared data begins and the custom UI ends.

Similarly, while I'm writing my next game engine, I'll try to write two (simple) games with the engine simultaneously. This way I can (hopefully) pull all the common code from both games into the engine. It helps me know where to draw the line.

Set in Stone

Many years ago, when I didn't know better, I wrote some games, partly as a learning exercise, partly to put in my portfolio, partly for fun. They were a Tetris clone (Tetratim) and a breakout clone (Bounce). But it didn't matter that they were clones because the main reason I wrote them was they gave me the experience of taking a game all the way from start to finish.

Tetratim was the first complete game I ever wrote. It has a start screen, an in-game screen, a game-over screen, and a high score table. Apart from the high scores, all of the data was hard coded into the game-code. (I'll come back to this point in a minute).

Bounce took things a little bit further. It has several UI screens at the front, and included sound effects. The levels were designed in an editor that I wrote. I'd started learning to separate out my code and my data.

Even though I didn't stop programming after that, the game writing dried up. Not through lack of enthusiasm about the projects - I had plenty of exciting ideas that I wanted to implement. No, the reason the writing dried up was because I had become obsessed with ideals. I didn't want to hard-code data for another game. I didn't want to take short-cuts in my code. I wanted to do everything the Right Way.

So I spent lots and lots of time learning the correct way to do things, writing lots of little test programs, trying out new techniques and effects, and storing them all up for later. But for several years I didn't come up with anything that was as near finished as Tetratim or Bounce.

Fast-forward a few years to when I was preparing to enter the games-industry. Suddenly I had an urgent need to have demo material - something that showed that I actually did know how to program games! Urgency is an excellent motivator. Within the space of a few days I threw together a demo of a 3d car driving around on a surface.

A lot of the demo wasn't done the Right Way. The worst offence (in my eyes) was that once again, I'd hard-coded my data into my program. But it didn't matter. It was a neatly packaged, little demo. And that demo got me my job in the games industry.

At first I spent a lot of time programming in my spare time as well as at work, but I was still chasing the ideal. I wanted to do things the Right Way. Again a dearth of completed projects.

Which leads me to now. I have epiphanies from time to time. One of my most recent was "Nothing is set in stone."

It doesn't matter if it isn't written perfectly first time - get something written, and you can always change it later if it isn't correct. Make things modular, if at all possible, then if something is wrong you can "unplug" it and plug something else in in its place.

Ok, so don't dive in straight away - some planning is always good, but don't agonize over the fine details to the detriment of project. That's what I did in between my demo games and it meant I didn't get anything completed!

SMS to Email

Found the email address to send emails to my mobile.

http://basicstate.com/htm/page.htm

Now I can get sms alerts when I receive an email.

The tape fell off

I was getting a stream of exceptions in my output window when doing a drag-drop. They didn't seem to be affecting my program; the exceptions were in windows code (rather than my code); they weren't stopping my program running - just appearing in my debug output window.

I googled for the exception. I couldn't find what was causing them, or how to stop them occuring. But I did find a post explaining how to stop them appearing in my output window (right click the output window, untick "Exception Messages").

Obviously it would need resolving eventually, but this worked as a stop-gap solution.

Trouble is, the "solution" reminds me of an episode of the Simpsons...

Lisa: Hey dad, that light says check engine...
Homer: Uh oh... the tape must have fallen off.... there, problem solved (engine stops)

Chrome

I tried out google chrome.

It's... interesting.

But I'm not going to use it for now because:

* The title bar doesn't fit in with my other windows.
* If I close the last tab, chrome "helpfully" closes too.
* No adblock.