I'm building a game for speedrunning. I don't speedrun. You do. Help?

2015-06-07 06:46:12 pm

So, I was inspired by Super House of Dead Ninjas, which includes a split timer at the top, and I decided to make a similar game.

There are some things which, obviously, I need to leave to chance (like random generation). But there are other things, like player weapons, that I could randomize but I don't want to discourage speedrunners because they have to restart a million times to get the Hero and weapons that they want...

As of yet, it's similar to SHoDN from a game mechanic perspective - a falling platformer with a world randomly generated from a fixed set of rooms.

Now, what do you all think is the best way to handle player selection, weapons (built in to hero, random drops in rooms, etc.), and anything else you can think of.

This is YOUR chance to have an impact on a game, first hand, so feel free to say literally anything! I'm open to any and all ideas Smiley

Thanks!

Thread title:

Crow!

2015-06-08 01:25:46 pm

What's that gemma?

The questions you ask are too broad. You're effectively asking for someone to do most of the game design for you, even if you didn't mean to do that.

The important thing for a speed run is that the game is fun. If people want to play the game over and over, they'll use a timer to measure how well they did each time. So, my suggestion is to work on making a good game, and not worry so much about speed runners specifically.

HallaSurvivor

2015-06-08 05:29:54 pm

Thanks. I didn't realize I had posed it that way, but now that you point it out, it does look like that. I'll build the game a little bit more, and maybe I'll come back when I have something more specific to the community (which I do still plan to cater to, I love watching the skill great speedrunners exhibit).

Thank you for your time Smiley

charleon

2015-06-09 12:26:24 am

What is a man?

Basically what Crowl says, although this part struck me a bit: "a falling platformer with a world randomly generated from a fixed set of rooms.". As we have no information about how you're going to do this at the moment wouldn't this mean that for every playthrough, the spawn of said rooms would be the major factor in how a good time you would get? which would make it extremely RNG heavy to get a good time. In the speedrunningworld you might not get the full attention you would want since some runners (such as me), empathize skill and execution and try to avoid RNG if i can help it. If you manage to do it in a really awesome way though, please go for it!

Sir VG

2015-06-09 04:53:40 am

Fucking Weeaboo

Frankly, I don't think you should develop a game with a speedrunner in mind. Develop it for ALL gamers in mind. The speedrunning community will find ways to play and break every game.

Just take basic things into consideration, like the ability to skip cutscenes or easy ways to skip/speed through dialogue, and make sure the timer is accurate (if you include one).

HallaSurvivor

2015-06-09 11:02:43 am

Sir VG - That's a really good point, actually. It seems like the general theme of this thread is "you don't need to cater to speedrunners as much as you think you do", which is cool. It gives me a lot more freedom :).

