Falling block matching game

Download source

I’ve always considered embedded programming as something that only people who practice black magic can do, with the aid of sacrificing several small animals. I’ve come to terms with the fact that writing application code allows you to manipulate data and do interesting things, like mine databases or create games, but I just assumed that getting your software to interact with something physical, something that I can pick up and spin in my fingers was something that would be well beyond the realms of my intellect. Luckily I like a challenge, and given the opportunity I figured I’d give it a go.

It sort of came about by accident really, one day I was browsing reddit when I saw an ad spruiking NerdKits at the top of a page. I checked it out, and it turns out it’s a bunch of guys in America who decided to make a beginners pack for embedded programming. I, along with a bunch of other redditors (Note to self, when I have something to sell, advertise on reddit) handed over my cash money and received the kit. I went through the tutorials, then started modifying them to try and learn some more things. Not long after that I realised that if I was going to actually learn anything I was going to need a project, so I though what a better idea then writing the ‘Hello World’ of the game world: Tetris Falling block matching game. [1]

So off I went, and here are my results…

Breadborad
Breadboard

There she is. Not the most beautiful piece of electronics you’ll ever see, but it works. Here’s a rundown of the parts…

  1. Push Button – Move piece left
  2. Push Button – Move piece right
  3. Push Button – Rotate piece
  4. Atmega168 Microcontroller (MCU) : Stores the program, and allows you to tie together the pieces.
  5. ADC (Analog to Digital Converter)– Random number generator
  6. Crystal Oscillator – The clock for the circuit
  7. SPDT (Single pull double throw) switch. Used to set the board to either run normally, or put it in programming mode to update the MCU.
  8. Resistor (1K Ohm) – used to set the contrast on the LCD
  9. Voltage regulator

That’s it. The only components I had to get separate from the original Nerdkit were the push buttons, although they were bigger than I had anticipated and things got crowded on the breadboard pretty quickly. Next time I’ll be sure to check the dimensions of what I’m buying, but I think it would also be a good idea to get a bigger breadboard anyway. I ended up using the ADC to generate my random numbers, which is used to determine the next piece. I got the idea from the NerdKit forums, where basically the last significant bit is so volatile due to temperature shifts and noise that every time you poll it you should get something different.

Breadborad and LCD
Breadboard and LCD

It took a while to become familiar with how to interperate the values sent to the MCU and how to handle interrupts, but like most things once you get your head around it it’s not that bad. What completely threw me off was a whole range of new things that can go wrong. From my non-electronics background, I ‘knew’ that a switch has two states, on and off, but what I learned was that when you press a switch the state actually flickers between on and off for a few milliseconds until the switch comes to rest. This wreaks havoc when you are reacting to whenever a switches state changes. I had pieces flying all over until I read up on debouncing , which is basically just not taking a switches value when it’s changed straight away, but giving it time to come to rest first. My approach was that if the button has been in the same state for the last 10 checks, then it is safe to consider it changed, and then use it’s value.

Game in motion
Game in motion

For the future, I am thinking about adding sound and some other features to my game, although I also would like to start playing around with motors and sensors…

Game over
Game over

[1] Originally I was going to call this simple game Tetris, although I went for an interview at EA, and was warned that there was another game with the same name already. That’s one of the things I like most about ‘Falling block matching game’, how it is in no way like any other game created.

Posted in Embedded, Games, Programming | 1 Comment

Mouthy Mouse

While I am getting everything set up I figured I’d share my first game I made with flash. I made this as a university assignment back in the day and I’m pretty sure I got a decent mark on it. It’s a very simple kids game, that contains three mini games. There is ‘Cheese Wars’ which has cheese shot out of cannons which you have to catch, ‘Cheese Rain’ which is essentially the same as cheese wars, except it falls from the sky, and ‘Find the cheese’, which is a guessing game, where you select which platter you think the cheese is under which is totally random. All three games get old within a minute or two, although my nephew seemed to like it.

The executable can be downloaded from here: Mouthy Mouse

Unfortunately I have lost the source since then, so I can’t post it.

Cheese Wars
Cheese Wars
Posted in Flash, Games | 1 Comment

Things are gunna change ’round here…

If you’ve even been to this site once before, you may have noticed that everything is completely different. You may also notice the fact that I haven’t updated this site in a long time. Well, that’s about to change. I’m planning on getting on my lazy ass and getting this site done properly. So if you can just ignore anything broken around here for a little bit (the CSS for one), I’ll do my best to have it spick and span in the coming days…

