Scrolly Map

One Room

An epic journey revolving around one room, jumping on platforms, and an awful lot of treasure. The Spanish demand a ransom for the Inca Atahualpa! Collect enough gold and silver treasure to fill one room - three times! Based on a true story.

Awards

Give this entry an award

Scores

Ratings (show detail)

Overall: 1.9
Fun: 1.6
Production: 2.2
Innovation: 1.8

58% respondents marked the game as not working.
Respondents: 5

Files

File Size Uploader Date
inca-game-0.0.2.tar.gzfinal
The Game
7.7 KB dholth 2014/10/11 05:52
Screen Shot 2014-10-06 at 11.27.30 PM.png
Scrolly Map
87.4 KB dholth 2014/10/07 03:28

Diary Entries

And that's it

Well, my schedule changed and I didn't get as much development time as I had hoped, but I think I've accomplished something. Unfortunately the game is not winnable, but it should at least provide a neat example of using pysdl2-cffi (which exists as a result of my participation in the last pyweek). Until next time!

By the way, the source code repository is at https://bitbucket.org/dholth/pyweek19/

3 comments

Sticky situation

So I continued tweaking my physics re: player collides with world, loosely based on the Sonic Physics Guide. Continuing to experiment to find good values for gravity, drag, etc. Characters will fall to and snap to the floor, and the floor sets your 'vy' to 0. And, a first for me, we only let you jump if you are currently touching a tile. No double jumping. The funniest part is the same logic that sticks you to the floor also sticks you to the ceiling!

The coolest thing about how Sonic interacts with the ground is that it isn't the obvious box collision with the floor. Instead, several "sensor" points including a couple at either side of his feet are checked for collision, then the usual snapping is done. The Sonic games take advantage of this system to play the "teetering" animation when you are near an edge - one sensor is on the ground, the other is in the air.

Add a comment

Night 3: Gravity

Heavy stuff. Got the object layer to fall, and collide with the solid world layer.

Today I realized that PyTMX does not assign IDs to or load the coordinates for unused tiles. This makes it difficult to render the second frame of, for example, a bad-guy animation, if the level as drawn in Tiled only shows the first frame.

Instead, my game now uses a second Tiled map just for the characters. Each row is a single character and each column is one of the standard frames for characters like run or jump. The tiles, in a shared tileset, also carry properties to hold names like 'Hero', 'Skeleton' etc. (I am using http://opengameart.org/content/simple-broad-purpose-tileset). By loading the second 'critters.tmx' in the background, PyTMX gives me coordinates and properties for all the interesting tiles that don't necessarily appear statically in a level.

The game also handles gamepad hotplugging and removal properly, and as an optimization no longer draws tiles that are outside the visible area of the screen.

Add a comment

Night 2: scrolly map with joystick input

After a second night of coding I have a basic pysdl2-cfffi RenderCopyEx-based renderer for PyTMX maps that supports flipped and rotated tiles (the tile layer, not the object layer). I'm not 100% sure it matches Tiled in every case, but it is really nice to be able to get more mileage out of the same tiles by spinning them around. It took me a while to figure out that you can use the X, Y, and Z keys inside Tiled for flip & rotate; the keyboard shortcuts don't seem to be shown in the menus at all; you have to use the online docs.

An input class keeps track of gamepad add/remove events and synthesizes the keyboard and gamepad states at the beginning of each frame into more useful "x motion", "y motion" and "jump" states. And you can scroll around the little map to prove the input is working.

The game also has a 2-screen intro with an image and some sdl.renderUTF8_Blended_Wrapped text - a handy under-documented function that renders several lines of text in one call.

So far I'm very pleased with how much better organized the code is than my previous SDL adventures. Instead of having a giant game loop with everything, it has a simple game loop that delegates to classes that take care of the different aspects of what the program has to do. I'm hoping to be able to keep the core event loop generic and have it always just call 'render' and 'advance(dt)' on whichever scene is current.

Add a comment