About nickd3000 (twitter: @physmo)

Art/Design Half of Physmo, indie game developers from Scotland. www.physmo.com


Ludum Dare 22
Ludum Dare 21

nickd3000's Trophies

nickd3000's Archive

Rambling Post Mortem – Fernands War

Posted by (twitter: @physmo)
Thursday, December 29th, 2011 9:55 am

Ludum Dare 22 Post Mortem
December 2011 – Game: Fernands War.

Pre-compo prep.
Last year I found out about the Ludum dare competition and was really interested in doing something, unfortunately I didn’t have the weekend totally free to commit to making any real attempt, but I managed to crank out a tiny little endless runner in a couple of hours and catch some of the live recordings (Notch’s one mainly). It was interesting to see the fruits of every-one’s labours, and the community spirit here is really inspiring.
So as I hadn’t managed to make a decent attempt last time, I had planned to jump in properly for LD22. In preparation I had made all the necessary requests for that 48 hour period to be free and started thinking about the tools I would use to make the game.

Physmo is a 2 man team, I do the art and design and @physmotone is the chap with the coding skillz. We had talked a bit about entering the jam as a team but were struggling to both get the time off we needed so I planned to enter solo. This meant coding the game myself; I am a programmer but I’m certainly no game programmer so I realised this would be tough. I’m sure Tony would be shocked by all the fundamental coding mistakes I made while making my entry, stuff he has the experience now to avoid, but I learned a lot doing this, especially about the architecture of making a game, the game states, resource management etc – all that tricky stuff we can take for granted sometimes.

In the week before the theme was announced, I decided I would choose Java as the language, and Slick2D as the graphics library for drawing the sprites (It also does a great job of loading graphics, sound and level data.) I’m not a java programmer but it seemed close enough to C++ to be easy to pick up, but mainly I wanted something that would be multi platform with the vague possibility of embedding in a web page (this didn’t happen). I didn’t know what kind of game I’d be making but assumed it might need level data, and I had heard of a map editor that was supported by Slick2D called Tiled, so I downloaded that and made sure I knew the basics of how it worked. In the prep week I didn’t find as much time as I would have liked to do actual prep but I did get a few hours to find some java tutorials and create a small test application that demonstrated loading and displaying sprites, loading and playing sounds and reading a Tiled level. I didn’t want to waste much of the 48 hours being stuck on some trivial problem like not being able to draw a font to the screen so I investigated the font libraries too (Angel code fonts I think it was). I had the small test app running, the final thing on my list of prep was to actually package the program to be runnable on other computers.
This was a couple of days before the announcement and I could not for the life of me package this thing properly. Eclipse is the IDE I was using and it’s pretty complicated if you don’t know it, and I had no idea about how to create Jar packages (which is what I needed to make the thing runnable). I tried every combination of including the platform specific .dll files, the library .jars for Slick2D and LWJGL, and did a lot of googling for the problem. Fortunately (?) many novices seem to have a problem with this step, and in the end I reluctantly tried using another app to package all of the files up into a fat jar, which worked. i say reluctantly because even though it worked in the end, I still don’t have a good understanding why it didn’t work and why it does now, but hey, it works! This was a real problem just before the compo started though. If I couldn’t find out how to package the game, there would be no point in working on a game. I would heartily recommend anyone taking part in a time limiting game creation competition to build a full app end-to-end before they take part.

The graphic and audio tools were to be Photoshop, SFXR (of course) for sound effects and Audacity in case I needed any sound effect editing. In the end I did install audacity in the final hour to tweak the ship thruster sound effect but that’s all.

I’m in the UK, so the announcement came at 2am our time. The plan was to stay up for the announcement, have a think about it and then get some sleep.
The theme is announced. “Alone”. I stare at the screen for a few minutes. My first thought is, “Well at least I won’t have to code any enemy AI”.
At Physmo we have a folder full of crazy game Ideas and prototypes, but we have never really considered a thrust style game. I used to like thrust style games though, and I though it would be within my skill range to make a good attempt at one. Quite soon after the announcement I had come up with some ideas for a decent plot – I wanted to have some narrative in the game that would be explained as you play and I really wanted to have a good twist in there too. I had my general story Idea and style of game I wanted, I could now sleep (and secretly hope to come up with good ideas in my dreams).

