I can't believe that I did all the sprites with MS Paint. Even though I have Photoshop. Why? .... Just for kicks.

-Stella

We've just posted the first mockup:

Click here for a full resolution. Graphics courtesy of Urser. The characters are Jellyfish (they wibble) and the main character can shoot jelly (which wobble).

I've currently programmed in collision detection and projectile physics with some random sprites found on the Internet. I'm going to switch over to the above sprites soon.

Hi friends,

I'm new to Python game programming, so maybe this is too basic, but for me it is very interesting.

Tonight I was playing with py2exe as I want to distribute my games to people who doesn't neccesarily have Python installed in their computers.

After reading a couple of tutorials I could create an exe file.

Then using WinRAR I created a SFX file that uncompresses the file (plus libraries and media) in the temp directory and runs the exe automatically (so the user doesn't know is a SFX).

So now I can distribute my Python games as a single EXE's. Great!!!

You can test it here. (It doesn't do too much... just move the sprite using arrowkeys).

Best regards

JF

Still a long way to go, but I already learned a ton of things this week. Like for instance:

• one week can be really short, especially towards the end
• even seemingly simple things can turn out to be quite complicated
• motivation is no substitute for sleep

I'll upload some screenshots tomorrow (maybe even a first playable prototype)

Today I should have implemented baddies. Problem is I have been terribly busy... Watching TV and playing Super Tux Kart! As such I have really only managed to get around to creating some form of base for solid objects that the player can't walk through.

At first the collision detection turned out to be quite flawed. Initially, solid objects were recognized as crooks, which resulted in death for the player if he touched a pillar, bush or brick. After that had been "fixed" (actually I just disabled dying from colliding with crooks) I found that magically, Wibbles could walk under objects like walls.

I didn't quite understand why at the time, but after a bit of experimenting I understood the problem. The sprite group which contained solid objects and the one which contained baddies were passed in the wrong order to a function, so crooks became bricks and bricks became crooks.

Once that had been fixed, it turned out that Wibbles would magically be teleported from the right side to the left side of a square if he collided with it from the top. Luckily hitting the square horizontally worked. Yet amazingly after a bit of hacking, collision didn't work at all, Wibbles was beeing teleported all over the place by the collision detection. Eventually I decided to try with the code I wrote yesterday (which had only teleported Wibbles around if he hit the box vertically) and IT WORKED FLAWLESSLY! Despite the fact that it had not been working just "minutes" ago.

So basically, today I have implemented a class that loads a picture, changes it's position to a given  set of coordinates, and then does absolutely nothing, in a matter of just hours! What that means for tomorrow is that I will have to make baddies, triggers and messages from the gods work in the first half of the day, so that I can make menus the other half and then start making levels. Looks like it might become a rather short game (right now it includes a cutscene and a level with a square on it, neither of which will be included in the final game).

I spent today trying get the physics for the unicycle's forwards-backwards rotation to work right. As I suck at maths this has proved to be a lot more difficult than I anticipated (damn you, third dimension!!) This has involved a lot of random sign flipping and constant changing and most of the code has been hacked to pieces in the process. Oh well.

The aim is to have it so you can lean forwards and backwards with your mouse and control the wheel with the keyboard. At the moment this is incredibly difficult to control, so we may have to tweak it to make it a bit easier, maybe by giving the player less control over the wheel.

You will also be able to turn by tilting left and right, which should be fairly straightforward to implement as I probably won't make it realistic.


Here the rider (white line) is leaning backwards and the unicycle is about to tip over.

We have a lot to do before this playable and I don't know if we will be able to finish it on time, but we're going to meet to work on it tomorrow so hopefully we will be able to get a lot of it done then. Cav is also working on some music so we should be able to up the production values a bit by sunday.

Here is a graph to prove I did originally have a plan for this:

so beutiful weather, but i am sitting at home and thinking why game is going wrong ...

Do well and these friendly anonymous passers by might stop for a little while for the show.

I spent my game-programming time today experimenting with different ways the player can control their avatar in the game. Most of them sucked. I'm sticking with the latest, least-sucky version and hoping that inspiration will strike. I've got a few more things to add into the "game" ... I'll see how it goes.

I also experimented with cython - and wrote a blog post about it. That was kinda fun, but mostly a diversion from thinking about how to make my tech demo into a game :-)

No, you still can't choose your own path :-P

My internets have been down for the past 24 hours, due apparently to a burst water main flooding the exchange. Below is my diary entry for last night.

Today's progress was poor, which is a serious setback when I'm estimating having 2 programming days left. I spent too long today tweaking the character physics. The physics are very good now, and the upside is that the terrain feels great to run and jump on - you get some nice speed kicks when you land on a downward slope.

The fight to get friction working came down to numerical accuracy. Friction acts in the opposite direction to the player's velocity along the slope, if the velocity is not zero. But as you come to a stop, this velocity becomes small, but due to floating point errors, not actually zero. Normalizing this vector gives completely the wrong results - it actually starts the object moving again.

The moral of this story is that in a 2D vector class, __nonzero__ should read

def __nonzero__(self):
        return abs(self.x) > ERROR_TOLERANCE or abs(self.y) > ERROR_TOLERANCE

Now I'm up against it though. I have two days in which to take what is basically a platformer engine - though I am fairly satisfied with it - and make a game with it. I have plenty of innovative ideas to add but I value production and fun much more highly.

In today's screenshot I've added some trails to the player to illustrate the physics in action - notice how the player's velocity changes as a function of the terrain.