• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
  • comments
  • views

About this blog


Entries in this blog


New Project Announcement

I've been working on a fencing game for the last few months with a friend of mine. Its coming along nicely. We hope to have it finished during the summer, but we're close to having an alpha of the primary gameplay, perhaps by the end of the month.

I thought I'd get time to work on the programming language tutorial set, but my energy has gone into this and I thought better than producing some half rate work.

About the Game

My friend Sean is the lead designer (being a fencer!) and also doing almost all of the art. I'm doing most of the programming, and acting as a sub-designer of sorts. It is interesting work, particularly writing game AI which I've never done before.

The game is quite simple. It is round based, you can attack, block and sprint. You can play against a friend using an XBox controller or play against the AI. For the full game we want to make a tournament system, where you control a team of fencers who will have different statistics. Winning will be partly about pairing off your fencers against the opposing team in the correct order as overcoming the individuals in the interactive fights.

Here is a quick video I made of the current gameplay. This features a bug (which has since been fixed), where the screen declaring the winner appears instantaneously and doesn't tell you who won.



The rounds are reasonably quick, it gets tense and more fun towards the end when you have only a couple of rounds left to go! The AI can be really mean, it does this thing where he can step back one pixel away from your attack, and then step in a pixel and hit you. It is also quite non-deterministic, but we're thinking almost too much so at the moment.

We Need You!

What I'm hoping for is a few volunteers for testing the outcome of our next iteration. This will be primarily to get feedback on the gameplay, but also an initial test for deployment, performance issues on strange machines, etc. I've never deployed a C#/XNA game before so I hope it won't be particularly tricky. What would be really great is if we could get someone who has an XBox controller they can use with their PC to try out the multiplayer for us.

Let me know in the comments if you are interested.
I'm just cleaning up the code for the first article in my planned series. In particular I scrubbed C++0x from it, because not everyone will support it.


I'm debating on whether to add extensive comments. I intend for this to be aimed at people who know C++, but the question is how well. I make liberal use of the standard library data structures and algorithms. I'm planning on keeping it a mid to high level discussion of the various problems and my solutions to them. I do plan to discuss the implementation itself but not in exhaustive detail.

Publishing Schedule

I think it will be worth taking some time to write up this base code, as it presents the foundation of the rest of the series. It is simple enough. For the moment, I support number literals and functions defined in C++. There are a small set of functions predefined, including the basic math operators and a print and println function. A function can be passed to another, but this isn't particularly useful yet. It does allow one to implement a library function like std::accumulate(), where the operation to be run is specified as part of the data. I'll probably have to split the initial implementation into three or so articles to keep them short and readable.

Implementation Stuff

So far I've implemented a simple value based system, everything is passed and returned by value. Functions are hard coded at compile time. This means that multiple invocations of a function will incur copies. This is fine at the moment as a function is just a string and a function pointer, but when I move to support user defined functions I don't want to be needlessly be copying them around.

The current implementation merely starts a REPL interpreter. There is no support as yet for loading from a file or any command line parameters at all.

Show me the Code!

The code is available on github: https://github.com/rip-off/rasp-lang. I haven't put in a build system or committed the Visual Studio project files as yet. I'm testing it on Linux too, so I'm not sure how I'm going to do that just yet.

There has been a lot of interest on the forums about creating custom programming languages. Since I have done this, I was thinking of doing a semi-retrospective, semi-rewrite to illustrate how to build a working programming language interpreter. I was considering doing this for quite some time, but I didn't quite have the motivation to do so.


I'm going to start with a basic Lisp syntax, using a hand rolled parser. Integrating a proper parser is a hurdle that I don't want to place too early in the process. I do plan to do it eventually so I can use a nice custom syntax. Most of my initial effort will be concentrated on getting the interpreter up to scratch. Its working title is "Rasp", which is an ugly mix of my user name and "Lisp".

Type System

