Something bugged me today. Although our game runs at a fast 60fps, it still was using about 60% of CPU on my weak eeepc. For a game mainly only active on events this is pretty bad. To solve this issue I decided to get rid of the display.flip() and use pygames.update() instead only updating parts of the screen that are more commonly used. By doing this our CPU usage was reduced to 2/3rds. More optimization to come. 

tl;dr
In case you are not writing a scrolling game: pygame.display.update() might save your framerates.

Demo Video of what we have so far: http://www.youtube.com/watch?v=q6t-JftajV8

Screenshot too:  

The background image is used as the level map (a trick I picked up from watching a timelapse of notch a while back). So I just edit the background image in gimp, and voila, new level! :) - Unfortunately, I just have the ugly little levels I made so far. I'll bug Lisa to make some better looking (and playable) levels.

The plain humans run away from mutants, and turn into mutants if they're touched by one. Mutant AI is super simple as well, they just run after the first human they see, or the player.
 
So much left to do!

Progress Dump:
    Sept 9-10: Pre-challenge: Basic infrastructure (skellington-1.9) and sprite animation code (but no sprites!)
    Sept 11:    Background-image based level map. Walking over uneven/sloped terrain.
    Sept 12:    Refactoring, rewrite background-image level code cos of bugs, super simple (f=ma) physics, just used for jumping at this point.
    Sept 13:    Mutants with some AS (Artificial Stupidity)
    Sept 14:    Humans, with more AS. They mutate into whatever mutant touches them, with a 3s delay.
    Sept 15:    I tried the game out with 50+ characters instead of 3 to see how much it slows down. Quite a bit. After a bunch of profiling, got the FPS up, but the final game will have 30 FPS instead of 60 like I wanted.

I got that out of my git log. While I've been doing this, Lisa has had a particularly busy week. But she's cool, so she still made a few sprites. I think they're pretty good for someone who has never done this before. Oh, and she made 5 different types of hair for our heroine. XD
    

It always branches to the left, and goes round in circles...

I don't know why I am having such a hard time going from a (broken) simulation to a game. One of my goals at the outset was to make sure I have a game, because I wanted to fight my natural inclination when creating simulations like this to just keep tweaking the simulation forever. After excessive tweaking, not only is the simulation completely broken (the virus does not spread beyond its first few victims), but there are still no meaningful actions for the player to even do. I did however add the basic system for doing actions, so that's a start I guess. You can hire doctors and researchers to a city, but they don't actually do anything.

I feel like it is so close, and if I am able to get the tuning on the simulation right, that the game will just naturally emerge from the soup of stuff I've been cobbling together all week. But I'm risking a lot on that assumption :) Here's hoping tomorrow is a bit more productive than today was!

As pyweek approaches the end quickly (less than 2 days to go) it's time to reflect a bit on what we planned an acheived. 

There is some discussion around pyweek on the suitability of python for writing games and a lot of yammering about frame-rate: It depends on two things: your implementation and the game you write. For our simple adventure style game python is perfectly suited. We have nothing running in the background just the occasional check for events. So event driven games are perfectly fine. As soon as you need more complicated stuff, you might get into trouble if you implement your logic too crude. Because of our simple loop we had to limit the framerate to 60fps not to run on 100% CPU all the time. There are computers this happens but even on my fairly weak eeePC the game runs at 60fps without a problem. 

For python: I like python and use it for most of my programming. I am confortable with a lot of things but still I learned a lot during this pyweek, especially because some more experienced and better python programmers reviewed the code and gave hints. My and some other participants motivation primarily was to learn (more) python and I'd say I succeeded. 

The scope of the project seems ok, although the story is very extensive and there is a chance we don't finish it. (the graph shown previously is just a tiny part it grows every day. I should have made a timelapse...) Nevertheless we already have a playable game and will finish. The project was well suited for pyweek (especially for a team entry). If i'd do a solo entry things would be a lot simpler. Graphics even if only stand in graphics or crude things quickly hacked in gimp really make a difference and give a more polished feel to the game. There is still polishing to be done and we still have ideas what to implement. If we don't finish everything the pyggys are an option... 

Overly I'm still stoked about pyweek and programming games in python (have never written a game before, as have some on our team, some others are 4th time participants (with 2DNF and one rather poorly rated entry). I'm looking forward to spend my time playing all the interesting looking games evolving in this pyweek.

Another slow day, but with some useful progress

• Some sounds were added to the game, although more are needed
• We replaced several placeholder graphics
• Added a new maze level
• The level editor grew a number of features. It can now load or create new levels, and, after some nagging, learnt about hotkeys.
• The level editor became a lot more robust in the face of unexpected level files, and now requires some effort to crash
• Several bits of out widget stack got fixed and improved

We have some quirks with how the snake reacts to keyboard input to tweak, and some of the debugging features need to be removed, but other than that, we just need to produce more levels to have a game.

Well I did not get all I was planning done, so tomorrow is going to be a bit of a rush.  I need to finish coding animated tiles, add in doors, add in switches, add in powers, add in trees, add in wool (don't ask, it'll make sense in the level), add in level finish, put in text entities (for in-game instructions), animate (walking, jumping, falling, activating, wow, I need a lot of time for those... not good), make 6 levels, finish tiling (haven't totally completed)

This will most definitely run into saturday.  Good thing is that the levels will likely be stupidly easy so I don't have to worry about that.

Wish me luck!

Hi fellow PyWeek-ers!

Only 2 days left! Still lots of things to do but we should end up with most of what we wanted in the game.

So what could we learn about FEAW today? Well we didn't show that many levels, no mutated Stan and no enemies. So today you're lucky because you'll see all of these things :D



Here's Water Stan jumping from platforms to platforms. Isn't he nice in blue?
And here is a part of the bathroom enemies: ducks. You can see they aren't that nice when watching their blank look.

So here Stan is trying to get to the tub in some purpose I won't reveal here. I can just tell you that throwing water balls won't be the only power of his water mutation.

 
So that's it for today for FEAW. Let's see what we did during this 5th day.
 
cha, as usual, created more asset. She finished all the levels today and did a few menus. So now all she has left to do is a few animations and 1 or 2 things.

elghinn didn't do that much as he was really tired because of last night diary entry :)
Well he had some time to handle most of the levels filling system. Now we can load and display the items, the gems, the platforms and enemies are almost there too.
He finished the room system so that now Stan car walk in the different part of a level.

We had some troubles with these room changes, mostly in the collision system because of some non homogeneous things in different coordinate systems.

And he even found some time to code a surprise, but I won't say what it is today. We'll give you a hint at some point.

And for my part of the day, I fixed a few bugs in the collision system so that now Stan can walk on the ground and all the platforms as he likes.
I also added the effects when colliding with an Item (gem, food, ..) and with the exits (to go to another room).

We hope we won't have too many problems tomorrow in order to be able to spend our saturday testing the game and tuning the levels.

That's it for today people. Good luck with your projects. We had time to look around and there are lots of really interesting games we can't wait to play to :)

Europe basketball championship that is going on in my country does not help me to participate into this challenge at all. But it seems I will manage to produce something. It is going to be bad one, because I just starting to gasp Blender Game Engine. The code I have written is very c like -- I do not know it is me or it is BGE fault.

So progress:

First of all, there is repository of my entry: https://bitbucket.org/petraszd/pyweek-13
Second, I think technically You can call it a game. Because You can play it and lose it.

Added optional grid alignment to the editor, logically I had to build towers all over the map. They are all rotating in different directions. This will make you dizzy! (when viewed in motion) :)