Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1305673 Posts in 58318 Topics- by 49420 Members - Latest Member: AdamBallard

July 25, 2017, 04:51:51 am

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityCompetitionsVersus (Moderator: Melly)The Snap [Finished]
Pages: 1 ... 4 5 [6] 7
Print
Author Topic: The Snap [Finished]  (Read 37358 times)
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #100 on: February 19, 2011, 07:16:53 pm »

Hah yeah this is hard to test single-playerrrrr

(would be nice to display what the controls were somewhere, also to have esc go to the title screen)

I personally think the 'snap' sound effect is a bit queer.
Yeah the way I'm planning on addressing this is you pass through the screen pictured above before you play ( current controls will be visible in the lower box). ESC=back-rather-than-quit is a good idea.

The pure-1p mode is going away, like, tomorrow. (I can imagine making a meaty 1P mode where the goal is to solve "puzzles", but I feel like that territory has been well-covered by other games already, the entire point here is the interaction of two autonomous entities that both have the ability to time-travel.) Playing 2p mode with "one person" is not much better though and I assume that's what you're referring to. I think I far underemphasized the importance of online play, even as a prototype I'm having a lot of trouble getting value out of this without being able to play a bunch of actual games as I go.

Also re the snap sound: Really? Hm. You mean the first-pass snap? That was the only sound effect I was happy with.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
increpare
Guest
« Reply #101 on: February 20, 2011, 01:59:33 am »

I meant, it's hard to test 2 player with just one player.

I think there might be too many controls for a two player one keyboard game.  Way too much risk of clashing keys.  Not sure how I'd change it, though.
Logged
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #102 on: February 20, 2011, 02:20:37 am »

I meant, it's hard to test 2 player with just one player.

I think there might be too many controls for a two player one keyboard game.  Way too much risk of clashing keys.  Not sure how I'd change it, though.
Oh, I have a sort of solution for that, it requires a cheat code right now tho (enter backtick for fire up). You should try the build I (should) have tomorrow.

I should probably admit I have done almost all my gameplay testing with a gamepad.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #103 on: February 21, 2011, 01:17:08 am »

You should try the build I (should) have tomorrow.
Yeah I didn't get as far as I thought I would when I wrote that.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #104 on: February 21, 2011, 01:24:09 am »

Day 32

Mac build (r151)
Windows build (r151)



Status: Still pretty sick and progress is very slow. A little alarmed because I'd been hoping I'd be able to use this 3 day weekend as crunch time-- I'm certain I'm going to meet the deadline but I'm starting to get worried about which features will or won't make it in. I got a good way along on the player config screen but it's still got issues, in particular you can't pick anything other than the keyboard so I can't remove the "old" menus yet. I'm using inverse text to denote selection on the player config screen so I switched the level picker screen to use inverse text for selection also-- that >SELECTION< thing was extremely aesthetically pleasing to me but oh well, it was also kind of hard to read.

Now that I'm looking at the player config screen, I'm worried about whether it's readable or if there's just too much dense ASCII. I tried to space it out a bit.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
Fluff
Level 1
*



View Profile Email
« Reply #105 on: February 21, 2011, 04:24:59 pm »

That menu looks fine to me. The only thing that seems a little squeezed in (both vertically and horizontally) is the "Type '1' to change" line. Not sure how to improve it though. Maybe take out the ' tick marks? Not sure if that would help much.

You could also try lining up all the : to the same column. The text wouldn't be centered, but it might make it subtly easier to read.

Also re snap sound: is that actual fingers snapping? I like it.

I'm looking forward to more! Keep up the excellent work!
Logged
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #106 on: February 21, 2011, 09:58:16 pm »

Day 33

Mac build (r151)
Windows build (r151)





Status: Fixed various camera problems, added levels which "loop" (it seemed weird to me that the time axis looped but the x and y axes never did), added levels with gravity, allowed levels to override several other physics defaults, added custom messages for levels, added a level setting called "immortal bullets". The game is technically like 3x bigger now counting by number of maps.

There is a particular visual glitch associated with the loop levels still. The "Platforms" (gravity) and "RubberRoom" (immortal bullets) levels, which are kind of experiments/jokes, kind of highlight flaws in the engine and I'm not sure whether to keep them in or not.