I haven't tied down all the details yet, but I'm aiming for a semi-dynamic language, with optional explicit but otherwise inferred strong typing. That is, a function can be written without mentioning types. If a variable are used in a context where the type is known (e.g. passed to a library function or explicitly typed) then the type will be inferred and an error occurs trying to invoke the function with an incorrect type. Types will be be inferred recursively, so a generic function calling a second generic function which calls a typed function will have the types propagated all the way back. In certain circumstances, I expect the type will not be deducible. For the moment, I'm going to do something similar to "autoboxing" where in such cases the program will generate type errors at runtime rather than compile time. A variable would be strongly typed, once given a type (explicitly via declaration or implicitly through first assignment) it would not be legal to assign it to an unrelated type.

Some or all of these ideas might be compromised if they end up contradicting each other, or if they overly complicate implementation or finally if they just aren't nice to use. In any case, almost none of them will be present early on. Hopefully it won't be too difficult to add them later.

Advanced Topics

Some of the more advanced things I'm interested in investigating are automatic type decomposition to enable "data oriented programming" without imposing a large burden on the programmer, or possibly an explicit way of separating the physical arrangement of the data from the logic arrangement, to put the programmer in charge of their data layout. Other ideas include a hybrid approach to memory, using RAII where possible and garbage collection only where cycles can occur. I think the type system I'm considering might cause the compiler to be unable to infer a useful type, it would end up inferring something like "Object" in managed languages, though I'd prefer to omit such an arbitrary base class from the language if possible. To achieve this I may be forced to use explicit types when defining data types. I'll need to investigate.

I'd also like a language that helps programmers with multi-threaded code, or at least doesn't hinder them in quite the same way that other languages do. The plans I have for this are more nebulous at the moment, we'll see how it goes. Maybe something like language support for transactions, which can be rolled back and made a critical section.

I'm also thinking about an alternative to exceptions and error codes, or possibly merging them together - for example: checked return codes, the compiler will reject code that does not test the return value of marked functions. Investigate some kind of language support to ease the burden of passing error codes through a function call hierarchy, which might be aided by the inference engine I'm including. We'll see.

Long term goals include optimising the implementation to the point that people might want to actually use it, and eventually JIT compilation using LLVM. I would consider targeting a prewritten VM but it don't think it will allow me to get to some of the juicier advanced topics.

Coming soon

But the first few iterations will be very simple. I threw together an interpreter yesterday using my old "Lisp" project as a base. It lacks a parser. I'll get something simple working for the weekend, during which I hope to publish (or at least write) my first "article". I am currently testing it by building a raw instruction list and executing it. The first iteration will support integer literals and calling arbitrary C++ functions, hopefully even in a nested manner.

I started from scratch, not because I want to but because that is the best way to demonstrate the iterative process over the series of articles. Even stripped down to quite basic functionality, the base code is not small. I believe it is about the smallest useful size that will give me a good bit to talk about without being overwhelming. Hopefully it will be about the size that my intended audience can manage.

I know I can get it to the point where my last Lisp language was, which was reasonably powerful but with glaring omissions, notably user defined types. I should be able to get a few articles out until that point, then I can start braching into some of the topics I mentioned above.


The main complication is that my time is divided because I'm working on a game with a friend at the moment. We're getting close to a potential test of a gameplay mockup, we're aiming to have the program ready by the end of January and possibly conduct some tests in the months following.

Stay tuned,
-- rip-off

New game idea

I've had an idea brewing for some time for a new game. It is roughly like Civilisation, but more abstract, hopefully simpler and with a few ideas of my own I'd like to try out. I'm aiming for a proof of concept at the moment. So I'm not going to worry too much about the non-military aspects of such games. Diplomacy, economies and other such mechanics will come later, if necessary.

The basic idea is a space conquest game. This has definitely been done before. You have planetary systems you can conquer, and you build fleets using them and conquer more. There will be a simple galaxy generator that might populate 50-200 planetary systems (depending on the scale you might choose).

The abstractions are just removing lots of special cases. In most similar games I've played, you can build a wide variety of units (often accompanied by a varied research tree). I intend to replace this with a simple power/disposition system. Basically, variable statistics. So a particular fleet might have an offensive or defensive disposition, or neutral. It might have a fast or slow disposition, or a heavy/light one. Some statistics might be naturally exclusive, for example I might disallow fast/heavy dispositions. The power is basically a combination of the size, disposition and relative technology levels.