Oh, this post mortem is going to be a total spoiler for the game, so please play it first if you intend to… I’ll give you a couple of minutes, just watch out for the spinning sawblades, the collision on them is a bit saucy.

For the plot of the game, I wanted the player to have unwittingly done something really terrible. This idea made it into the final game but was very scaled back. The initial idea was that you would be flying a ship around a room with some kind of reactor in the middle, there would be a cage full of energy capsules milling around that you would have to pick up and drop into the reactor. At some point you would realise that this is not the true reality of the situation, the reactor is actually a horrible mind controlling alien, the energy capsules are really other human members of your crew and the alien has tricked you into feeding your crew to it.
This was the plan until the end of day one, I didn’t think I would have time to code the mechanics for all this, the switching level graphics, picking up and dropping the crew etc, so at the start of day 2 I decided to change it slightly so that you were a security guard of a mining colony, who was going mad. It seems like at first you are being attacked by aliens, but as you progress through the game you can read log files that gradually explain that the aliens are really just the colonists, and by the end of the game you will be alone, having killed them all. It’s nice to end on a cheery, up-beat note.

It was time to start programming. But first I went to my trusty Photoshop and drew some sprites: A yellow ship, some bullets, some white splodges to use as particles and a simple tiling foreground and background tile sprite. The spaceship made it into the final cut of the game with no modifications as I quite liked it. NOW it was time to start programming! First I needed some classes to represent the ship, bullets and enemies. That’s what the game needed, they are an integral part of the game. You can’t have a game without them. That’s why, like an idiot, I spent the first couple of hours making some pretty particle effects.
Ok, Basic particle engine created, I now really HAD to start creating the game objects. I found a nice tutorial about creating game entities, and then creating generic behaviours that could be inserted into them, this seemed like a cool Idea and one I had never tried before so I gave it a shot (I’ll try to link to these tutorials and things at the end of the post). After stealing the code to create the framework of the entities, behaviours and renderers, I derived my own object classes for them, starting with the players ship movement code. This was easy as I had used some basic maths like this a lot in some processing toys I made a while ago. It’s useful to know so I’ll write it out here:
Horizontal Thrust = sin(ship angle of rotation) * force;
Vertical Thrust = cos(ship angle of rotation) * force;
So everytime the thrust button is pressed, I add these values onto the ships velocity on the x and y axis. Every time through the game loop, I add the velocity vector to the ships position, and that moves the ship. And at the same time I dampen the ship’s velocity by multiplying it by a number slightly less than 1.0 (0.98 or something). That reduces the ships motion over time and eventually makes it stop in a pleasing way.

Ok, next big problem. In my processing (processing is a simple java-like programming language) experience, the main loop is locked to a certain frame rate, but in the Slick2D framework it isn’t. This means the loop runs as fast as it possible can – maybe hundreds of times a second – but it will vary from computer to computer and will vary depending on how much is being drawn on the screen too. To handle this, the update loops are passed in a variable that represents the number of clock ticks that occurred since the last update, and using this I could feed it into all the motion equations. Essentially, every calculation that results in something moving on screen needs to be scaled down by the number of clock ticks, so that the movement is nice and constant. I forgot to do this to the scrolling routine though so sometimes the scrolling can be a bit slow if your machine is struggling. That’s a bug but would be easy to fix.

