Here is my submission to the "Toy Box Jam 2020"!
This is my first game jam ever.
Known issues:
- The game can only save up to 89 rails blocks due to limited save game size on pico-8.
- You can't destroy rails.
- T or X crossings are not supported
Have fun!
Nice game.
(p.s. deleted a bug report, because it was for the old version)
Sounds like you had fun with this game jam. The result is good! Nice work, it was fun to play with. I see you ran right up against the token limit!
@Dan555 Thank for the comment. I forget to write the known issues on this page (it's on the itch.io page).
The game can't save more than 89 rails due to limitation on the save data. I've spent some time improving this but can't seem to get more (and I also reached the token limit). After the 89 rails, the others are ignored.
Also, the game doesn't support X or T crossings, you are right. And you are not supposed to make a loop (it will probably create an infinite loop in the code that detects the rail path). I'll try to prevent the player to create the "turn" at the start of the path.
Just uploaded a new version.
@brettski: thanks for your comment! Yes, I tried to code in a "not so ugly" way but that probably didn't help staying below the token limit :)
Interesting systems here, but the gameplay was a bit too limiting for me. I unlocked all the areas, but missed one of the stations by accident, and then I wasn't going to backtrack my rails all the way back to it. I do appreciate that you took the time to prevent coins from showing up if you just go back into the same station twice though, as I was trying to metagame that mechanic. I was happily surprised that it didn't work. :)
I went through your saving code, and it looks like you're searching the map for all rocks and trees, then using a bit vector of 512 values for their destruction. Pretty clever, though it does use 25% of the save file on this alone. I have a few ideas for general storage optimization, and the biggest issue is the 2 bytes used to store each rail:
- The map looks like the default 128x32 Pico8 area, so you could store each rail's position in 7+5 bits, instead of 16. 12 bits becomes 3 bytes per two rails, so it's not that hard to do, and gives you 33% more save space.
- You could also use cstore() to permanently update the cart ROM for the entire map, then just have a saved copy of the starting map that you regenerate on a new game. If you stored the blank map as a 1-token string in code or something, this gives you much more storage. This is probably the best plan, if you keep the map this size.
- Since rails are often connected, you could also search for each connected group of rails, and save them separately. Start with the first rail in a group and save its position, then save the number of connected rails that follow, and the same number of offsets to them. There are four directions you can move, so each subsequent rail would only need 2 bits to store (where 00=left,01=right,10=up,11=down). But this means T-intersections and loops would require some interesting flagging, to separate connected rail lines into different paths.
The big thing I'd want in a full version of this is the ability to destroy rails, and some kind of stakes in the gameplay loop. Maybe the train is always moving? Maybe you earn coal instead of gold, and you have to feed the train or you lose? I just want a reason to play beyond the initial exploration phase. Other than that missing piece, I think this game is really great!
@shy thanks for the comment and trying the game!
I actually had the idea of the 12b instead of 16b for rails. But as I reached the token limit, and this is a basic game jam, I didn't have the motivation to do it ;)
For the cstore, if I understand the docs correctly, it means writing on the cart right? And therefore it gets destroyed when updating the cart? The map is actually generated on startup procedurally (world:init function) with a fixed size set in code and I don't use the map feature of pico8 at all.
About gameplay, you're right that it's a bit repetitive, and once you completed the objectives, there's not much to do. The fun part is that the original gameplay idea was not actually to build the rails, but to repair rails and remove obstacles to an always moving train, which is somewhat similar to some of your ideas. ;)
I like your idea of 2 bits per "next rail", I had the idea of storing the rails as segments but didn't think it as much and your idea is great! It should be easy to implement, especially since the game actually saves the full path of rail as a linked list, as T/X crossing are not supported (except with the token limit once again :)).
With a fixed map, I could therefore store 4 rails / bytes instead of 0.5 rails / bytes. I'll look into it.
EDIT: Well I was wrong because one can actually build rails from non-connected cities and this would not support it as-is.
Yeah, for a game jam it's better to avoid this kind of ultra-optimization. Just wanted to suggest a few ideas you may have overlooked, in case you wanted to keep working on this game. :)
You're right that cstore would break on cart updates. Although, if you aren't using the map memory at all, you'd have lots of cart space to work with if you wanted to save more data this way. It just has to be the final version of the game, so updates aren't an issue.
For the rails, it's true that you can build multiple tracks from different cities, but I was seeing it as just saving each track as its own group (with a starting position-based rail, and then the following "next rails"). It might be hard to structure this, especially if you're out of tokens, but something to consider for future games.
[Please log in to post a comment]