It will be turn-based, but each turn will be divided into two phases, decision and simulation. Orders are given during the decision phase. The combat is resolved in the simulation phase. I also intend combat to be a multi-turn process. Planets are captured by laying seige to them for a number of turns. Two armies facing each other will do damage based on their dispositions, only if at least one is in the aggressive disposition will notable combat take place. Two fleets both engaged in an offensive stance should be resolved fairly quickly, with victory mostly based on the power difference between the fleets. If one army is neutral and another is aggressive, the neutral fleet might fall back rather than take excessive damage in a single turn.

The inspiration for some of the interesting ideas come from recently reading The Forever War. I really liked his description of the implications of relativity on interstellar combat. One simple example is that the human space craft travel to the enemy space that a long time has passed for the aliens. This means that the humans are facing technology which literally didn't exist when they set out. I don't believe I can replicate the ideas in the book exactly, but I can offer mechanics which have similar effects.

It will obviously be necessary for fleets to travel faster than light. My ideas are still forming, but one is to drop the relative technology levels of fast moving fleets (in the absence of logistical support perhaps). Another might be to allow the enemy players see the fast-moving fleets from further off. This is obviously artificial - the speed of light forbids this, but this is a game! The point is to design a mechanic

Another idea is to make the galaxy change over time. So the planetary systems will rotate around the centre of the galaxy, but also around each other. This is partly the reason for a separate simulation phase. While individual star systems might have little effect on one another, galactic features like black holes and globular clusters might have noticeable local effects (which I will probably exaggerate for effect). I might simplify the gravitational interactions by grouping areas that are close together. Getting this to work will be the main technical challenge I believe. I will probably have to simulate thousands of non-populated star systems to give the system some stability. I would have to at least draw them anyway to create a nice background effect to give the impression of a galaxy. I'll have to generate stable galaxies, where very few collisions will occur over the lifetime of the game. In particular, care must be taken to avoid the entire galaxy collapsing toward a single point. If it is infeasible to simulate gravity, I might just go for a very simplified system where the different star systems rotate around the centre of the galaxy at a fixed rate. But because different star systems rotate at different speeds, the same dynamic galaxy will be created.

My experience with the critter game taught me that I've a lot to learn about game design. This will be a huge test for me. I don't know if I can make a good strategy game in a ever-changing world. It sounds like an interesting idea, so I am eager to try it out and see if it is any fun. It sounds like a bit of a nightmare though, you have to plan X turns down the line when your planets and ships are all in constant motion. Add to this the various real and theoretical/imaginary interstellar features that can be included, the aforementioned black holes and globular clusters, but maybe supernova, wormholes, nebula. I will include anything that has a bit of character, and can act as strategic key points. I'm not too concerned about realism, I will scale any feature to fit the game, even if it doesn't really make sense. I might even include new ones, such as massive objects which have an inverse effect to gravity. These might be pre-populated features or might be created by the users, I'm not sure yet.

I don't look forward to writing AI for such a system though! I expect it will be hard enough for a human to meaningfully plan ahead in such an dynamic environment. The interface will present a challenge. For example, if you order a fleet to move to a point that will take 10 turns, should that point be relative or absolute? Did the player want the fleet just to approach the galactic core, or did they intend that it end up close to a particular resource of interest. The strategic value of certain areas will change over time as they move. A once important planet might end up moving to the wrong position and become isolated and useless. This could feed into the economic system in the long term, if I take it that far.

I've only barely begun work on this project. The working title is "Conq". This post is intended as a roadmap for future development. At the moment it is a top-down 2D game, but when I look at video's like the Infinity Game Engine by Ysaneya (included below), I keep thinking how cool it would be to do this in 3D. Imagine a fleet surprise attacking - from perpendicular to the galactic plane!

">Infinity Video

UFEC pre-results

The deadline for UFEC feedback is tomorrow. Hopefully that means the results will be available shortly, perhaps before the end of the month depending on how busy Lesan is.

Giving feedback on other peoples games is hard. Being game developers, we all know the trials involved, the hacks, the programmer art, the frantic cutting for impending deadlines that seem to come at just the wrong time in your work and/or personal life.

