Project Tarot: End of week

David Shaw, 12:58 am 17th December 2009
Posted under: Blog Babble

Project Tarot - Tile Prototype

The week is over, and technically I failed. Bummer.

What I did get done was a tile-based prototype, shown above in the screen shot. It’s an experiment for what a tile based puzzle game would be like if the tiles consisted of two colours, split at the diagonals. In the version above, the coloured sections get highlighted if there’s a connection chain of four or more tiles long. Unfortunately, it’s currently just a toy. I didn’t think of a good way to make a game out of it. I was on my way to experimenting with a Tetris-like mechanic – matched tiles disappear, replaced with tiles above – but I ran out of time.

I might continue working on this at some stage, but I’m doubtful. Coloured tile games don’t excite me as a developer, mostly because I suspect every single gameplay combination has been done to death by now. I’m also not sure if it’s worth posting the prototype: it’s not fun, dead simple, Mac OS X only and spits log files into a subdirectory in your Library folder that you need to clean up after. Maybe next time. Part of the point of just having a week is that if I need to walk away, it doesn’t feel like much of a waste.

I’ll need some time to evaluate what went right and wrong from this exercise, but I’ve got some ideas of how things went off the top of my head.

First: I need to organise my time better. I just dove in, and while the time pressures helped me stay focused to begin with I went a bit all over the place with my focus. It would have helped to spend an hour or two at the beginning figuring out exactly what my objectives are, the best way to achieve them in the time available and pitfalls to avoid. With the haphazard approach I can get focused with deadlines, but I’m easily distracted by non-essential things. I also lost a lot of energy at the end which is part of the reason why I only got a prototype done.

Second: prototyping in C is a pain. Having a better set of in-built functionality at my fingertips would give me a lot more flexibility. I wouldn’t have to waste hours of work trying to think of a C friendly way to do the tile connection counting algorithm.

Third: prototyping puzzle game ideas in a short period of time is hard. I suspect if I just did a simple action game I’d have got something finished in the time. It’s easy to kludge together something amusing in the action game genre, but puzzle games live or die on their core mechanic. I don’t know if this is inherent to the genre or just my lack of practice with the area.

Fourth: if I’m not excited by the idea, then it’s really hard to crunch development. I didn’t exactly go “full out” in developing this one, a conscious decision to see whether it could be done with a sensible workload. But I confess it also meant I slacked off the pace in the last couple of days when minor issues reared their head and made completion all that more challenging. Maybe if I really loved the idea I might have sweated through the headaches (metaphorical and literal), the random Xcode crashes (grr) and the heat. But in the end, yesterday I effectively waved a white flag when it was clear I was out of time. I feel bad about that.

So… where to from here? I might have not completed an actual game, but it was a good exercise. My feeling is I should repeat the process until I get good at it. There’s one week between now and Christmas; that’s plenty of time for another small game attempt. This time, I’d like to give Python a whirl as a comparison. I need a theme though. I’m happy for any suggestions, otherwise I’ll take something at random in the next few hours.

3 comments for “Project Tarot: End of week”

  1. Matthew says:

    I think you should stick with a known quantity. Choose a classic arcade game that already has set gameplay and implement it. You are after all seeing what tools work for you and that will take a lot of the pain (and time) out of the week-long project. Something like Asteroids, Space Invaders etc. would be my suggestion.

  2. David says:

    Hi David, I found your blog from your great tutorial on inkscape drawings (based on Order of the Stick). Not the purpose of my comment, but I take the opportunity here to say how much I loved this tutorial. It really rocks. Clear, detailed and real fun to follow. I have now a tiny avatar which I am proud of, thank you for this.

    Ok, now, that is not the main subject of my comment.
    Actually, I read your blog because I am also lurking into the possibility of making games myself as job. (I also followed the Andrew Russell blog). Both blogs are very interesting.

    I think it is good idea to make a lot of small projects to learn. This makes you more and more familiar with a technology, and you can do better and better things in less and less time. So your 1 week “contest” was a great idea.

    Now, what I do not understand is : you are trying the same thing in Python. So you will spend time again to learn a new language, get Python installed, get proper Python games libs, learn their APIs, read Python games tuts and so on…
    That’s a lot of time that you could spend trying new game mechanics instead, isn’t it ?

    You spent time to learn Flash, I think, that could be helpful to prototype games.

    I just have the feeling you are spending more time learning games technology than writing games themselves.

    So I am curious to know why ?

    Ok, so thank you for your very interesting blog anyway. Looking forward to read it further.

  3. David Shaw says:

    Yes, I’m a bit wary I’m spending too long shopping around for the “perfect” language and approach, rather than knuckling down with the one I know best.

    The prototype above for Tarot was written in C, which is the programming language I know best. C is quite low level when compared with languages used these days, which is good if you need hand-written speedy code. The downside is that it’s easy to get bogged down in small implementation details. I spent a lot of my time in the prototype above writing code that comes for free with the libraries that come with Python. You’ve also got to put some effort into managing all your data, which is distracting when you’re intending to belt out ideas.

    Python is nice in that it has libraries for near everything and a syntax that makes it easy to cobble parts together. It’s a lot faster to get something up and running in Python than with C, even with the use of libraries. My main drawback with Python is inexperience; I’ve been using it for a year or two now, but I’ve only written rather small programs and my code tends to be somewhat “C-like” rather than using the full strength of Python.

    Flash is something I’ve dabbled in, but it hasn’t yet clicked with me. I still think it’s worth learning as posting apps and games to play in web browsers online is really useful, but I’m uncertain as to whether it’s worth using by me as a prototyping tool due to my unfamiliarity with it.

    Summary: Python seems to be best for messy on-the-fly code, which is what I write when I prototype. C is good if I can plan the code in advance. Logically it seems best to start in Python, then move towards C if I need to.

    And I’ll try to blog more in 2010 as I go (I’m not a natural blogger yet). Should be an interesting year. ;)

Leave a Reply