Category Archives: Game Development

My own work on game development

PyStroke: Pre-alpha at last!

It’s been a long time coming, but I finally got my game engine properly online in a version controlled, browsable form. Say hello to PyStroke v0.02!

This isn’t an amazing success, or even much of a step forward, in terms of programming. I haven’t worked much on it since Ludum Dare, thanks to various assignments, including writing a twenty-page report on PyStroke and assorted research as part of my Final Year Project. However, I have met some nice people through Reddit and Twitter who are interested in reading the code and giving it a try. As well as that, I wanted to have a build online by Christmas. Unfortunately that wasn’t possible, given the aforementioned assignments taking up so much time, but less than two weeks later isn’t too bad, I don’t think. And technically, my Ludum Dare game included a build of the engine more than a week before Christmas, it just wasn’t very readable. So overall, I think I succeeded.

The code isn’t exactly pretty, but it is very, very much a work in progress – pre-alpha is even being a tad generous. I have used it to create games, but I don’t necessarily think it follows that someone else will be able to. In the next week, I hope to knock together an extremely simple game and write a little tutorial on how the engine is used, as I see it.

There is one semantic bug that isn’t going to go away for a little while – rotation of the ‘vex’ (or vector sprites) uses a slightly incorrect call to do some of its calculation. The rotation works, but under the hood it isn’t strictly right. I’ll need to give that some time as a priority in the coming days.

Anyway, I’m glad to have it finally out there! Feels good. Expect to hear more about it as January (and the year) continues.

Advertisements

Ludum Dare 25

My Final Year project has ballooned somewhat from a relatively simple idea to make an open-source game, to the considerably more complex idea to create a game framework for others to use. I’m not upset about this, though. I’ve discovered I really enjoy playing about with the bits that people will use to make games.

Last weekend was the 25th Ludum Dare competition. It was also, on Saturday, the time of my last exam this semester. So, as tempted as I was, I did not start a Ludum Dare game at 2am on Saturday like many other participants. I told myself that if the exam went well, and if I could make the current pre-alpha build of the library separate from the main sample game, that I would try to knock something together.

As it happened, the exam did go rather well. After some recovery time, that evening I sat down, without much hope, to try and extract the framework from the game without breaking it. Two hours later I had it working from a separate folder, and it wasn’t even close to bedtime. ‘I guess that’s it’, I thought. ‘I’m finally making a go of Ludum Dare.’ Armed with a couple of uncaffienated beverages and some paper, I set to work designing a game to fit the theme of LD25: You Are The Villain. At first I struggled, but then I had a flash of inspiration: a packet sniffer! It was simple, could have malicious intent, and could be gamified using the vector graphics style my framework revolves around.

Thence came IdentiThief, a game that took me about twelve hours of work and vindicated many of the niggling suspicions I had about the framework’s design, as well as highlighting a few new ones. Nevertheless, I was able to see my framework through the eyes of a developer at last, which was very valuable indeed. I went from concept to full design to first prototype in a matter of hours, and that was a lot of fun. At the end, I even had time to work in a separate menu and game state, which I have never done before in Pygame, let alone in my framework. I had to hack it a little to make it work, but it will definitely be a feature now.

All in all, I had a great time and gathered (somewhat) useful data on how I could improve my framework. Not to mention, I made a game in a day! Not too many people can say that.

Achievement Unlocked: Ethical Game Design

As game designers, is it our responsibility when someone spends more time than they want to on a videogame?

It’s a common enough occurrence in this world of social game systems like Raptr and TrueAchievements. Someone buys a game, and straightaway fills their Twitter and Facebook feeds with their journey towards completing every single little challenge in that game.

Achievements, for the uninitiated, are meta-medals that are associated with a player’s profile across multiple games. They are earned by completing small or large challenges in the game – or at least, that is how they were designed. The best achievements record things that players might do just for fun – to see if they can. Today, the effort required to get an achievement is approaching rather silly extremes. From the ‘turn-on-the-console’ achievements, which reward you for starting the first mission or shooting your first enemy, to the achievements which require literally hundreds or thousands of hours of play. An example of the latter is the now-infamous ‘Seriously…’ achievement from the Gears of War series. Here you can see the Seriously 2.0 achievement from Gears of War 2. This achievement requires you to kill a hundred thousand enemies.