charleon - As it stands, the rooms are picked so as to discourage multiple easy rooms in a row, and the rooms are all about the same length. I've been getting consistent times throughout testing, so I don't think that (at the moment) the pseudorandom generation would be a major discouragement to getting a fast time. The main reason I included it is because I find games that are the same every time to be boring, and this lets speedrunners have consistency in room structure (provided you recognize the room you're in quickly enough) while still making the world a unique experience every playthrough. If you have any suggestions for making things more skill-based, I would love to hear them! Smiley

Thanks again, guys. This is helping a lot.

ais523

2015-06-10 08:19:57 am

There are lots of little things you can do to make life easier for speedrunners (things like making all cutscenes skippable, having unlimited save slots and a "copy save" command, etc.), but you can normally add those on after the game's already been made; they're more on the level of details, rather than the level of game design.

As for randomness, it can certainly keep a game fresh. However, the problem is that many runners aim for world record times. Once someone's got a good run of a good layout, that means that nobody can match it unless they happen to get a layout that's at least as good, which can rather discourage competition. (See, for example, the current Spelunky any% WR; the runner who got it basically explained it as "this is why I don't like any%", because it was only possible due to a huge amount of luck in level layouts.) I'm not sure if there's much you can do about this except always having the same rooms but in a different order each time (which won't eliminate the impact of luck, but will reduce it at least).

There are lots of little things you can do to make life easier for speedrunners (things like making all cutscenes skippable, having unlimited save slots and a "copy save" command, etc.), but you can normally add those on after the game's already been made; they're more on the level of details, rather than the level of game design.

As for randomness, it can certainly keep a game fresh. However, the problem is that many runners aim for world record times. Once someone's got a good run of a good layout, that means that nobody can match it unless they happen to get a layout that's at least as good, which can rather discourage competition. (See, for example, the current Spelunky any% WR; the runner who got it basically explained it as "this is why I don't like any%", because it was only possible due to a huge amount of luck in level layouts.) I'm not sure if there's much you can do about this except always having the same rooms but in a different order each time (which won't eliminate the impact of luck, but will reduce it at least).

Melodia

Edit history:

Melodia: 2015-06-10 01:27:25 pm

2015-06-10 01:27:04 pm

Now....one way to fix the above is to made seeds selectable and keepable. That is, you can input a seed number and get a consistent map, and on top of this make sure if a good seed IS found randomly it's not lost and can be written down, or even saved in the save file.

BadJim

2015-06-11 05:28:40 pm

As others have said, don't design a game around speedrunning. Make a fun game and speedrunners will play it regardless. However, there are a few things that make speedrunning easier.

1) A recording feature. The most common way is to record the players' inputs. You need to make sure that everything that can affect the game is recorded, including, for example, seeds for random number generators. Third party libraries may be an issue here, as a physics engine that uses random numbers internally and seeds from the system timer may give you different results from the same input and you'll have no idea why. This is worth doing regardless of whether you think the player should have it as it is an excellent debugging tool.

2) A built in timer. For PC games without timers, loading times are excluded so there is not a contest of who can afford the fastest hard drive. Accounting for loading times can get tiresome though. This timer should be reliable, it should be accurate to the frame, and it should be reasonably close to SDA timing rules, counting all time that can be considered gameplay (Braid, for example, counts time spent in levels but not time spent solving jigsaw puzzles, which should count) and not counting things that SDA excludes, like loading times.

3) Skippable cutscenes. When you are on your hundredth playthrough, you really don't want to sit through cutscenes. People watching a speedrun want to see the game being played quickly. Also avoid locking the player in a room and dumping exposition like in Half Life 2, that's still an unskippable cutscene for practical purposes (although HL does have a way to speed it up slightly).

4) Allow the player to remove or mitigate random elements that drastically affect completion time. If the environment is randomly generated, allow the player to set a seed. If there is random loot, maybe do something similar to Bubble Bobble, where bonuses appear to be random but are all triggered by player actions. AdamAK wasted a lot of time in his SGDQ13 Vice City run trying to find a specific car in random traffic, which is an example of what you don't want.

As others have said, don't design a game around speedrunning. Make a fun game and speedrunners will play it regardless. However, there are a few things that make speedrunning easier.

1) A recording feature. The most common way is to record the players' inputs. You need to make sure that everything that can affect the game is recorded, including, for example, seeds for random number generators. Third party libraries may be an issue here, as a physics engine that uses random numbers internally and seeds from the system timer may give you different results from the same input and you'll have no idea why. This is worth doing regardless of whether you think the player should have it as it is an excellent debugging tool.

2) A built in timer. For PC games without timers, loading times are excluded so there is not a contest of who can afford the fastest hard drive. Accounting for loading times can get tiresome though. This timer should be reliable, it should be accurate to the frame, and it should be reasonably close to SDA timing rules, counting all time that can be considered gameplay (Braid, for example, counts time spent in levels but not time spent solving jigsaw puzzles, which should count) and not counting things that SDA excludes, like loading times.

3) Skippable cutscenes. When you are on your hundredth playthrough, you really don't want to sit through cutscenes. People watching a speedrun want to see the game being played quickly. Also avoid locking the player in a room and dumping exposition like in Half Life 2, that's still an unskippable cutscene for practical purposes (although HL does have a way to speed it up slightly).

4) Allow the player to remove or mitigate random elements that drastically affect completion time. If the environment is randomly generated, allow the player to set a seed. If there is random loot, maybe do something similar to Bubble Bobble, where bonuses appear to be random but are all triggered by player actions. AdamAK wasted a lot of time in his SGDQ13 Vice City run trying to find a specific car in random traffic, which is an example of what you don't want.

presjpolk

Edit history:

presjpolk: 2015-06-12 07:28:19 am

2015-06-12 07:28:04 am

HELLO!

If you really want to make it a fun speedrun, test it. Hard. By people who break games. Fix the bugs.

Release it when it's freaking ready, so that runners don't have to deal with a dozen patches that each break the route.

