DrakeFox Nov 15, 2013 @ 1:30pm
Suggestion for a feature long missing from the TIM series
From back in the days of DOS and TIM1, one of the great issues I've always had is trajectory. There's a LOT of trial and error in aiming (I at one point stopped playing TIM2 and went over to playing LaserLIght purely because of it having a Hold Right Mouse to show 8 directions for aiming purposes feature).

Implementing an aiming feature might be too tricky and messy in the UI to keep track of (unless you were to do some sort of tracing certain objects on a blueprint view or similar after a run)
Instead, how about a blue tinted (blueprinted?) snapshot/savepoint. Mark it during the run of a contraption, and state at that exact point, including speed and such, will be stored. You can then make changes to the layout and replay from that point a couple of times to get aim right. Of course to complete a puzzle you'd need it to be run from start.

Anything put in the way of something which happened previously wouldn't affect the snapshot. That's up to the player to keep track of. Making a collision layer for all the elapsed time would be too tricky and CPU and memory consuming I'd fear. Also placing dynamic objects would need to be wound up to the snapshot time once placed, maybe with a neat pencil sketch animation to show it's expected movement in relation to the snapshot?

A snapshot wouldn't eat too much memory unless you have huge contraptions, would be a fairly simple concept to convey to players, and would, at least for me, be very welcome in tweaking positions without having to replay a contraption from start to move a few pixels.
Or lacking a snapshot, how about a "run as fast forward to XXsec" to mimic this behaviour without the extra code to store and manage a snapshot?
Showing 1-2 of 2 comments
< >
gorilla nest  [developer] Nov 15, 2013 @ 2:17pm 
These are the types of features that we have been talking about since we started working on the game, we just haven't been able to fully explore them yet. Especially if you are making something massive, it will be very helpful to be able to see what's going on before you have to run the whole contraption.

Right now, we have fast forward which helps alleviate some of the waiting to see a failed contraption, but it's not going to be the final solution.

Trajectory lines, ghosted parts, checkpoints, all of these things are most definitely on our road map. I can't give an exact timeline on when things like this will get in, but you will see something related to this some day.
DrakeFox Nov 15, 2013 @ 10:05pm 
Sounds great :-)
Most game I've ever coded was a Minesweeper midlet for my old Siemens M55, and a P2P game of Scrabble in Java, so I might have no clue what I'm talking about. But it seems like it could be semi-trivial to add a "checkpoint" button during playback, and a special playback button to auto-play the contraption at max speed until that time, at which point playback automatically continues at regular speed. It shouldn't require much in the way of UI elements. There's already playback at a different speed. It seems like it'd be a matter of making sure to simulate a speed change at xSeconds gametime.

Of course the physics might be dependent on the timer and speed of which, in which case it wouldn't be trivial at all. And again if the other stuff is on your roadmap, it might be too much effort
Showing 1-2 of 2 comments
< >
Per page: 15 30 50