Posted in Excuses | 2 Comments

Stop rolling the dice

If there was any one rule that was the most important in software development, I’m pretty sure it is ‘Have some form of version control, you idiot!’, and I have been breaking that for a while. I didn’t mean for it to happen, one thing just lead to another, you know?

Over the lifetime of Neo Chess, I’ve come up with a bunch of excuses not to bother putting in a version control system.

  • There’s no point implementing version control when the project has only just started
  • There’s not really any need since I am the only person working on it
  • It’s easier just to take a backup of the game evry so often than bother with setting up a full system
  • I’m a bad ass gangsta living on the edge and I don’t need your damn version control rules

I couldn’t have been more wrong on all of those points (except maybe the last one).

I just got a new hard drive for my computer, and was upgrading to windows 7, so I figured since I was formatting and would have a hard drive spare to hold my backups, I would bite the bullet and finally get something put in place. I have used perforce and subversion in my previous work roles, but I remembered reading a post by Joel Spolsky about a version control system I’d never heard of before, Mercurial. I like to learn new things, and I figured maybe this Mercurial thing might be the next best thing.

I downloaded and installed it (which was incredibly easy) and then cloned a repository. I spend a fair bit of time fighting with the system trying to set things up the way I always had, by having a base folder in the repository, and having different projects under that, when what your supposed to do with Mercurial is have a repository for each project. After I finally figured that out, I thought I was all sweet. I did some work on my game and went to commit it back to the repository, but I got confused as to how I was supposed to do this, and where everything would be stored. Eventually after reading about it on the nets for a about an hour, I uninstalled it and installed my nice safe Subversion. This isn’t a reflection on Mercurial in any way, I’m sure it’s a fine version control system, I just figured in the end I was wasting too much time messing around with my tools, and not enough time getting things done.

So now that I have my version control system installed and set up correctly, I don’t know what the hell I was thinking putting it off for so long. The are heaps of benefits to version control

  • Obviously backups: Once you are done making a change to some code, you back submit it, and it’s now backed up (although don’t forget to also back up your repository, I’ve seen a hard drive with everything in the repository on it go down with no backups, and it wasn’t pretty )
  • Reasoning: If I’m looking through a file, and I see something strange and I think to myself ‘Why the hell did I do that?’, you simply look through the logs, find the change you made and look at the notes that you wrote as to why you made it
  • History: It gives me the ability to think, what did my game look like on Tuesday August 4th 2009, and I could easily check out the files from that date, and see exactly where my game was at.
  • Double Checking: Before I ever commit anything to a repository, I always go through every file and diff it against the original. The benefit of this is, you can catch code that you thought you were going to use, but never did and remove it so that it never gets into your source. Also, I’ve caught a lot of stupid mistakes at this stage.

I’m sure there are more I can’t think of right now. But for me the biggest one is freedom. Before I had version control, I used to just copy and paste the whole project into a backup directory about once a week. Then if I am working on my game, and realise that I need to restructure one of the main classes it was risky. I would comment out large chunks of the code, and re-write bits, which then would mean I would need to re-write things in other classes and before long I would hit a point where, if it didn’t work or I was better off with the first structure, I was in trouble. Trying to get it back the way it was is hard, and very time consuming. Now, I can make a change knowing that if I stuff something up, it’s only a matter of 3 mouse clicks to revert back to the origionals.

I love you source control.

Posted in Programming | 2 Comments

When does writing tools start to become a problem?

When I first started Neo Chess, I decided to make a tool that handles logging. It takes all the logs the game spits out the results in a nice list that is filterable by the logging level. Then I thought it would be nifty if I could do a text search on the messages, so I can look up specific errors. I’ve thought of extending the tool so that I can real time update values in the game without having to restart wasting valuable time.

Then I was recently reading a post the other day about using custom attributes in C# to keep track of todos. It’s an excellent idea, and one I’ve since implemented in my game, and one I will continue to use from now on. And I am now thinking of extending my logging tool to also show an active list of todos, with varying levels of severity. Although I am starting to question if this is a good idea.

Obviously creating tools that streamlines the production of my game is great, and it will save time in the future. But what is the initial upfront time cost of making them? I am a one man team, and any time I am working on anything else is time I am not making my game. I usually convince myself to do it, thinking of my future me (that bastard better be appreciative), but recently I am leaning towards just sucking it up and working on my actual game, as opposed to all the peripherals.

Posted in Programming | 1 Comment