And make sure none of the music and sound are annoying.

Partystar

Edit history:

Partystar: 2015-06-12 08:51:30 am

Partystar: 2015-06-12 08:45:26 am

Partystar: 2015-06-12 08:41:36 am

2015-06-12 08:40:56 am

I also agree with SirVG. Most games were probably not designed with speedrunning in mind at all. But there are maybe things that could make a game more fun or interesting to speedrun. I would go for an interesting set of mechanics. Especially the controls are important. Mechanics such as sliding and dashing in Mega Man 3 and Mega Man X respectively, make the games more faced paced. Acrobatic moves such as in Mario 64 provide a lot of dynamics to the game. But even more static games can be interesting speedruns, such as Ninja Gaiden. I think it doesn't have a speedup mechanic but the way you use the sword, the tricky jumps and the fact the game is considered fairly hard makes it interesting. Contra games are fairly simplistic too but the gun allows for planning you shots ahead. With Super Castlevania and Rondo of Blood (Richter) you have the cross and axe respectively to clear your path. In the end people speedrun everything or find a way to do it.
Also what pressjpolk said, the music is important too. If it has a killer soundtrack, that alone could draw in many people to repeatedly play a game. To me that's where speedrunning starts, the replay value of a game determines whether I find it worth putting more effort in it or not.

SilverViper

2015-06-12 01:39:27 pm

As a game developer myself, I would recommend you to focus on the "fun" part more than anything else. If you put all the pieces together like you would normally do (story, game elements, learning curve, etc.) and do them right, people will like your game and will want to play. That's the main thing to think about. The rest is mostly adding extra stuff for runners, like BadJim said, things like a built in timer or record features could be nice add-ons to your game but they should not alter the fun.

HallaSurvivor

Edit history:

HallaSurvivor: 2015-06-14 09:53:53 pm

2015-06-14 09:39:36 pm

Thank you all for your responses! This is helping a lot Smiley

ais - The problem with randomness is exactly what I came here to mitigate, as I figured speedrunners have encountered this before, and would have a solution

Melodia - Thank you for providing that solution! I would have NEVER considered seeds, but it's a great way to let people play the same map if they so choose, but keep
it random for the people who want that Smiley

BadJim -
1) I'm not sure I understand the reasoning behind a recording feature. If I better understood why I needed it, I could implement it better. Would you care to elaborate?
2) The game already has a timer, thankfully. Although, the bit about loading times is something I would have never considered! I'll also make it a point to look at
SDA rules to see what else to consider Smiley

thank you!
3) I will definitely add a way to skip cutscenes if I ever add any, as that seems to be a common one.
4) What do you mean by "determined by player action" ? Like, the buttons the player pressed is what causes certain loot to spawn in chests?
As it stands, I'm generating all of the loot at the start of the level, so it would be easy to include loot spawns as a seed... Once I add in random
drops from enemies, though, I'll think about a way to make it consistent as well. Smiley

presjpolk - I was planning on testing it with friends, but they probably wouldn't try to break it. Would I do that in a beta-esque stage? Or would that constitute "releasing" it, do you think?
As for music, I certainly don't think it's annoying, haha... I guess I'll get opinions once other people try it Smiley

Partystar - I feel like my controls are pretty good, but I don't play enough games to know for sure. As for mechanics, I'm definitely adding dashing, and I'll try to keep interesting mechanics at the front of my mind as I make others. I might come here asking what people think about a particularly strange one, if nobody minds Smiley

Finally, the replay value. I had thought about this, but
never consciously. I definitely think it's fun to replay, but I'll ask some of my friends what they think as well.

SilverViper - I feel like the theme of this thread is to not focus on speedrunning, because you all are crazy and will figure out how to break the game whether I let you or not, which is awesome. I'm planning to keep fun at the forefront of the design, particularly because I'm doing a lot of testing myself, and I might as well enjoy myself while doing it Tongue

Thanks again for all the responses! I feel like every time I check the forum I learn more and more useful tips Smiley

Thank you all for your responses! This is helping a lot :)
ais - The problem with randomness is exactly what I came here to mitigate, as I figured speedrunners have encountered this before, and would have a solution

Melodia - Thank you for providing that solution! I would have NEVER considered seeds, but it's a great way to let people play the same map if they so choose, but keep
it random for the people who want that :)