Anybody who is of an obsessive frame of mind – and some gamers certainly are – might waste incredible amounts of time trying to reach this goal, way beyond the amount of time they would spend on the game if there were no achievements. I realise that designers want to encourage players to spend more time (and sometimes more money) on their games, but achievements like this are simply gratuitous.

I play games for fun. Achievements are fun in general, and some of them can be entertaining to strive for, but the pressure of earning every single one in every single game would drive me mad. And yet some people feel that pressure. As game designers, I think we have a ethical responsibility not to enable this kind of anti-fun idea. Not that I think achievements are bad, just that there will always be players obsessive enough to spend the time earning the silly ones like Seriously…, and that we should think carefully before adding such achievements to our games.

tile_puzzle: A Python tile puzzle emulator with simple solver

During the last couple of months I have been attending a module on artificial intelligence and machine learning in games. One of the basic algorithms the course looks at is the best-first search for making in-game decisions such as the next move in chess. In class, we used A* search (finding the shortest possible path from one node to another – an extension of best-first search) to solve a puzzle like the one below – a selection of sliding tiles in a housing that allows for one tile to move at a time.

A 15-tile puzzle with 16 spaces, also known as a fifteen-puzzle.

Beginning with a scrambled (but legal) board state, the algorithm uses a heuristic to assign values to every possible next state, puts them in a list of open states, and then picks one of those states to move to. Then it does the same thing again, adding new board states to the open list and already-used states to the closed list. This continues until it has reached a predefined goal state – in this case, the start state. The heuristic takes into account not just the closeness of the state to the goal, but also how many moves it took to get to the state. That is what allows it to find the shortest path every time.

I liked this algorithm when I heard it the first time, but it wasn’t as clear to me as I would have liked. This time, I decided to make sure I understood – by implementing it in real code. I began with emulating the tiled board. The board state is simply a two-dimensional list, which is generated in the start (or goal state). Random legal moves are then made on the state to generate a random, legal, board state.

The other part of the program is a solver, which creates an instance of the board and randomises it. Then it uses the algorithm described above to attempt a solution. I say ‘attempt’ because even at the 15-puzzle level, complicated board states can take more than a few hours to solve. The 24-puzzle is considerably more complex, so I don’t even consider it here, although the code will work for a square board of any size from two upwards.

I enjoyed this project because it was fun to use Python in a new context – solving heuristic problems. Previously I had only done this with Java. I learned a lot about how A* algorithms work, and got some experience with designing for general solutions. I designed the code to work with any size board, and made it possible to solve different problems using the same solver.

The code is available on GitHub. Below is a fairly simple execution log of a 24-puzzle with 20 random moves on it.


Size: 5
Random iterations: 20
Randomising: 20 iterations
Tiles out of place: 11
Isolated moves from goal state: 39
1
2
3
4
5
6
7
8
9
10
Found it after 10 moves
Total children added to open list: 21691

| 1| 2| 3| 4| 5|
| 6| 7| 8| 9|10|
|11|12|13|14|15|
|16|17|18|19|20|
|21|22|23|24| 0|

| 1| 2| 3| 9| 4|
| 6| 7|13| 8| 5|
|11|12|18|14|10|
|16|17|19| 0|15|
|21|22|23|24|20|

| 1| 2| 3| 9| 4|
| 6| 7|13| 8| 5|
|11|12|18|14|10|
|16|17| 0|19|15|
|21|22|23|24|20|

| 1| 2| 3| 9| 4|
| 6| 7|13| 8| 5|
|11|12| 0|14|10|
|16|17|18|19|15|
|21|22|23|24|20|

| 1| 2| 3| 9| 4|
| 6| 7| 0| 8| 5|
|11|12|13|14|10|
|16|17|18|19|15|
|21|22|23|24|20|

| 1| 2| 3| 9| 4|
| 6| 7| 8| 0| 5|
|11|12|13|14|10|
|16|17|18|19|15|
|21|22|23|24|20|

