SS Tiny World
This game is from the old Ludum Dare platform. You can try viewing the original page on Web Archive
(may not load correctly).
(may not load correctly).
First Ludum Dare and the result is playable! I would have liked to design some levels and add more backstory, but I'm pretty happy with what I've got. Thanks, Static Void Games, for hosting! Code was done in Java, graphics in Photoshop.
I've added a gameplay details document to try to make the game more playable, less confusing. This is post-compo.
With this game I wanted to experiment with an idea that has been kicking around in my head for a while, temporal portals. I imagined you having a barrier in your way, but then a portal opens up and your future self emerges, presses a button that clears the barrier, then returns. You then go through the cleared barrier, create a portal and go back in time to clear that barrier for yourself before moving on.
It seems to me that you need to be able to create portals from the future at any time, but with each portal you are also creating a 'promise' that in the future you will enter a portal to the past. I wanted to add something that would individualize the players, something that could change with them over time. I chose hats because they were easy to implement (the same hat graphic is used for facing left right and down, it almost worked when facing up, but it didn't cover the guy's bald spot.) So, when a player with a hat portals in, you have to fulfill the promise by portaling out a (different) player with a hat.
I realized that this might cause paradoxes and introduced code to prevent that, which ultimately made the game very confusing. I wanted to be able to play back the path of the one character through time, so you watch him go through each portal until he finally finishes the room. If the 'promises' were not filled, then this sequence could not be constructed. I considered adding in 'cameos' to fix hat/no hat problems (the player enters a portal, then you see him inside the time portal and finds a hat floating in the inter-spacetime void, which he takes before returning to the real world) but I thought that putting the responsibility for avoiding paradoxes on the player would make a more interesting game. That idea clearly needs to be re-examined post-mortem.
Please let me know what parts are confusing or what parts you have a good feel for. Thanks for playing!
I've added a gameplay details document to try to make the game more playable, less confusing. This is post-compo.
With this game I wanted to experiment with an idea that has been kicking around in my head for a while, temporal portals. I imagined you having a barrier in your way, but then a portal opens up and your future self emerges, presses a button that clears the barrier, then returns. You then go through the cleared barrier, create a portal and go back in time to clear that barrier for yourself before moving on.
It seems to me that you need to be able to create portals from the future at any time, but with each portal you are also creating a 'promise' that in the future you will enter a portal to the past. I wanted to add something that would individualize the players, something that could change with them over time. I chose hats because they were easy to implement (the same hat graphic is used for facing left right and down, it almost worked when facing up, but it didn't cover the guy's bald spot.) So, when a player with a hat portals in, you have to fulfill the promise by portaling out a (different) player with a hat.
I realized that this might cause paradoxes and introduced code to prevent that, which ultimately made the game very confusing. I wanted to be able to play back the path of the one character through time, so you watch him go through each portal until he finally finishes the room. If the 'promises' were not filled, then this sequence could not be constructed. I considered adding in 'cameos' to fix hat/no hat problems (the player enters a portal, then you see him inside the time portal and finds a hat floating in the inter-spacetime void, which he takes before returning to the real world) but I thought that putting the responsibility for avoiding paradoxes on the player would make a more interesting game. That idea clearly needs to be re-examined post-mortem.
Please let me know what parts are confusing or what parts you have a good feel for. Thanks for playing!