On 2/21/2014 10:20, Sebastian Silva wrote:
> Hi Gumm,
> Thank you a lot for helping me debug the issue.
> I decided to simply remove the "trans" property in the XML Tiled file
> so that I can use the Gumm library unpatched.
> This has allowed me to advance a lot in the development of our little
> adventure (still not a full game, sorry).
You're welcome. No need to say sorry. =) Now that you're past the trans
obstacle, the game seems to be coming along nicely.
> Now I wonder, for map transitions, I was looking at 23_supermap.py in
> examples dir, it seems that it should do what I want,
> but doesn't seem to work. Maybe I'm missing something, or I can
> motivate you to point me to figure out how the example
> should work? I'm also planning to make map transitions on certain
> events (character enters door...), but I guess it shouldn't
> be too hard to figure that one out myself.
Map transitions are a matter of taste. DR0ID made some beautiful level
transitions in our Pyweek events, but I have not gotten around to
integrating his Context class and transitions into Gummworld's Context.
I wouldn't expect you to want to work so hard at getting fancy, though.
:) But if you have some real guts, there is a zip of our Pyweek 13
Shroom Gobbler at
http://code.google.com/p/multifac/. Earlier versions
of DR0ID's transitions are in Fort Izembo and Fractured Soul at the same
web site.
The Supermap class was interesting. I brainstormed an idea after a
discussion on pygame-users mailing list: how to solve a demand for huge
surfaces when SDL surfaces have a finite limit. Also including the
concern that huge maps are memory hogs, the supermap concept was
spawned. It keeps only the most immediate maps in memory. But it is not
something I have tried to use in a game yet. I'm sure there will be
significant problems to solve with regards to managing the model (list
of objects involved in game behavior) and storing/loading game state
when it is swapped to/from disk.
One strategy I've used well is to define a "level" as a Tiled map. The
player moves between levels by hitting a hot spot in the map, or
completing some game logic, or using a game menu. To do this, the use of
Context is most convenient. Engine is a subclass of Context just for
this purpose. If you're interested in this, study examples/20_context.py
and gamelib/gummworld2/context.py. Switching levels or map areas is just
a matter of managing the stack of Context objects.
On the Google code site there is a gw2_skeleton package that is also a
great (and fairly small) example of how to design a game's contexts, or
to use as a game framework. I made it to save myself time during Pyweek,
and it did save hours of work. You just plop it into a fresh gummworld2
directory and it works; just add code to flesh out your game--which is
the fun part, after all.
I hope these tips help. Feel free to shoot additional questions to the
group.
> Another thing, in my code I fixed the keyboard input, sometimes if
> changing direction too quickly, the character would
> stop moving, I think this is because maybe one would press one key
> before releasing the other, causing the approach in
> the examples to not work correctly. I fixed the issue by processing
> pygame.key.get_pressed() for both key_up and key_down
> events (see
>
https://github.com/icarito/sunset-adventure/blob/master/game/runme.py#L361
> )
You're right, it is the order that the key events arrive. I've solved
this by using addition to accumulate key events. For example:
if key == K_RIGHT:
self.move_x += 1
elif key == K_LEFT:
self.move_x -= 1
Thus, if the player has opposing keys pressed they cancel out (zero)
until one is released.
> I'm still having lots of fun and hopefully so will the children. I
> tested the current version on an OLPC XO1.5 and performance
> is quite decent.
Ha. I'm delighted to hear of your experience on the lowly OLPC. :) I
look forward to watching your progress, and hope the kids get some joy
from our efforts.