Overall, I think I was reasonably fair (but then again I would, wouldn't I?). All the games had positive sides,

I think that fang's Lord of the Elementals was the best of the bunch. A good and original idea, tied in well with the theme and polished too. The only complaint would be that the AI is too simple, once you understand the game it is too easy to win. Some proper AI, or a network play mode, would add some much-needed challenge.

I believe ne0_kamen's Forest Defense was the next best. Tower defense isn't too original, but I really liked the sound of the ideas in his thread, they seemed to play off the elements very well. However, the delivered version didn't quite live up to some of the more interesting ideas (a pain I know all too well), but the gameplay is solid enough. The main weakness is the variety, which is apparently been tweaked in his latest version.

Erik Rufelt's Origin of Aliens is a fun game, but a bit too unfinished, with some difficulty issues (which may be as per design) and some stability ones (which probably aren't part of the design). The elements were weaker than the other games, I thought.

I had high hopes for XDigital's Cycle, I even helped produce a Windows executable, but unfortunatly I found the game unplayable. This might have been a bug in the Windows port, but the game doesn't provide enough feedback to enable strategy, I ended up just clicking randomly because I couldn't tell the state of the board. I imagine it is similar to being taught to play blindfold chess, without first knowing the rules of chess. The game certainly looks like it had a lot of work put into it, so I would like to play an improved version if it becomes available. If the quality of the loading screen and menu art is anything to go by, there could be a good game there.

As for my own game, I don't know what to think. The elements came out a lot worse than I hoped. The polish just isn't there. The gameplay was still in flux, and its actually quite a messy game to play, too easy with spikes of insane difficulty. The graphics were ok, but inconsistent. The sounds might be the strongest part, given that no other games included them!

I hope to get some interesting feedback. I'm a solid programmer, but I don't have much experience in game design, and it definitely showed. The opinions of others could be vital for my next project.

I have some similar sized projects in my mind, but I think I might let them ferment some more. I might do some rapid prototyping of small games for my next project or two.


I "finished" my game for UFEC. I've spent the last couple of weeks frantically crunching trying to get it someway reasonable, so even though I posted it a few days ago I'm only now getting around to writing about it.

I've mixed feelings about the situation.

Primarily, at the time I was quite annoyed at how poor the game turned out, it need a lot more balance and polish. There are some odd little bugs in there that I simply didn't have time to track down or weren't too important.

With the benefit of a little break though, I'm quite happy with it. It isn't finished, and I will surely come back to it in the near future to take it the whole way, but it contains the essential ingredients that I was hoping to include.

Its reasonably fun to play and looks nice in motion, even if the graphics could do with quite a bit of tweaking.

I've learned a lot too, I had never really designed a game before, and it definitely shows. I left all the gameplay decisions until too late, being more of a programmer I concentrated on getting most of it built rather than prototyping the core aspects of the game. Though I am pleased with the code, not too overdesigned yet still in good shape despite the epic hack-a-thon trying to get it done.

The "levels" were all thrown together at the last minute. While I sketched them out before making them, they were in no way designed and were more of a show case of most of the stuff I had done, in no particular order. The rather weak "level editor" is possibly another cause of this, all it allows is the placement and deletion of obstacles, its quite hard to "tweak" levels because you cannot move the pieces of terrain around.

There were some nice surprises. My totally unoptimised Java code, running immediate mode OpenGL and using a native Java physics library that I believe defensively copies Vec2 instances when you read them performed admirably, at least on the two machines I tested it on. One was a laptop with a graphics card that didn't support power of two textures, so I assumed the hardware wasn't great.

Its fine to talk about Java coming close to native languages in theory, but its quite another thing to see it actually happening. I'd really like to try it out on a wider range of hardware to see how it performs. Maybe I would be disappointed though [smile]

Download link

Feel free to leave any feedback in the comments, or you could use the UFEC thread for the game.


The deadline for UFEC approaches rapidly. I may not have sufficient time.

I have so much to get done, I have to take a clincal approach to my TODO list and cut anything that isn't necessary. I'm just hoping there will be enough stuff left to leave a fun game.

