SS Tiny World by JesterBLUE
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!
Ratings
| Coolness | 45% | 705 |
| Overall | 2.52 | 709 |
| Fun | 2.09 | 782 |
| Graphics | 2.83 | 456 |
| Humor | 2.56 | 277 |
| Innovation | 2.96 | 419 |
| Mood | 2.62 | 475 |
| Theme | 2.65 | 606 |
Could not find the main class: TinyWorldLD23.TinyWorldLD23. Program will exit.
That's with the newest Java Runtime Environment.
-->TinyWorldLD23.java line 29 should be deleted, this is probably what is causing the trouble. The program still ran fine on my computer, so next time I will test on a different computer. The line references a class I replaced in the 44th hour.
-->Animation speed is related to computer speed, needs to be regulated to a clock instead of just tick counting. everything animates faster than intended on modern computers (this was programmed and tested on a computer built in 2001)
for a temporary fix, increase the values of ANIMATION_TICK_TIMEOUT and STEP_TICK_TIMEOUT in TinyWorldLD23 lines 24 and 25.
->terminals do not display random messages. to fix this, change levelLoader.java lines 156~165? to:
//start of good code
//now add a terminal tile, but not over teh start tile
String str=strings[randomLevel.nextInt(numStrings)];
TileTerminal t;
do {
t = new TileTerminal(randomLevel.nextInt(TinyWorldLD23.TILES_WIDE),randomLevel.nextInt(TinyWorldLD23.TILES_HIGH-1),str,randomLevel);
} while(thisLevel.tiles[t.xpos][t.ypos].getClass() == TileStart.class || thisLevel.tiles[t.xpos][t.ypos+1].getClass() == TileStart.class);
thisLevel.tiles[t.xpos][t.ypos]=t;
thisLevel.tiles[t.xpos][t.ypos+1]=new TileFloor(t.xpos,t.ypos+1);
}
//end of good code
->the messages on the starting terminal sometimes run off the screen. this is fixed by editing levelLoader.java lines 41-68
->clicking the start terminal many times then clicking the messages many times will result in missing standard messages. Not quite sure why, I would guess something in Message.java related to multiple threads deleting messages at the same time.
But... wow. Sheesh. This is a complicated and intimidating game. It's hard for me to embrace this level of apparent complexity given that the reward for success isn't clear. It made me realize how important it is to be gentle to a new player... to give them confidence in themselves as players, and in you as the creator.. In this case, I haven't really had the gradual progression of increasing difficulty to also gradually increase my trust that the game is worth my time.
The game itself was really confusing, though. I wasn't sure how to get the hat back in the cupboard without not having stolen it (if that makes sense).
But overall, good job.
SLiV - to get the hat back in the cupboard, do this:
find a player with no hat. (create more players if needed until you get one.) have that player take the hat from the locker and portal out. have another player with a hat put it back in the locker. portal out everyone except one player with no hat. the green portal should be open (unless there are still some cupboards that have had their hats stolen, in that case get a player with a hat to put it in those cupboards.)
Got a bit confused by the hat thing at first. Also the some of the tiles are not obviously walkable. The controls are also a bit awkward, especially if you have a long way to go.