Guess I might as well document how user-created levels work now. You can create your own levels by dumping .xml and .png files into the same directory as the Snap .exe (or .app). Snap will load all .xml files it finds when it starts up, and when it's building level maps it will load .pngs in the directory "with the exe" before looking inside the application's internal folder (in other words it's possible to override default maps). If you want to see example .xmls and .pngs, look inside the "Internal" folder (or, on the mac, control-click the .app, choose "Show Package Contents", look in Contents/Resources). You should be able to just copy the default level.xml and edit that; each "level" line is one of the default maps. The "level" attributes, if it's not already obvious, are defined like:

* "name" - Name in level menu. Required.
* "file" - Png file name to load to construct map. Required unless "padded_room" is true. Notice, EVERYTHING else except these first two attributes is optional and will be replaced with sensible defaults if left out.
* "maxhealth" - Maximum/starting health. An integer greater than zero.
* "std_zoom" - The camera zoom amount. A float value greater than zero.
* "forever_length" - Number of seconds before the timeline "loops". A float value greater than zero.
* "snap_factor" - Snap distance is calculated by dividing this number from forever_length. This should be an integer which evenly divides forever_length.
* "block_size" - Each pixel in the "file" png will equate to a square with this side length. For scale, a player character is always a square 0.2 units wide and 0.2 units tall. This should be a float value greater than zero.
* "have_camera_freedom" - Determines on which axes the camera may move freely. This is what I'm going to call an "xy mask", which means it's an integer equal to either 0 (for "neither axis"), 1 (for "x axis"), 2 (for "y axis") or 3 (for "both axes"). The default is 3.
* "have_camera_limit" - Determines on which axes the camera halts at the edge of the map. An xy mask. Default is 3.
* "repeat" - Determines on which axes the map "loops". An xy mask. Default is 3. By the way, I've discovered that my old game Jumpman (which also used PNGs for level maps) is an excellent editor for making levels using this feature. Note though unlike Jumpman you shouldn't try to make levels in which the "repeating" area is so small you can see copies of yourself. This won't work and trying it will lead to graphical glitching.
* "padded_room" - If set to "1", the map is discarded and instead a special map is built which is exactly the size of the screen. block_size is honored but this attribute has not been tested to-- and probably does not-- work with many of the other attributes.
* "immortal_bullets" - If set to "1", bullets bounce off walls instead of exploding against them. May cause odd things to happen.
* "gravity" - If greater than zero, vertical gravity is enabled. This should be a float equal to or less than zero. The default is of course zero. May cause odd things to happen.
* "w_e", "p_e", "b_e", "w_u", "p_u", "b_u" - The elasticity and friction material values assigned to, respectively, the (W)alls, (P)layers, and (B)ullets. Do the documented things e and u do in the Chipmunk physics engine. Of very little use to you unless you are playing with gravity (I still haven't found a good value to set friction to with gravity, so the "Platforms" level things move like on ice).
* "message" - If present, the contents will be shown on the level select screen in the blank space between SNAP and FOREVER. All the messages in the default levels are of the form "HAZARD: Something here".

The custom levels feature probably shouldn't be considered "supported". Entering bad values for some of these attributes, particularly name or file, may cause the game to misbehave or crash. And I may change the schema later, though either way I'll bundle an updated copy of this documentation along with the game or something.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #107 on: February 23, 2011, 02:25:30 am »

Day 34

Mac build (r179)
Windows build (r179)



Status: Controls-config screen is now fully featured-- you can choose gamepads in addition to the keyboard now, and you can choose whether to use auto aim mode or not. The defaults for both players have been changed to use auto aim mode (meaning, 2 players can actually play on 1 keyboard using the default controls now). The superfluous, vestigial mouse-driven "menus" from earlier in the project have been removed (which felt good) and, since it's no longer used anywhere, the mouse cursor is now hidden during gameplay. Hitting "esc" now causes you to go "back a screen" until you quit instead of quitting immediately.

Nearly all of these features (all of them except the esc thing, basically) are totally broken, and using them will result in you running into a set of bizarre and inconsistent bugs which somehow exist when I build in release mode, do not exist when I build in debug mode, and may or may not exist on Windows. In release mode on mac it usually reads apparent garbage data instead of the defaults, usually does not create the controls save file (but often later successfully loads the correct data from the file it did not create), and asks for unused buttons (like "fire right") in auto aim mode. It looks like either I have a subtle memory corruption bug or I'm doing something incredibly illegal with filehandles.

EDIT: Wait, like a minute after I made this post I figured out part of the problem. Somehow the controls prefs file on mac is getting saved to / instead of to the expected directory. Which is pretty bad. But this does not explain the other problems.
« Last Edit: February 23, 2011, 02:34:45 am by mcc » Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
increpare
Guest
« Reply #108 on: February 23, 2011, 02:52:52 am »

Tried playing it yesterday with someone else.  Confusing and little else.  Didn't know which side I was playing on.  Keys kept on clashing, so trying to identify which side and/or cube I was by pressing buttons also didn't help.
Logged
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #109 on: February 23, 2011, 08:54:37 am »

Increpare, thanks, this was without auto-aim mode right? (Note: I don't suggest trying that build I just posted, it's likely to be yesterday's build plus interface bugs)
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #110 on: February 23, 2011, 10:01:29 pm »

Day 35

Mac build (r181)
Windows build (r181)



Status: One more day on that increasingly-terrifyingly time-consuming controls configure screen, and I do believe I've fixed all the problems with it now. The controls file should save in the right place, not become garbled, your choice of auto-aim vs free-aim should be honored. As one more wrinkle I made the way you exit the screen now be that both players are supposed to snap. This decreases the risk you will blow past this screen without absorbing any of the information.

Also made some GRAPHICS today but did not put them in the program yet.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #111 on: February 23, 2011, 11:21:19 pm »



Not 100% sure yet where I am going with this.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #112 on: February 25, 2011, 04:00:04 am »

Day 36

Mac build (r188)
Windows build (r188)



Status: Objectively not a very big change but probably important, a complaint I've been getting from playtesters for a long time is that there's all these copies of yourself on screen and you can't keep track of which one you're actually controlling (or, as, one report the other day pointed out, which half of the screen to even look at). So I gave the square you are actually controlling at any one moment a kind of pulsing glow now. (At one point messing around with the blend functions I got this to have a pretty light-bloom effect to it, but this broke other stuff...) If anyone plays this I'd be curious what they think of the player pulsing, did it help, etc.

Oh also the game shows score "totals" on the game over screen now.

Running kind of low on time now so I'm starting to think now about feature triage. The two things I think I'm going to really try to get in before doing final cleanup are music and the health drops. If ammo drops don't make it in I'll deal. I made some little sprite things for health, ammo and snap refill canisters. They looked terrible. Then I talked to Kyou, who did the sprite work for Jumpman, and he made these and they look awesome.



Current plan is to try to use one of these for the health refills.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #113 on: February 25, 2011, 04:01:45 am »

BTW, increpare--
Tried playing it yesterday with someone else.  Confusing and little else.  Didn't know which side I was playing on.  Keys kept on clashing, so trying to identify which side and/or cube I was by pressing buttons also didn't help.
Thanks for the playtest, this report was what spurred me to make the change today. Is time travelling missiles still going to be in the compo?
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #114 on: February 26, 2011, 03:13:52 am »

Day 37

Mac build (r199)
Windows build (r199)



Status: Rushed one last feature in: Health drops. At periodic intervals, if the level is set up for it, there will be a flash in the time bar up top indicating a health container has just appeared somewhere on the timeline. If you get the health container, you restore some health. The health container is subject to the ravages of time travel like anything else in this game, so if you get a health container, and then the other player goes back in time and gets it first, the extra health is deducted from your bar and transferred to the other player.

The original idea with the health/ammo drops was, since the incentive is to grab them as close as possible to the moment where they spawn (to prevent someone else from retroactively grabbing it "first"), as soon as one appears on the timeline it should create a race across time where all the players dash to jump back to the point where the spawn was marked to occur. The health/ammo drops were supposed to be an incentive to move around the timeline and the map, and create interesting "moments" in time, instead of just plodding forward in normal time or camping near time 0 around the other player's spawn point. However as things have developed I don't think the health drops are enough of an incentive for them to really change the game much-- play just moves too quickly in this prototype, and picking up the health packs is mostly extraneous to winning (if I got ammo drops in, there were going to be levels where taking advantage of the ammo drops was required because you actually just weren't given enough bullets to kill the other player without reloading at least once). So you probably are better off just ignoring the ammo drops. However maybe this will give some sort of sense of how things might work in a slightly more complex version of this game.

In the end I put health drops in exactly one level, and stuck it at the end of the list with the other "experimental" levels.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #115 on: February 27, 2011, 12:16:53 am »

Day 38

Mac build (r212)
Windows build (r212)



Status: Added select-screen "previews" to the levels that didn't have them or where they had them but they looked wrong. Fixed a bunch of visual and controls glitching. Finally got to do some playtests and concluded that just literally no one notices the subtle glow that the "you are controlling this character" characters get, and the game is simply not playable if you can't follow which square you're controlling. Gave in, said SCREW AESTHETIC PURITY and put big ugly smiley faces on the character you're controlling. If you can't keep track of who you're controlling now, there is nothing more I can do for you. Oh, and I gave the game an icon.

This will be the last update of this type, my build tomorrow will be my final submission to the compo. I don't expect any further changes except a linux version and maybe a kill screen if OpenGL 2 is not present. Hoping to spend my time tomorrow doing as little coding as possible and ideally making, like. A HOW TO PLAY graphic or something.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #116 on: February 27, 2011, 11:36:52 pm »

Posted!

The Snap
A first person shooter

Download (1.0, r219):

* Mac version
* Windows version
* Linux version (requires SDL and Freetype)

How to Play:



The Snap is a deathmatch shooter with time travel. Time in the Snap arena takes place in a loop. 20 seconds or so after the start of each game, the events of the game will begin to repeat themselves. You can also jump back in time by about five seconds or so by performing a Snap.

If you interact with the past, you will change the present. If you shoot someone in the past, you will damage them in the present. If you block a bullet in the past, thus preventing someone from getting hit by that bullet, damage in the present will be undone.

For best results, I suggest using a gamepad with analog thumbsticks (you can fit both players on one gamepad if you try!); also, since the game uses stereo sound with the sounds "heard" by one player going to each ear, I suggest plugging in a pair of earbuds and giving each player one earbud.

10 levels are included, and you can make your own; if anyone plays around with the custom levels feature, please do post and let me know!

Future development?

This is sort of a prototype, and I'd be interested in making a more complex game using the time engine someday. If I open sourced this, would anyone use it?
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #117 on: March 17, 2011, 01:28:35 am »

Very late response to Will Vale's question!

Thanks for your earlier description of the event tree - I think what I wasn't getting was whether it was fully discrete, or whether events could come in at any point in time - so you jump -10s, but you can start from any time rather than at 10 second intervals.

The latter would make it possible for the tree to grow very large, but since you have a limiting factor in that players only make so many decisions per second, it's probably not a huge deal?

How do you store player movement in the event tree?

Cheers,

Will

So: This is NOT IMPORTANT TO PLAYING THE GAME, but here's a bunch of internal information about how the game works.

There are:

- Objects
- Events

There are two [main] kinds of objects:

- Bullets
- Players

There are two kinds of events:

- Events (single events, at single points in time)
- Lifetimes (an event plus a "duration"-- the duration can change if it needs to)

Objects have:

- A lifetime-event associated with them
- Arrays recording their position and velocity at each point in time that they exist

Events have:

- A list of "children"-- events with the property "if I happened, so did this".

Lifetimes have, in addition to their duration:

- A list of "children", BUT each child may also have an "after" time-- meaning with lifetimes, dependence is more like "if this lifetime survived AT LEAST to time T, then this other event happened".

Events have a "set_canon" function, which can be used to say "you didn't happen anymore" or "you happened, but you now cease to exist at time T". When this gets called, it goes over its list of children and (if appropriate) updates their canonicity-- it says, you depended on me, but I didn't happen anymore, so you didn't happen either. The children then dutifully call their children and so on...

Aside from this, there is a "forever" array. For each moment in time, this has a list of the events which occurred at that moment and a list of the lifetimes that began at that moment. Remember, time wraps, so there is a finite number of moments.

So, one more object I need to introduce: I also have a sort of a game-runner object I call a "space". It has:

- A Chipmunk physics space.
- A list of "currently alive" lifetimes.

When I simulate the game, I tell the space object to step through the "forever" array, moment by moment, one moment for each drawn frame. At the start of each moment, I trigger the events which are registered at that moment. The events do different things depending on their type. Some of those events are lifetimes, and they insert themselves into the "alive" list for the stepping space. Some of the lifetimes are OBJECT lifetimes, and these ALSO insert the appropriate bodies/shapes for that object into the physics space. After triggering the events, I go over the list of "living" lifetimes, and give each one an option to do more or less whatever it feels like. The object lifetimes in particular take this moment to interact with the physics objects they manage: If the object is "present" (i.e.: it has not filled up yet its position/velocity arrays) then it lets Chipmunk calculate its next position and velocity and then it records them in its record arrays. If an object is "past" (i.e. the position/velocity arrays are already set), it overrides what Chipmunk thinks should happen next with the historical recorded values. (This means that there may be lots of objects on screen at once, but only a few are ever being updated at any one time, the others are just marching through their replays). Eventually each lifetime object reaches its "maximum duration" and then it is removed from the alive array.

Objects and lifetimes cannot "time travel" in any fashion. Sometimes an object lives to the "end of time", the wrap moment. If this happens I actually "destroy" (i.e. set the maximum lifetime of) the object and create a new object at time 0 at the appropriate place. The new object's lifetime event depends on the old object's lifetime event surviving all the way to the end of time.

So, let's consider a very simple thing that could happen in gameplay: Let's say 60 is the "end of time". Let's say at time 50 player 1 fires a bullet. Time passes and we reach time 60; the bullet is still in flight. The player and the bullet are both destroyed. A new player object is born at time 0; it depends on the old player object living to time 60 (though this is irrelevant because if a player ever died the game would end). A new bullet object is also born at time 0; it depends on the old bullet object living to time 60. More time passes; at time 10 new-bullet hits a wall. The bullet is destroyed, and a "kash" event is born at time 10. The "kash" event depends on new-bullet surviving to time 10; what it does is play a sound effect ("KASH!") and draw a little explosion animation. Okay, so this is all well and good. Time keeps passing. Eventually, we get BACK to time 50, again. At this point player 2, who we've been ignoring all this time, comes flying in and, at time 55, accidentally walks into the path of the bullet (the "old" bullet, because we haven't reached the wrap yet). Several things happen at once. A new "kash" event is born at time 55, dependent on old-bullet surviving to time 55; and a new "health loss" event for player 2 is born at time 55 since she got hit by a bullet, dependent on old-bullet surviving to time 55 (health quantities have their own system for tracking I won't get into except to say it's done via the event tree). Meanwhile, old-bullet is destroyed: Its "maximum duration" changes such that it now only survives to time 55. Since the bullet-lifetime's duration has changed, we check the event tree to see if there are any children who are no longer canon. There's one: the "new-bullet" birth event, at time 0, depends on the old-bullet living to time 60. It doesn't anymore, so new-bullet is no longer canon. New-bullet informs its own children (the "kash" event); they are no longer canon either. So time keeps marching and this time, at time 0 new-bullet is NOT born and at time 10 the kash effect does NOT play, because although they're still in the forever array, they're marked as non-canon.

... there's actually a lot of complicated crap happening just to track a bullet here!!! The system's very expressive, though, which is why I think I can do the things I want it to do if I ever make a Snap 2.0 (four players, players dying and coming back to life, etc).

One final thing: The scenario I gave above describes just stuff happening in a single "space", a single thread of time. However if you perform a snap you can jump around in time. The way this works is that I actually am always running several spaces at a time, scattered throughout the timeline. So if "forever" is 20 seconds and the "snap size" is 5 seconds, I create 4 space objects, one initially "positioned" at 0 seconds, the others at 5, 10 and 15 seconds. On each drawn frame, all four spaces load their respective moments and do the right thing. Each player has a space they're "looking at", and when you snap all you're doing is changing which of the four spaces (four in this example) is drawn on your half of the screen.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
Will Vale
Level 4
****


will@secondintention.com
View Profile WWW Email
« Reply #118 on: March 17, 2011, 05:04:45 pm »

Thanks for the explanation, I've read it twice now and I think I'm starting to get it...

Am I right in thinking that the position/velocity array for each object has (fps * forever) entries, e.g. 3600 entries for 60fps/60 seconds?

Will
Logged
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #119 on: March 17, 2011, 05:52:47 pm »

Thanks for the explanation, I've read it twice now and I think I'm starting to get it...

Am I right in thinking that the position/velocity array for each object has (fps * forever) entries, e.g. 3600 entries for 60fps/60 seconds?

Will
Yup, same with the "forever" array that holds the events. (Although objects in practice can have shorter record arrays, because many objects don't live the full length of "forever", but this is basically an implementation detail.)
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
Pages: 1 ... 4 5 [6] 7
Print
Jump to:  

Theme orange-lt created by panic