Week of Awesome IV: Initial thoughts

About a week ago I got the regular GameDev.net newsletter email. One of the items was an annual weeklong jam called Week of Awesome. My girlfriend’s away this week which means I can put in a good amount of dev time, so I’m entering.

Slightly ironically, I couldn’t access the account which the GameDev email was sent to so I had to create a new one for the forums.

The themes this year are Shadows, Evolution, Undead and Ruins. I’ve been working a lot of ray cast soft shadows recently (for my oblique project – see Twitter), so I think that’s a good starting point. Confusingly, or perhaps cleverly, Shadows is supposed to be a gameplay rather than graphical theme, but I think my shadows will give rise to unique gameplay, not just be a graphical feature. The scope of the Evolution theme is very broad, but nothing springs to mind so I’ll leave that for now. So I have to pick one of Undead and Ruins. A top down zombie shooter should work nicely I reckon.

Nothing clever with the themes this time, unlike with past jams. On Saturday I tried to take part in the One Hour Game Jam and learn Pico-8 at the same time. Unfortunately the theme was Mouse Only and Pico-8 doesn’t support mouse input, so my game was actually just a mouse on its own. The learning curve was a bit too steep to do anything interesting so I didn’t submit it in the end.

I will be using Monogame for the development, for reasons I’ve discussed in several previous blog posts. GameMaker would be ideal for this sort of rapid development, but I don’t think I could do the shadows as easily. I will be using a voxel map for the world, so I’m going to have to write a voxel renderer which I’ve never done before. That should be fun.

I’ll need to organise my code carefully, because working on it for even a week has the potential to get very messy and I can’t afford to keep refactoring and rewriting code.

Stay tuned for screenshots etc., on my Twitter and here.

Prince of Persia’s Parallel Projection

Prince of Persia (1989) uses oblique projection – the same as is used for furniture diagrams – to give a sense of depth to an otherwise flat 2D platformer.


The problem is that oblique projection, while it gives an intuitive depiction of objects, is not really physically possible, for say a camera.

To do any kind of realistic lighting of a game in this perspective, we need to understand how the light rays are received by the camera.

Read more Prince of Persia’s Parallel Projection

Pixel Art vs Pixel Perfect (Part 1)

In the early days of video games – ignoring Tennis for Two and the like – graphics were low resolution images using a very limited palette: first two colours, then 48 for the NES. The golden age of these hand drawn pixel art games, before the move to 3D games and digital painting, was arguably the SNES, which had 32,768 possible colours but could only display 256 different colours on a single sprite. The limited colour choice meant that smooth gradients were not possible, and colours tended to look blocky and contrasting. This, combined with the low resolutions stretched over a large tv screen, gave a distinctive art style where individual pixels were very visible.

Super Mario WorldSuper Mario World (1990), one of the flagship games for the SNES, before 3D games became the norm

Read more Pixel Art vs Pixel Perfect (Part 1)

Converting a GameMaker: Studio project to MonoGame (Part 3)

In Part 2 we wrote the Room class including the loader. Of course, I made a mistake in the code I hadn’t tested.
This line:

should be

I thought it checked the current namespace by default, clearly I was wrong.

Today, we’re going to write the code to draw and update objects, and we’ll start to implement the player object.

Read more Converting a GameMaker: Studio project to MonoGame (Part 3)

Converting a GameMaker: Studio project to MonoGame (Part 2)

In Part 1 we set up the solution for our game.

One thing I forgot to mention was that after importing room0.room.gmx, that too needs to have its Copy to Output Directory property set to “Copy if newer”.

Now let’s write some code.

Read more Converting a GameMaker: Studio project to MonoGame (Part 2)

Converting a GameMaker: Studio project to MonoGame (Part 1)

I recently changed from using GM:S for a game I’m working on to using MonoGame. There are a few good reasons for doing this, mainly to do with low-level control, and some performance improvements. There are many good reasons not to do this. A few that spring to mind are:

  • You use GM:S for the drag-and-drop coding
  • You’re not familiar with object-oriented programming but are happy using GML
  • You like the large and active community of GM:S
  • You use some of the advanced features of GM:S, like In App Purchases or Advertising
  • (Perhaps most importantly) Everything is fine as it is in GM:S

With all that said, MonoGame is a great cross-platform library, and for much of what you’d want to do there is an easy one-to-one conversion into C# with MonoGame.

Things which will be more difficult to convert include Time Lines and Texture Pages. I shan’t go into much detail on these, but be aware for the latter that your performance could be significantly worse if you use lots of individual sprite files rather than unified sprite atlases.

I’m going to talk through a conversion process for the Tile Based Platformer project which comes with GM:S. Hopefully for other simple projects the conversion is just as easy.

Read more Converting a GameMaker: Studio project to MonoGame (Part 1)

Which tool to make games with or: How I learned to stop worrying and love managed code

I think I’m at a point now where I can usefully discuss the problem of choosing the basis on which to develop a game. This summer I’ve been working on games in Unity, and in my spare time I’ve been using GameMaker: Studio. I also have several years of experience with XNA and raw DirectX and recently, MonoGame.

I started writing games in Flash a decade ago now, but desperately wanted to make 3D games. Back then, all 3D games were written in C++ or C. In fact, my first ever exposure to a full sized game’s code was the GPLed Quake II, which I modded. I assumed that it was only possible to make large games in native code, and perhaps it was even true then.

It took a while after this for it to dawn on me that for 2D games, one doesn’t need native efficiency at all, and if a game is running slowly it’s probably bad design than the tool you’re using.

This summer especially using C# with Unity, I was surprised at how efficiently I could run quite complicated games. Even on a low-end laptop, I was seeing a solid 60 fps on anything I wrote, as long as I put a bit of thought into how it would execute.

Separately, in the evenings, I’ve been working on a game with GameMaker: Studio. This was inspired mostly by the discovery that a lot of my favourite 2D games were written in GMS and a sudden desire to create 2D games from start to end. I suspect I will continue to use GMS for Ludum Dares.

However, GMS has some issues, after which I converted my game to MonoGame. I’ll go into more detail on that in a future post.

So, allow me to weigh up the pros and cons of various different game development tools. All this assumes comfort in switching between imperative languages.

Read more Which tool to make games with or: How I learned to stop worrying and love managed code