I now had a ship swishing around the screen nicely, with lovely particles firing out of it’s bum (and me making “woosh” sounds) so I flew it around the screen for half an hour thinking how awesome I was to have achieved such a thing. Next I needed some background to be drawn. The Slick2D libraries can load and display level data from Tiled map files, although they couldn’t handle (as far as I could tell) drawing level sprites scaled up, but it was quite easy to parse through the loaded level file, find what tile is at what location and draw it scaled up myself. I got this running surprisingly quickly (well it wasn’t very complicated) and then added some scrolling offset code, and voila! I had a ship flying around a scrolling level. Flying right through the walls though. Next step was to detect collision on the walls, so I wrote a routine that given a point in the game world, would find the foreground level sprite, and check if the pixel was filled or not. It worked and that is the basis of all the collision in the game. To collide the ship off walls, I check around 10 points in a circle around the ship to see if they are touching a solid part of the background. If they are, i calculate the vector from that point back to the centre of the ship and add that to the ships velocity, I was amazed that this works but it resulted in some pretty solid feeling collision (I was worried that the collision would be awful in this game) so maybe this is what real collision is based on.
I created some simple behaviours for the player bullets that I reused for enemy bullets (The entity system worked well here) then I added some basic enemy types. I regret not having the time to make the enemies do more, but in the end I just had static enemies that varied in the speed that they fired bullets at you and the number of shots it would take to kill them.
I added a lot to the game in the last half day, as the main mechanics were there. Different sprites for the enemies, more particle effects and the log file objects that can be picked up. Some trivial looking things took more time than expected, for instance displaying the log file text on screen and making the rest of the game pause while it was displayed. At this point I realised I would have to start thinking about game states, so I changed the main class to be a state based game state using the Slick2D libraries and created another state for the main menu screen, then worked on getting this to transition back and forward and make sure that the player could die and the game would switch back to the main menu. This is something I wish I’d thought about a lot more at the start as game states are a tricky thing to to if you aren’t used to it.

Panic was setting in in the last few hours of the 48, there was a lot to be tidied up. The collision between bullets, player ship and enemies was quite off so I modified the renderers to display the collision box and that helped me track down and fix the issues there. One big problem that I regret not fixing is that the hit-boxes for the circular saw blades is a square, not a circle and this makes for some really unfair deaths in the game. I realised I had no time left to fix this so I modified the level to move the saws and give the player more room to move around them, still it’s disappointing to get unfairly killed by them.

The game was looking quite finished, all the log files were placed and the end could be reached, but it was quite hard, so at the last minute I made the players health slowly regenerate over time. In the last half hour I feverishly added a lot of minor details: The player health bar, more particle effects for killing enemies, more sound effects and a dodgy system for playing the ships thrust sound. Panicking further, I played through the game one more time and hit the build button to build the final Jar file, and opened slick jar (i think) to package it up into a runnable jar file. With minutes to spare I clicked the Jar file and it seemed to work, phew! Opened my web browser, and went to www.ludumdare.com …… wait a … WTF .. oh MAN! Why is the site not working! Through lack of sleep and burnout I thought all was lost, I refreshed the site and still nothing. Thinking that all was lost, I gingerly climbed onto the window ledge, and, oh wait, the site loaded! Wheee! Well, at least, I saw a message from the site saying they would accept entries for an hour or two after the closing time. I eventually uploaded the game and could relax, but those last few minutes leading up to the deadline were some tense minutes let me tell you.

In closing this rather rambling post, I did enjoy the experience. I think I made a decent, complete game that I hope you enjoy playing – it’s quite short. I’ve learned a lot about what should be prioritised next time, and I feel like I was part of something big and crazy 😀

Please try it, it’s called “Fernands War” http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=5349

We have a full game called Mos Speedrun too, for iPhone and Mac/Pc, you might like it.




Repackaged my game for Mac

Posted by (twitter: @physmo)
Thursday, December 22nd, 2011 8:13 am

Hi I thought I’d post a quick message to say I have repackaged my game “Fernands War” for Mac now as well as PC (it’s a java .jar file), you can see it here: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=5349

I didn’t change any of the code btw, just added the mac dll’s to the jar package so I think this is within the rules. Hope you like it!

gratuitous kitten shot (in the face)

gratuitous kitten shot (in the face)

Submitted, like a boss.

Posted by (twitter: @physmo)
Sunday, December 18th, 2011 7:41 pm

