Game dev with questions
5 years ago
Århus, Denmark

Hey speedrun.com

I am a developer of a 2D physics platformer and have a few questions in regards to features that speedrunners like in their games.

I enjoy wathing runs, but never dappled in speedrunning myself, which is why I am reaching out, as our small team is making a game that we think could be interesting for speedrunners.

Questions about tracking:

  • Do you guys care about ingame timers -For the full run, for parts of a run? Or do you just always use your own timers outside of the game anyways?
  • I have noticed that when a streamer does a run, they often have a time tracker besides them showing their current time relative to a previous or their best run. If I were to save you the hazzle of setting up code sniffers, what kind of information o you want, just .txt files for major clearing points, per level? You want ingame time in those?
  • In terms of run validation, is it usually a issue? Would you want small things like in meatboy for example where there is a frame cycle you can track to combat video splicing. Or is that a non-issue, especially for a small title anyways?

Questions about gameplay: This a slitghly broader question, but what do you guys enjoy most in speedruns:?

  • The discovery of new routes, so a broad game with lots of alternative ways of getting to the goal (like Mario odyssey before it gets "figured out")
  • Skill and execution in a linear experience, so more like super meat boy, where the execution of each level is what matters and new tricks are of limited scope.
  • Maybe something else entirely?

Our team would be very grateful for any kind of feedback or maybe even further insight we might have missed, that could help us make a better speedrunning experience.

The intentions of this post is mostly for getting general insight, but if anyone is interested in giving concrete feedback or want to try a demo out, you can find demo and discord on https://chopchopgames.itch.io/mineralph

Iglum likes this
United States

In-game timers can be useful, especially when they automatically remove loading times (so players on different platforms can easily compare times). For a good implementation of such a timer, I'd take a look at Celeste. Don't know specifics, but something like that would probably save a little hassle by those who develop autosplitters. Probably a non-issue, but never hurts to have one.

This might be personal preference, but I'd choose option 1. Eventually, all routes become very optimized, so you always get the experience you see with option 2. But having more possibilities opens up the potential for multiple routes, or the discovery of new tactics, which bring excitement to speedgames. Plus, from a casual perspective, more routes increases replay value.

Iglum and MunkBusiness like this
Århus, Denmark

Interesting, we had a discussion internally in regards to timers, whether it should be a "true" timer that just keeps on going through loading and cutscenes, or whether to only count gameplay time. Arguments being like you said, fairer across all specs, and the counter argument being a true timer matches the timer a player would set up manually better.

Iglum likes this
Canada

"Do you guys care about ingame timers" If the in-game timer is reliable and accurate then people will use it. Bonus if you can have it show on screen at all times.

"In terms of run validation, is it usually a issue" Not really. There have been a few high profile cases of cheating in the last year or so but it's really not that common. Having frame-cycle stuff like that can be helpful but I wouldn't worry about it too much.

"The discovery of new routes... Skill and execution in a linear experience" You're going to get a completely different answer depending on who you ask. I wouldn't change anything about your gameplay to make it more appealing to speedrunners, since they're going to be a very small subset of your audience (speedrunning is still very niche).

"whether it should be a "true" timer that just keeps on going through loading and cutscenes, or whether to only count gameplay time" In most cases leaderboards will sort by load-removed time if it's available (and if you don't put it in the game, someone will probably make a load removal tool anyway), it just makes for a more fair competition. I'd have both.

Iglum, Quivico, and MunkBusiness like this
Århus, Denmark

Having both timer options might be a good idea. Thanks for your input, definitely nice to get the prespective from players. We haven't completed all leves quite yet, which is why getting some insight and new perspectives for what is enjoyable is still very useful without remaking anything, but we did suspect that it would be a "different people, different answers" sort of thing.

Iglum likes this
England

Already answered this on Reddit, mirrroring my answer here to increase exposure:

Do you guys care about ingame timers -For the full run, for parts of a run? Or do you just always use your own timers outside of the game anyways?

Yes, please do include an ingame timer. One thing that gets overlooked in speedrunning quite often is timing accuracy; if people are using an external timer, they will quite often submit an estimation of their actual end time ie. their final split was late, and they submit whatever LiveSplit displays rather than actually calculating the accurate time. Most of the time this "won't matter", but there is no reason not to assess the time accurately, and an ingame timer makes this not only simple, but also impossible to get wrong. Assuming that timer is accurate, of course.

This also levels the playing field between consoles; let's assume your game is going to be multi-platform, and will be released on Switch/PS4/PC. Without an ingame timer, all of these individual platforms will likely need to be partitioned into their own leaderboards, as there will be variable loading times between the consoles, and indeed between individual PCs!

Ingame timers for each level are also very valuable, because "Individual Level" speedrunning is a widely practiced element of the hobby. People not only want to see how fast they can complete the whole game, but also each constituent part of the game. Because these parts are often short, the level of optimisation is also correspondingly higher. This in turn makes accurate timing even more important, because where fullgame runs are likely to be separated by seconds, IL runs are likely to be separated by frames.

I have noticed that when a streamer does a run, they often have a time tracker besides them showing their current time relative to a previous or their best run. If I were to save you the hazzle of setting up code sniffers, what kind of information do you want, just .txt files for major clearing points, pr. level? You want ingame time in those?

This is a very nice offer, though I don't think you should worry about putting any special effort in to provide this information. As long as your game code isn't really cryptic to decipher, there'll be runners who won't struggle to find the relevant memory values. If you're sure it's no problem to provide this information though, typically we look for consistent flags that occur in the game code that can be used as useful split points, and don't occur anywhere else whilst the game is operating.

For instance, when we first worked on making an autosplitter for Sonic Adventure 2, we had to look for a way for the program to recognise that each level had been completed. The game fundamentally consists of a series of stages and boss fights, and when each of these stages is over, a fade-to-white animation plays that doesn't occur anywhere else in the game. This was our first idea for a flag the program should look for. We've now cut out the middle man by having the program simply look at the ingame timer itself, and split whenever it stops at the end of a stage. Some tooling was required to get it to differentiate between the timer stopping because of the stage ending VS player actions such as taking a death or pausing the game, but it works perfectly now. This is the most clear-cut route you can take with an autosplitter.

In terms of run validation, is it usually a issue? Would you want small things like in meatboy for example where there is a frame cycle you can track to combat video splicing. Or is that a non-issue, especially for a small title anyways?

Something like this certainly wouldn't hurt if it's easy enough for you to insert, but it's worth mentioning that if you're including features from the point above, this issue largely takes care of itself; if the runner's LiveSplit window is displaying information directly from game memory, such as when they finished each stage in a live run, this information is just about impossible to falsify or otherwise 'cheat'.

This a slightly broader question, but what do you guys enjoy most in speedruns? The discovery of new routes, so a broad game with lots of alternative ways of getting to the goal (like Mario odyssey before it gets "figured out") Skill and execution in a linear experience, so more like super meat boy, where the execution of each level is what matters and new tricks are of limited scope. Maybe something else entirely?

None of these will hurt your game as a speedgame. If people enjoy playing the game, they'll run it regardless of linearity or structure, so don't worry too much about this.

Edited by the author 5 years ago
Iglum, Guff and 4 others like this