Day 2 is sprites and backgrounds day

Hi fellow PyWeek-ers!

We just finished the 2nd day of this PyWeek and lots of stuff happened today.

First let's talk about the game a little more. FEAW is a platformer where you have to find your way through a lots of different rooms (like in the old Castlevanias).
So the player controls our cockroach, Stan through all these rooms. Oh he came to introduce himself.
 



And to help him, I previously explained that some mysterious gems will make him mutate, giving him abilities. Well these gems are elemental gems : Fire, Earth, Air and Water.

But I gave enough details for today so I'll tell you later how these powers can help Stan in his quest for food.
 
 
Let's talk about the work we did today now.

 cha continued creating really nice assets. A few discussions about the gameplay and she finished the first level. It really is a big step as now we see our ideas drawn and we just have to combine all the parts in the code to be able to walk in the first full level 
 
elghinn worked on the levels handling in code. He can now compose the world by assembling them (by loading some description file). He can also display the backgrounds and scroll in front of them.
So the next step here is to handle all the elements which will populate our levels.

I worked on the sprites: display and moves. I had no problem for the display but encountered a big fail on the moves part.
I wanted to make the player move using basic physics to update the speed vector of Stan: mass * acceleration = sum(forces)
So i coded the system with the gravity as one of the forces, the others being the forces resulting form the player's inputs (left, right, jump). It ended with the character having too much inertia, as if he was a big rock in space (or on the moon) and not responsive enough.
I think this could work but with lots of tuning and I don't have that time this week (but I'll have some one day). So I ended up throwing this system away and now Stan is really responsive and it's fun to control him.

So that's it for today. We'll continue this adventure tomorrow maybe with some enemies and other things.

(log in to comment)

Comments

Just realized you guys have a very similar idea to mine, down to the elements chosen!  The major differences are that I use eggs instead of gems, and the player can mutate at will, not to mention that our powers will likely be different.  I'm a one-man team, so my art will not be nearly as good as yours, but I'm hoping to get ragdoll physics for some fun.  Best of luck to you! you have a much better chance of getting a game together, and I look forward to playing yours!
Great minds think alike as one says ;)
It's really cool to see all people's ideas, the differences and similarities on a same theme.
I see you'll have exploding zombies ! I want to see that !! :) And how is it going with pygame ?
I realize I didn't talk about our tech: we chose pyglet + rabbyt for FEAW.

Well good luck to you too and I hope you'll be able to do all what you want for your game. Can't wait to test it ;)
I'll see what I can do, might be a hidden game mode... but the exploding zombies is just to give visuals when I don't have them at the time, but my first screenshot in my final release should be some enemy being epicly killed.

As for pygame, I like it's simplicity and it works and makes sense, not to mention is easily cross platform (just some os.path calls for filenames). of course, I've never even looked at pyglet or rabbyt for developing, though I remember a rather fun RTS (snowballz) using pygame and rabbyt I think.  I'll look into pyglet after the comp when I have some free time, to expand my options.
Can't wait to see these epic kills ;)

I tried pygame before pyglet and I found it really cool. But a few things at the time weren't really handy (in my point of view in 2008).
And pyglet didn't have these defaults (but had others) . I had a game running wit some performance problems and so I used the Rabbyt sprite class instead of pyglet's one and it solved a big part of the performance issues.

The big problem I see now with pyglet is that it doesn't evolve a lot (last release was on 7-January-2010)
If Stan has too much inertia it's because his mass is too high. Reduce his mass and he'll be light and controllable. In most games you wouldn't model jumping as a force though - it's an impulse, so it adds straight to velocity, bypassing the net force calculation.
Thanks for your advice mauve :)
I bagen to test to play with the mass indeed but I stopped quite quickly not to lose too much time (maybe I was in a pessimistic moment of the dev ;) ).
I thought about jumping as an impulse but thought that if added just once (when pressing the button) in the net force, if would just act like an impulse. I'll give a try to your last piece of advice afterr the PyWeek!