About time!

I’ve been bogged down with tonnes of academic work over the past few months. Lots of assignments, lectures to attend and my on going third year project. As a result StudioFortress has been on the back burner for a while with the odd minor update.

However it’s now the end of term so that’s changed. Over the last few weeks Space Snake has been getting a lot of plays from visitors via SuperLand.de, a german blog on games. It’s still easily my most popular game, so I’ve finally found enough time to add a feature it’s needed for ages. Highscores!!!

space_snake_highscores

If you go and play today you’ll find the various death screens have been replaced with new ones where you can type in your name and submit a score. A minor improvement in the grand scheme of things, but I personally think it makes a big difference for this game.

Concurrency links

Currently I am in my fourth year at university, and for that year I am building a highly concurrent game framework in Erlang as my final year project. It’s a nice language that can potentially handle millions of processes, but in practice only 10′s of thousands on a standard home PC. I’m aiming to try to see if you can easily split a game up into thousands of parts that will automatically scale with the number of CPUs your using.

But this post is not about my project. Whilst doing some background research online I’ve found several nice articles and slides about concurrency in games. Here is a compiled list of my favourites:

Background

Game Benchmarks : Part 2: How Many CPU Cores Do You Need
This is the game benchmarks page from a Tom’s Hardware Guide article on how many cores you need to run apps and games. On average 4 cores only give a 0.6% increase (for games) over 3! So concurrency is clearly a problem, today.

Gamasutra Features : Multithreaded Game Engine Architectures
Three concurrent alternatives to the common game loop. I’m personally building the third architecture for my framework.

Info

Designing the Framework of a Parallel Game Engine
An article by a developer at Intel who has designed a highly concurrent game framework. A long but interesting read on how he has achieved it, and probably the best link on this page.

id Tech 5 Challenges, from Texture Virtualization to Massive Parallelization
These are some Id Software slides about some of the technologies they have built behind their upcomming game Rage. As a part of it they have built a Job based concurrency model where all of the games tasks are split into generic Jobs. At the same time they have a thread pool taking the Jobs and running them.

Tim Sweeney Slides

For those who don’t know, Tim Sweeney is one of the founders of Epic Games and worked on the Unreal engine. As someone who works on one of the most popular engines used for games, these slides are a great insight into what we should be seeing in the not-so distant future.

The next mainstream programming language
Some of this is about concurrency, however a large portion are also ideas on how functional languages could increase the code quality of games and game middle wear if used over current languages.

The end of the GPU roadmap
Very interesting set of slides on how the work inside games will (in Tim Sweeney’s eyes) be split up and parallelised in the futrue, and some of the potential speed ups from doing this. I like how the main emphasis is about underlying technologies that will do this for developers, leaving us to just handle building the games.

Valve

GDC 2007, Valve making Source multi-core
This is a more low-level set of slides on concurrency additions to Valve’s Source engine in 2007. It mainly covers a few key points about the importance of lock-free algorithms.

Multi-Threaded Challenges in the Game Space, a Conversation with Tom Leonard of Valve Fame
An interview discussing the ideas and issus behind the Source engines concurrency support. It mainly goes into why they have chosen to implement their libraries themselves rather then re-using existing libraries.

The SF Library

Today I uploaded the first technical demo for StudioFortress, Twilight. It’s a small implementation of a the Boids artificial life environment, and it’s also the first public demo that uses the latest version of my new library. The SF library.

I’ve been slowly building it over the last year and an early version is used for first 5 games on StudioFortress, but this version is built with the aim of distributing it soon. There is a big difference between building something for personal use and building it to production level. When released it’s going to be hosted as an open-source project on Project Kenai with my technical demos as examples. Others can then use and contribute to the library as they see fit.

There are however lots and lots of free game libraries for graphics and middle wear out there, so how does mine differ? First it’s aimed solely at rapid development for small 2d games. Second is that I found it quite difficult to find game libraries that did more then just graphics plus a few utility classes. There are some out there for Java, but they don’t quite do it how I want it. It’s more of a framework then a library designed to give you a structure you can use for all of your games.

More information will be released later closer to when it’s uploaded.

Painting

I’m about to go back to university to finish my degree in Computer Science. But before I go my mother had offered to make me a painting of anything I want, anything of my choosing. I very quickly knew I’d want to have the painting from a game, but which? Then it hit me, I’d take the image from one of my favourite all time games.

Here is the resulting painting…

… and the original …

I think it’s a very good job, especially considering how difficult a dark image like that is to copy. Can you tell which game it’s from?

Testing… Testing…

Welcome to my new blog: \o/ WOOOOOOOO! \o/

This is going to be a place where I will post various articles, thoughts, plans and general tid-bits that I write in conjunction with my site, StudioFortress.com.

To start I’m going to talk about ‘what is the point of StudioFortress?’. For a very long time I’ve been interested in game development but like many indie developers I have awesome ideas that get partly implemented and then just get passed around to a couple of friends (at most). I’ve always offered lots of advice on making games, but this is hard if you have nothing of your own to back it up (or more that you have nothing online to back it up). So the sites first aim is to be a place to host all my finished content. By building up a place with regular visitors exclusively showcasing my material; it helps to motivate me to show off all my work at a complete standard.

Note that last phrase ‘complete standard’. With StudioFortress setup and in place this is my second goal, to get projects finished. Not just so that the main gameplay is built and they don’t crash, but to a basic standard expected of any game. This is the 80% of the work that goes on top of the game to polish the graphics, sound, music, titles, endings, credits, splash screen, banners, instructions, high-scores, saving, multiplayer, player progression and much much more. Admittedly I haven’t added all the features listed in the previous sentence, but I intend to eventually add most of them as standard to all my titles.

Finally I intend one day (hopefully not too far away) to be producing games commercially. StudioFortress is my CV, resume and demo reel to show off my work so far: “You want examples? StudioFortress.com!” A ground work I can use to start building my own career or business on top.

But most of all, I hope people enjoy the games!

Joe.