Python vs Speed

So after a few days playing around with python I noticed a few interesting things:

1) PyPy is not always the fastest!

PyPy is an version of Python with a JIT compiler that is supposed to speed-up python code dramatically. It especially is good at optimising loops but has trouble with python modules that are not pure python, but have C/C++ backend libs.

Unfortunately in my case both PyGLET and PyMunk are backed by C/C++ and the event loop of my game is handled by PyGLET and calls events on the python code.

This causes PyPy to not perform as well as CPython in my case.

2) CPython performance is weird???

With my very simple early prototype I am getting weirdly inconsistent frame-rates between runs of the exact same code.

While I usually get a nice smooth 60fps, every now and then it will only run at 20fps for no apparent reason.

This raises the possibility that the finished game will not perform as well as I would like and makes me consider dropping python in general.

Of course that has its own set of problems, while the chipmunk code can be fairly easily ported to c++, changing the windowing/graphics library to something like SDL will be a bit of a pain.

Here we go again!

After a fairly substantial break that started off with an attempt to make a compiler for a custom language, I have decided to come back to the #1GAM competition and have another go.

The theme for this month is Resolution.

The game idea that I have come up with is a platformer game where your character starts off as a single pixel (scaled up so its visible) with no memory of who you are and what happened to you.

By collecting pixels throughout the levels you will gain “resolution” and recover your memories.

This time I will be using python as the language and the pyglet window/graphics/sound library.

I am also considering the pymunk wrapper for the chipmunk physics library.

I recorded a video of a little test that I did with the sprites that I am going to use (full resolution) you can find here:

#1GAM Game 2?

So 13 days have passed in this month and I have not posted anything. Does this mean that there is no game this month?

Well the answer to that is no, there is a game this month, I just haven’t got around to writing about it.

This is partially because I’m not that happy with what I chose to do and partially because other projects have demanded more attention.

What is this months game?

The theme for this month was “Doctor”, meaning it the game just needs to reference a doctor of some kind (whether medical or some other doctor).

This month I have chosen to follow that theme and since last month I had a lot of troubles with porting the game and was only in the end able to get it done for Mac OSX Mavericks, I have chosen to go in a much simpler direction.

And so Click Hospital was born.

Click Hospital couldn’t be any more different from Space Shooter, HTML+Javascript instead of C, no physics, no graphics, and very little game logic (relatively).

Click Hospital is what you would call an idle clicker game.

Basically clicking a button earns money which then can be used to purchase things and upgrades that make more money.

There is no end-game so there are no states such as winning or loosing it just continues on, although you could consider it the end when all the possible items and upgrade and achievements are purchased (although there is no limit on the amount of each item that you can purchase, and future updates can unlock more items/upgrades/achievements).

So while the game is inherently pointless, there is something about idle clicking games that is extremely addictive.

Advantages over Space Shooter

So while Click Hospital is much simpler the Space Shooter it also has quite a few advantages.

Because it is written in HTML and Javascript, it is inherently cross platform as you can run it on any system through a web-browser.

Also because only a limited amount of logic is needed for the game to be considered playable, I can make the game available for playing earlier in the month and then expand on the content for the rest of the month.

So where is it?

Ok while I said not much is needed to be considered playable, I have not yet made it to that stage.

There is a little bit of work remaining to get it into that state, but I am quite close.

I expect to have it ready for the initial launch in the next few days so pay attention to the Games section of my website.

Game Complete?

A lot of work (and time) has happened since the last update. I have completed the game to the point that it works as a prototype for a real game if I wanted to continue it down the line.

What does it include?

Well as promised in the last update we have lazers!!! You can shoot lazers from your ship at the turrets, but watch out, they will be shooting back at you!

Not only that but I have gone so far as to include lazer and explosion sounds. Did I also mention collision detection? I guess thats pretty important or the explosion sounds wouldn’t make sense.

There were a lot of physics and geometry calculations added so that the lazers shoot in the right direction (with some random spread for inaccuracy) and with the bounce when you hit a turret.

Also I have added gameplay elements like the shield discharging when shot (and recharging after 2 seconds of not being shot or colliding with turrets) the player ship only having a limited number of hits before it explodes and its game over, also winning game over when you kill all the turrets.

And to give it some atmosphere I have also got some cool background music that plays.

So its all done then?

Well why the game code is complete there are just 2 things that I want to do before I publish it.

  1. Allegro sound closing issue
  2. Windows build

Allegro sound closing issue

There is a problem with the Allegro library that when you try and unload the sound extension it locks up the game.

It seems to be a problem with cleaning up the default mixer so I might experiment with adding my own mixer and see if I can fix it.

If I can’t fix this it means that the game doesn’t quit (although I close the window so you can kill it with the force quit easily).

Windows build

I would like to build a Windows version due to the number of people who still use Windows, but to do that I have to setup an environment that I can build it in.

Visual Studio is out of the question as I mentioned in an earlier post due to its lack of c99 support.

That leaves me with setting up either a cygwin or mingw environment.

Having previous experience with cygwin and conflicts between the cygwin1.dll released with the app and one that might already be in the system directories I would prefer to not use it.

That means that over the next day(s) of free time I will be trying to setup a mingw environment and trying to get a build ready.

Screenshots (yay)

Everyone likes screenshots so here are a couple:

Screenshot 1 Screenshot 2

Looks quite different from the last screenshots right?

Now were getting somewhere

Flying Spaceship with shield

After my disastrous Windows experience, I have some new work-in-progress screenshots:

Spaceship with shield Now were getting somewhere

Not only do I now have a cool spaceship with a shield, it can be flown around the map nicely, also note the image with the thrusters on also causes the back of the ship to glow (oooh nice).

The longer you hold the up key the faster it gets until it hits top speed. If you let go of the up key it slows down and eventually stops.

Rotation is controlled by the left and right keys, but don’t expect it to instantly shift the new direction, its existing force keeps going in the same direction until it slows off or an opposing force slows it down.

Stop key? Nope! There is no stop, unless you let it gradually slow and stop or suddenly turn right around and use the thrusters in the opposite direction.

You might also notice the stars are smaller and there are no planets anymore. The planets were ugly and weren’t really that important, since the stars git it enough indication of “space” anyway.

So thats it for this update, up next: LASERS!!!