BadJim - 
1) I'm not sure I understand the reasoning behind a recording feature. If I better understood why I needed it, I could implement it better. Would you care to elaborate?
2) The game already has a timer, thankfully. Although, the bit about loading times is something I would have never considered! I'll also make it a point to look at 
SDA rules to see what else to consider :) thank you!
3) I will definitely add a way to skip cutscenes if I ever add any, as that seems to be a common one. 
4) What do you mean by "determined by player action" ? Like, the buttons the player pressed is what causes certain loot to spawn in chests? 
As it stands, I'm generating all of the loot at the start of the level, so it would be easy to include loot spawns as a seed... Once I add in random
drops from enemies, though, I'll think about a way to make it consistent as well. :)

presjpolk - I was planning on testing it with friends, but they probably wouldn't try to break it. Would I do that in a beta-esque stage? Or would that constitute "releasing" it, do you think?
As for music, I certainly don't think it's annoying, haha... I guess I'll get opinions once other people try it :)

Partystar - I feel like my controls are pretty good, but I don't play enough games to know for sure. As for mechanics, I'm definitely adding dashing, and I'll try to keep interesting mechanics at the front of my mind as I make others. I might come here asking what people think about a particularly strange one, if nobody minds :) Finally, the replay value. I had thought about this, but
never consciously. I definitely think it's fun to replay, but I'll ask some of my friends what they think as well.

SilverViper - I feel like the theme of this thread is to not focus on speedrunning, because you all are crazy and will figure out how to break the game whether I let you or not, which is awesome. I'm planning to keep fun at the forefront of the design, particularly because I'm doing a lot of testing myself, and I might as well enjoy myself while doing it :P

Thanks again for all the responses! I feel like every time I check the forum I learn more and more useful tips :)

presjpolk

2015-06-15 07:34:39 am

HELLO!

I think putting out a 'beta' once it's done, sending it out to people who are good at breaking games, before making the final release, would be excellent.

Lone_Kilted_Ninja

2015-06-17 04:53:54 pm

Anything you can do I can do halfass

Having done a bit of this myself, BadJim's points are golden.

Also, having TESTED a game of my own on speedrunners a few GDQs ago, I can definitely say
- avoid things which move intentionally slowly (e.g. pushable blocks which slow the character to <half speed)
- avoid undue repetition of segments/areas (although this is also a good "make it fun" rule)
- so far as mitigating randomness in an action game, I've generally worked under the theory of trying to make the RNG reproducible if the exact same inputs are entered with the exact same timing. This probably means you need to go oldschool and avoid system rand() calls in favor of your own random number table or algorithm
- the bigger RNG issue, however, is basically just one of overall game design. If RNG, particularly late-game, can make it so that a player needs to wait X amount of time regardless of skill (e.g. "boss goes into consecutive invincible attack pattern" or "room generator puts the exit waaay out in the boonies"), that's going to be a frustration point that casual players will probably "meh" right past but runners will be frustrated by
- so far as recording, I've never thought to add this, but the value I would imagine is in cutting out all ambiguity during practice/research runs: if you see something worked well, you can re-examine it / re-try it to figure out what made it go well, ideally without needing to capture full-frame video feed of every run. Back in the day, that was probably called "cheating," but as a feature request for a dedicated niche audience, it's perfectly valid Smiley

And as far as release/test timing, always figure out what you want to learn from the test (but be ready to observe players and note things you didn't expect), and weigh the value you'll get from the test against how much it will inconvenience players to get at and play the game. I've seen no fundamental harm in dropping specific builds to friends or maintaining a "latest" link on a web forum, but be aware that any "release," even a soft alpha/beta/demo, is a public face of your game to someone. If one build is garbage because you left out key functionality or failed to address painfully-obvious bugs in your own pre-testing "because it was just a beta/demo", it'll likely put players off to trying the next build. Industry-standard "beta" I believe still implies "expected-feature-complete and at least partially tested; just missing perhaps certain content and polish," so if you're going to put out less than that, be sure to constrain both what the player even has access to and what you specifically want them to try and give feedback on.

Having done a bit of this myself, BadJim's points are golden.

Also, having TESTED a game of my own on speedrunners a few GDQs ago, I can definitely say
- avoid things which move intentionally slowly (e.g. pushable blocks which slow the character to <half speed)
- avoid undue repetition of segments/areas (although this is also a good "make it fun" rule)
- so far as mitigating randomness in an action game, I've generally worked under the theory of trying to make the RNG reproducible if the exact same inputs are entered with the exact same timing.  This probably means you need to go oldschool and avoid system rand() calls in favor of your own random number table or algorithm
- the bigger RNG issue, however, is basically just one of overall game design.  If RNG, particularly late-game, can make it so that a player needs to wait X amount of time regardless of skill (e.g. "boss goes into consecutive invincible attack pattern" or "room generator puts the exit waaay out in the boonies"), that's going to be a frustration point that casual players will probably "meh" right past but runners will be frustrated by
- so far as recording, I've never thought to add this, but the value I would imagine is in cutting out all ambiguity during practice/research runs: if you see something worked well, you can re-examine it / re-try it to figure out what made it go well, ideally without needing to capture full-frame video feed of every run.  Back in the day, that was probably called "cheating," but as a feature request for a dedicated niche audience, it's perfectly valid :)