One of the UFEC elements is fire. I've put in a simple rendering technique that makes decent looking fire, but I'm not sure that it will suffice. The entire game is done in immediate mode, combined with rendering not a small number of particles I'm worried that the game will perform well on slower systems than my dev machine. I have a simple optimisation that could speed it up a lot, but that would require time to write and test that I'm not sure I have. Water rendering and handling is something I'm hoping to do today.

Input is a huge concern. The game game feels awkward to play at the moment. I really want to have a mouse only interface, but it is tricky. The problem is that I can reduce the number of actions that the user might need to perform at once to three, but that means relying on the middle button, which never really feels comfortable to hold on. Holding down the button is an essential part of each of the three actions - pan camera, select critters and "apply current mode".

The current modes are currently "proliferate", "evolve" or "attract critters to mouse". The really ugly temporary UI I have implemented for them will eventually be usable by clicking on the icon of the action you want to perform, with shortcut keys available too.

My evolution element is very weak at the moment, I have evolved types but they act pretty much identically to the "default" critter type. They are drawn a little different, but not even *that* different.

Some of the other things I was working on is getting levels to transition and keeping the camera inside the bounds of the map. I also worked on giving feedback for when a critter is injured, they flash red briefly. I still need to add some visual cue for how healthy a critter is.

Some more good news is that I've broken my level editor mode (which I haven't touched for a while). I'm going to have to design some levels for this game, which I'm not feeling confident about. Hopefully it won't be too bad.

This week is probably going to be crunch mode. I'm considering taking a day or two off work coming up to the deadline to try get this done. I'm just hoping that my enthusiasm holds steady. And perhaps my sanity.

">video featuring some of the changes I've made.

Critter Game Update

I only finished a bit this week, I ended up doing less than I had planned. If I am serious about finishing this in time for UFEC then I need to step up development a lot. I hope to get a good bit done this weekend.

What I did get done though was some code to allow me to play some sounds. I don't actually have any sounds made for the game yet - I might put out a help wanted request for that. At the moment I just have a test application that use lwjgl's OpenAL bindings to place a few sounds relative to the listener and play them. One of the sound loops and moves around, just to test that too.

I also added in some code for allowing the critters to grow and split (a bit like cells). This will be the proliferation aspect of UFEC. You will have points, which will be obtained at reasonably regular intervals between some of the tougher obstacles. You can spend these points on multiplying your critters, or evolving them to give them special abilities. It is the latter that I sorely need to get working, hopefully this weekend should see the first one or two evolved types. There are some serious bugs with the proliferation code where two critters can get locked together, or a critter spawns around terrain. I will probably have to put additional collision geometry on the critters to make it work right.

I enabled the code that allowed the critters to take damage. At the moment they simply have their alpha value set proportional to their health, I will change this to a quick red flash when they are injured, and maybe they will look a bit grey when their health is low. I might also relax the springs a little bit, which might help make the injured ones look a bit worse for wear. If you use the proliferation action on an injured critter, it will restore their health before fattening them up or splitting them.

">Video of proliferation mechanic in action.

I also fixed quite a few bugs, nothing particularly hilarious though.

I will finish up by saying that I'm thinking of calling the game "Primordial Blues".


Good morning everyone!

I've been paying for GDNet+ for ver a year now, so it is about time I got around to using this journal dealie...

I'm working on a game, a potential UFEC entry, depending on how finished it is by the deadline. The gameplay will be somewhere between Lemmings, Fantastic Contraption and IWBTG if it works out.

Basically, you have to get a bunch of amorphous blob like creatures (currently dubbed 'critters') from the start position to the end of the level. There will be various obstacles and impediments on the way to prevent you accomplishing your goal. You can attract critters towards the mouse, guiding them but you don't have direct control of them. I may eventually include a mouse gesture based system to support command-verbs such as "leap" or "run".

Currently, the obstacles are more of a nuisance than actual obstacles. I will soon be adding a damage system, so the little critters will be dropping like flies if you don't take care of them.

I've uploaded a gameplay prototype to
">Youtube. Any comments are welcome!
Sign in to follow this