Sort of. Didn’t think I would cut it so fine but I worked right up until the last hour, then ran into scary server problems trying to upload the thing! Thankfully the upload deadline was extended and I managed to get it uploaded.
This is the first LD I’ve properly taken part in, and it was definitely an experience. I’m no game programmer so this was pretty tough, and I have learned a lot about how I will prepare for the next LD (program architecture, knowing the libraries, making sure you can build an executable etc :) )
I was surprised how fluid my game design was throughout the 2 days (by fluid, i mean I kept dropping features)

and I think it was a mistake to try and write particle/entity/level renderer/collision all in 2 days. I quite like the game I came up with in the end but sadly the code is so terrible that if I wanted to expand the game i’d probably have to rewrite the whole thing!
The game is called “Fernands War” – it’s a pixel art-ish thrust like thing with a bit of a story. If you play it, try to discover the story bits as i think it adds something to the game.

anyway, well done to all the fools who took part in this, even if you didn’t finish it’s good experience for the next time! 😀


Less than an hour to go,

Posted by (twitter: @physmo)
Friday, December 16th, 2011 6:21 pm

Less than an hour to go, hear the theme, then some sleep! (GMT :-/)

I’ve spent a couple of days trying to figure out java & slick2d so here are the source files that might make it into my entry – mostly just stuff cobbled together from tutorials I found though. Best of luck to all of you taking part!




Posted by (twitter: @physmo)
Wednesday, December 14th, 2011 8:49 am

The weekend is fast approaching… I’d be interested to hear any suggestions about how to quickly make some music during LD22, I think this is going to be a bit of a stumbling block for me :)


LD22 Prep

Posted by (twitter: @physmo)
Monday, December 12th, 2011 3:43 am

To be as ready as possible for this weekends LD, I’ll be kicking the tyres of my whole development process (as much as I can anticipate at least) So I thought I’d share my todo list of what I’ll be making sure works and also some stuff I’ll be learning about before the comp. Much better to do this BEFORE the day. Of course it’s a great idea to try making a quick game as preperation, but this list might help if you aren’t going to do that.

Check coding tools are set up, and you can import any libraries you intend to use. I’ll be using Slick 2D library with eclipse so I’ll be making sure eclipse keyboard shortcuts are set up like Visual studio (which I am more used to).
Check audio tools and make sure you can load and use output formats.
Check art tools are usable, especially stuff like sprite transparencies, animation, file formats etc.
If you might use a pre-made one, know how to use your level editor and be able to read in the map files.

Input/Output; Test and get familiar with:
Loading/displaying images.
Loading/displaying fonts.
keyboard and mouse input.
loading and playing sounds.

Try making an executable and be sure it runs on all intended platforms like PC, Mac, Unix.  If making a browser game, check that what you are trying to do will run in most popular browsers.

Algorithmic stuff:
Know how to use common structures in the language: lists, maps, arrays etc.
Be familiar with basic game algorithms: collision, movement, velocities, game states and transitions, sorting algorithms, calculating a velocity from an angle, calc angle between two vectors etc.

Check your screenshot/video recording tools if you plan to use them.

Anything I’ve missed? Good luck ! 😀



I’m/We’re in

Posted by (twitter: @physmo)
Friday, December 9th, 2011 7:23 am

I’m planning to join in the fun for LD22, either myself or with my partner in crime, Physmo Tone, in which case we’ll be doing the Jam thing.

Graphics will be done in Photoshop, code will be either Java or C++. (Or unity or javascript. Man, we need to plan this better 😀 ).  Sound will be SFXR (surprise!) or some free thing that can generate sounds (audacity maybe?).

We’ll do regular updates through development and hope to have something at least playable. Good luck all!



blue man cthulhu escape

Posted by (twitter: @physmo)
Sunday, August 21st, 2011 3:18 pm

I had a very limited mount of time for my first entry into Ludum Dare. Hence I submit this programming monstrosity:


there is a link to the code on the page. Please do not attempt to learn from the code: it’s terrible! 😀

code: processing [java]

graphics: photoshop

nick / www.physmo.com

[cache: storing page]