| 1| 2| 3| 0| 4|
| 6| 7| 8| 9| 5|
|11|12|13|14|10|
|16|17|18|19|15|
|21|22|23|24|20|

| 1| 2| 3| 4| 0|
| 6| 7| 8| 9| 5|
|11|12|13|14|10|
|16|17|18|19|15|
|21|22|23|24|20|

| 1| 2| 3| 4| 5|
| 6| 7| 8| 9| 0|
|11|12|13|14|10|
|16|17|18|19|15|
|21|22|23|24|20|

| 1| 2| 3| 4| 5|
| 6| 7| 8| 9|10|
|11|12|13|14| 0|
|16|17|18|19|15|
|21|22|23|24|20|

| 1| 2| 3| 4| 5|
| 6| 7| 8| 9|10|
|11|12|13|14|15|
|16|17|18|19| 0|
|21|22|23|24|20|

| 1| 2| 3| 4| 5|
| 6| 7| 8| 9|10|
|11|12|13|14|15|
|16|17|18|19|20|
|21|22|23|24| 0|

Did it in 10 moves.

JustEvasion

JustEvasion is a game that I developed in 2011. I wanted to make a simple game to keep my programming hand in over the long summer months. I developed it in C++, using OpenGL and the freeglut library. I was relatively unfamiliar with C++ at the time, but I had some sample freeglut code to learn from. The low-level nature of the libraries made some features quite difficult to implement, but it was a very good learning experience for me.

JustEvasion is a game in which the player moves a star shape around the screen. The star is chased constantly by circles, which use an extremely basic chasing mechanism. As such, the circles often line up or overlap as they attempt to reach the player. Players score points by effecting these overlaps. When two circles overlap perfectly (so that only one can be seen), one of them will disappear and the score will increase. If there is more than one overlap happening at once, the player gets a combo bonus.

I had JustEvasion working to this specification within a relatively short time, and I wasn’t sure what to do with it next. Some time later I was investigating Adam Saltsman‘s Canabalt, a very entertaining one-button Flash game.I discovered that the library he used to make the game, Flixel, is open-source. It is possible to develop a full game using only Flixel and FlashDevelop.

I was very excited about Flixel, so as a first project I decided to remake JustEvasion as a Flash game. Although I had made JustEvasion open-source on Google Code, almost nobody I knew had been able to play it because of its dependence on system configuration. A Flash game could remedy this, and allow everyone to at least try my game.

I started by reimplementing all the features that JustEvasion had, then started to add new ones, like a high score cookie that is stored on the computer for the next time you play, and different behaviours in the enemies. The development in ActionScript3 was slow at first, because I had limited Flash experience before, but once I grasped the differences I made progress quickly.

This slideshow requires JavaScript.

JustEvasion was a landmark project for me. Being able to publish a game in a medium everyone could understand and play made for a great feedback loop. Catching bugs was a lot easier with ten or fifteen people trying each build. It also boosted my confidence in my own abilities.

Zeouterlimits's Blog

Just another WordPress.com weblog

Smaointe Lambo

Lambo's thoughts on Lambo's intrests.

Colm's Blog

Full of games, programming and overblown opinions

jester252

Just another WordPress.com site

xtremesolutionsie

Just another WordPress.com site

Project Management Blog

Learning in the module

Paul's Plethora of Peculiar Posts

Here be dragons (made of bad jokes, puns and weird imagery.)

Sophie O'Gara's blog

Creativity shall make dreams soar

Les Divagations d'une Jeunesse Imaginative

The ramblings of an imaginative youth

Phil's Blog

A blog about Philip and his opinions on Video Games, Art and just general Navel Gazing

Conor Murphy

Not sure if you know this but, I’m kind of a big deal

Some general vizardry

A novice programmer's musings

andruQuinn

Problem solving in programming. A blog to give new views into problem solving

Player Two

Ludology from a developer

William Laffan

A Portfolio blog

Not Your Blog

Let's go in there and take out that dragon!

LukesDevBlog

Gravity-It's not just a good idea, it's the LAW!

wi11iamcb

The quite mutterings of a madman