And as far as release/test timing, always figure out what you want to learn from the test (but be ready to observe players and note things you didn't expect), and weigh the value you'll get from the test against how much it will inconvenience players to get at and play the game.  I've seen no fundamental harm in dropping specific builds to friends or maintaining a "latest" link on a web forum, but be aware that any "release," even a soft alpha/beta/demo, is a public face of your game to someone.  If one build is garbage because you left out key functionality or failed to address painfully-obvious bugs in your own pre-testing "because it was just a beta/demo", it'll likely put players off to trying the next build.  Industry-standard "beta" I believe still implies "expected-feature-complete and at least partially tested; just missing perhaps certain content and polish," so if you're going to put out less than that, be sure to constrain both what the player even has access to and what you specifically want them to try and give feedback on.

HallaSurvivor

2015-06-21 12:03:53 pm

presjpolk - Sounds fair enough. I'll see if I can find these game breakers of whom you speak Wink

Lone_Kilted_Ninja - Thanks so much for the ideas! For the random mitigation, I'm pretty invested in seeds at this point, but I have everything in the world generated at the beginning based on that seed, so I think it's working out without me making my own table (thank any god you choose). I've been tossing around ideas for a boss, so that particular insight is going to be quite useful Smiley

As for recording, I didn't realize speedrunner went to that much effort, with researching and such. Knowing that, it makes a lot of sense as to why you'd want the feature, as well as why you're so much better than me, haha. I'll start working on it soon.
The test releases bit had some very good points in it, and I'll definitely keep it in mind. I'd release a working copy here (pretty early alpha), but I'm not sure if I want to end up releasing it for money or not. I don't want to, but my partner does, so we're still debating it.

Thanks again everybody for the input, and while we're here, I had a quick question:

my timer is running based on game ticks, and my clock is set to 60. Is there anything fundamentally wrong with having 60ths of a second as the smallest unit of time, or should I move to centiseconds?
Thanks in advance!

presjpolk - Sounds fair enough. I'll see if I can find these game breakers of whom you speak ;)

Lone_Kilted_Ninja - Thanks so much for the ideas! For the random mitigation, I'm pretty invested in seeds at this point, but I have everything in the world generated at the beginning based on that seed, so I think it's working out without me making my own table (thank any god you choose). I've been tossing around ideas for a boss, so that particular insight is going to be quite useful :)
As for recording, I didn't realize speedrunner went to that much effort, with researching and such. Knowing that, it makes a lot of sense as to why you'd want the feature, as well as why you're so much better than me, haha. I'll start working on it soon.
The test releases bit had some very good points in it, and I'll definitely keep it in mind. I'd release a working copy here (pretty early alpha), but I'm not sure if I want to end up releasing it for money or not. I don't want to, but my partner does, so we're still debating it.

Thanks again everybody for the input, and while we're here, I had a quick question:

my timer is running based on game ticks, and my clock is set to 60. Is there anything fundamentally wrong with having 60ths of a second as the smallest unit of time, or should I move to centiseconds? 
Thanks in advance!

LiamPiper

2015-06-21 01:44:25 pm

Personally I would release an alpha so us speedrunners can test it whilst you are still developing the game and as more levels are completed we can test it more.
Then when you feel once you got the game in a complete state, then distribute the betas out so we can test the game as a whole game.
Then release the game.
But anyways, i am up for testing your game when you need people to test it.

HallaSurvivor

2015-06-23 07:17:39 pm

ok, as far as recording goes: I've made it so that it logs keypresses/chest openings/damage alongside the time at which it happens. It's of the form:

2015-6-23; 21:15:32,558 - Hero Damaged
2015-6-23; 21:15:32,977 - HP: 234/250
2015-6-23; 21:15:33,187 - [LEFT] pressed

is this enough? If not, what else does it need?.

Thanks again!

BadJim

2015-08-02 10:13:43 am

You don't need to record things like "hero damaged" or changes to his hitpoints. If you replay the game using the recorded inputs, the engine can determine when the hero takes damage and how much damage.

Some of us do have high refresh rate monitors, like 120Hz or 144Hz. Locking a game to 60fps isn't a massive problem, but going higher would be nice. I'd run the game at 120 ticks/sec, not 100, as 120 evenly divides 60, which the majority of players will use.

I should point out that speedrunners don't all 'love' gamebreaking bugs, we just accept them because it is impractical to outlaw bug abuse in the general case. Most games actually have so many bugs that you cannot beat the game without triggering one. It is simpler to allow all bugs by default and have separate categories where specific gamebreakers are banned.

My reasoning behind a recording feature is simply that it is easier to record. Using Fraps requires an enormous amount of HD space, slows the game down while you are playing it, allows slowdowns and AIM popups to spoil the recording, and if performance concerns cause you to play at 640x480 resolution on the lowest detail settings then everyone who watches it must also suffer those settings. But if the game has a recording feature that stores the player inputs, this needs only a tiny amount of HD space, has minimal performance cost, allows viewers to watch at whatever quality their PC can handle and any performance problems that happened during the original run will only affect the replay if they caused the runner to play badly. Someone with a good PC can turn your WR run into a good movie even if you can't.

By "determined by player action" I mean that in Bubble Bobble you can cause bonus items to appear by doing specific, arbitrary things. If you pop 25 water bubbles for instance, you get a purple umbrella that takes you forward 7 screens
http://tjasink.com/games/bb/items2.html
http://game-oldies.com/play-online/bubble-bobble-coin-op-arcade#
What's important is that while these items may appear random to the average player, a speedrunner does not have to pray to the RNG god for useful items. But having loot spawns determined by the starting seed is also a good way to avoid randomness.

You don't need to record things like "hero damaged" or changes to his hitpoints. If you replay the game using the recorded inputs, the engine can determine when the hero takes damage and how much damage.

Some of us do have high refresh rate monitors, like 120Hz or 144Hz. Locking a game to 60fps isn't a massive problem, but going higher would be nice. I'd run the game at 120 ticks/sec, not 100, as 120 evenly divides 60, which the majority of players will use.

I should point out that speedrunners don't all 'love' gamebreaking bugs, we just accept them because it is impractical to outlaw bug abuse in the general case. Most games actually have so many bugs that you cannot beat the game without triggering one. It is simpler to allow all bugs by default and have separate categories where specific gamebreakers are banned.

My reasoning behind a recording feature is simply that it is easier to record. Using Fraps requires an enormous amount of HD space, slows the game down while you are playing it, allows slowdowns and AIM popups to spoil the recording, and if performance concerns cause you to play at 640x480 resolution on the lowest detail settings then everyone who watches it must also suffer those settings. But if the game has a recording feature that stores the player inputs, this needs only a tiny amount of HD space, has minimal performance cost, allows viewers to watch at whatever quality their PC can handle and any performance problems that happened during the original run will only affect the replay if they caused the runner to play badly. Someone with a good PC can turn your WR run into a good movie even if you can't.

By  "determined by player action" I mean that in Bubble Bobble you can cause bonus items to appear by doing specific, arbitrary things. If you pop 25 water bubbles for instance, you get a purple umbrella that takes you forward 7 screens
http://tjasink.com/games/bb/items2.html
http://game-oldies.com/play-online/bubble-bobble-coin-op-arcade#
What's important is that while these items may appear random to the average player, a speedrunner does not have to pray to the RNG god for useful items. But having loot spawns determined by the starting seed is also a good way to avoid randomness.

Vibex

2015-08-02 10:36:46 am

I would implement it similarly to the way Binding Of Isaac Rebirth did. You can't unlock things or get acheivments in seeded runs, but you can still play through it.

One thing I haven't seen mentioned is making sure your code isn't to strong. And by this I don't mean filled with bugs. Thats just dumb and makes the game less enjoyable for everyone. What I mean is, for example, if there are 5 collectables in a level and the player some how gets 6 in his inventory don't softlock the game. Your not giving players a way break the game, but you also aren't punishing speedrunners if they find a way to break it anyway.

BadJim

2015-08-02 02:40:18 pm

Quote from Vibex:

One thing I haven't seen mentioned is making sure your code isn't to strong. And by this I don't mean filled with bugs. Thats just dumb and makes the game less enjoyable for everyone. What I mean is, for example, if there are 5 collectables in a level and the player some how gets 6 in his inventory don't softlock the game. Your not giving players a way break the game, but you also aren't punishing speedrunners if they find a way to break it anyway.

If there are 5 collectables and you somehow get 6, the behavior of the program is usually undefined. If it softlocks, it is because the programmer didn't consider it at all. Spending time making the game handle impossible situations gracefully is wasteful. Real games will have thousands of known bugs that actually occur in play, which is what the programmer should be doing.

Vibex

2015-08-02 02:52:16 pm

Quote from BadJim:

Quote from Vibex:

One thing I haven't seen mentioned is making sure your code isn't to strong. And by this I don't mean filled with bugs. Thats just dumb and makes the game less enjoyable for everyone. What I mean is, for example, if there are 5 collectables in a level and the player some how gets 6 in his inventory don't softlock the game. Your not giving players a way break the game, but you also aren't punishing speedrunners if they find a way to break it anyway.

If there are 5 collectables and you somehow get 6, the behavior of the program is usually undefined. If it softlocks, it is because the programmer didn't consider it at all. Spending time making the game handle impossible situations gracefully is wasteful. Real games will have thousands of known bugs that actually occur in play, which is what the programmer should be doing.

I wordered it poorly. I'm not talking about making it handle it gracefully. I'm currently a game dev student, and I'be seen a lot of my fellow students forced their games to hard quit with errors in situations like that. I didn't mean to imply that you should waste effort on trivial unlikely bugs.

[quote="BadJim"][quote="Vibex"]One thing I haven't seen mentioned is making sure your code isn't to strong. And by this I don't mean filled with bugs. Thats just dumb and makes the game less enjoyable for everyone. What I mean is, for example, if there are 5 collectables in a level and the player some how gets 6 in his inventory don't softlock the game. Your not giving players a way break the game, but you also aren't punishing speedrunners if they find a way to break it anyway.
[/quote]

If there are 5 collectables and you somehow get 6, the behavior of the program is usually undefined. If it softlocks, it is because the programmer didn't consider it at all. Spending time making the game handle impossible situations gracefully is wasteful. Real games will have thousands of known bugs that actually occur in play, which is what the programmer should be doing.[/quote]

I wordered it poorly. I'm not talking about making it handle it gracefully. I'm currently a game dev student, and I'be seen a lot of my fellow students forced their games to hard quit with errors in situations like that. I didn't mean to imply that you should waste effort on trivial unlikely bugs.

ais523

2015-08-04 03:35:56 pm

You want the game to react gracefully to any situation that might happen through glitch. For example, suppose you're making a Metroid clone. If someone gets items out of order, the game should just give them the items they've collected (and no other items), or if you're worried about this making the game unwinnable, make the game give someone all the items they're meant to have at a given point whenever they reach it. What you shouldn't do is have the game softlock because someone reaches an item earlier than they're supposed to, or give some other item instead, or whatever.

HallaSurvivor

2015-08-10 02:18:45 am

Those are all really good points to consider, Vibex/BadJim/ais523. I'll be sure to keep them in mind while making assumptions in the code Smiley

Also, I started another forum here: https://forum.speeddemosarchive.com/post/im_making_a_game_and_would_love_some_alpha_testers._any_takers.html

it has links to the current release of the game, etc, if anybody wants to give it a go Smiley

Thanks again!

dangodofthunder

2015-08-11 04:45:35 pm

If you haven't, watch the Extra Credits video about catering games for speedrunners.

If you don't want to, the best way to describe it is this. We'll find good games. We're some of the most educated, knowledgeable, and insightful consumers of video games on the planet. For games we speedrun, we often know the games better than the creators themselves do. You absolutely do NOT need to pander to us in any way, shape or form. If you want to make a game for speedrunning, simply make a game that we'll want to play for thousands upon thousands of hours and we'll go from there. Adding things like speedrun timers and such help, but they're not WHY we'll pick up a game.