You know, part of me doing Tub was to see what the other guys were up against when working on their prototypes. Why do we start projects, limp slowly forward for 2 years, then shut them down? Why arent they ended after a month? Why don't they pivot into something else? Why isn't anyone playing them?
One thing I feel like I'm discovering from Tub is that the internal playtests only work in specific ways. Internal tests reveal bugs, performance issues and they might sometimes throw up good ideas. They're kind of a mechnical test. It's like showing a computer a joke. It's going to spell check it, it's not going to let you know whether it's funny or not.
When you give your audience access to it you can see if they're having fun. You can see if your game works as a game - because people play it. They have ideas, they report problems. And not just for 10 minutes on the last friday of every month, it's every day, all times of the day and night.
This gets you into a positive feedback loop with everyone benefiting. The players are giving feedback, which inspires and motivates you as a game developer, which means more content for the players. This loop is the secret ingredient that made Garry's Mod and Rust.
Sometimes I have to step in and shut a project down. For the most part I like to give people enough rope to hang themselves. While it's a waste of time and not good business, it feels like a win win. Either the project turns into something or it's really obvious that it's going nowhere.
We had a situation like this with Rust. The early prototype dragged on. Stuff was being worked on that didn't need to be worked on. Code was constantly being refactored, days were spent coding tools that saved less than 10 minutes work, middleware was tested and swapped in and out regularly, time was spent optimizing code that was thrown away the next week.
I was on the verge of abandoning it but Helk was adament that it had potential, that it wasn't far off being playable. So I gave him a month to make it something we could release and get people playing. This laser focused the attention on everything that mattered. People played it, and liked it. It proved that the game shouldn't be abandoned.
So it seems that this is the missing ingredient in a lot of our prototypes. Players.
I'd encourage developers to give out keys and get people playing as soon as possible. This should make you focus on what matters and work towards providing the gameplay you're imagining.
This isn't about letting players dictate the direction of the game's development. Your role as a game designer is to design the game. If players find a certain aspect of the game too hard, you don't automatically make it easier. You gather information and make a decision on that. Maybe it's meant to be hard, maybe it's harder than you wanted and they're flagging a legit bug. But either way you wouldn't have known that players find that part "too hard" without letting them play.
I wanted to add a few new mechanics to the character controller before creating too much more content and having to go back and making it all work with the new moves. This feels like a good time to start exploring that.
There's other movement stuff I want to do here. Climbing (ladders, ropes, nets), ledge hanging, dive rolling, rope swinging etc. All the standard platformer stuff.
Jumping into a wall and pressing right mouse button will put you in a wall slide. This means that if I have the balls to add fall damage there'll be a way to counter it.
Standard platformer wall jumping. It's a bit tricky to do right now, because you need to go into a wall slide by right clicking when you hit the wall, then jump to wall jump.
This has already made it possible to break most of the levels we have.
You used to be able to jump up any wall less than 90 degrees. I added a slide mechanic to stop this. This broke a few things around the existing levels too, and has needed a lot of tweaking (and still isn't great).
Controller steps down small drops now. Previously it'd put you in a "fall", slowing down your run and making it feel awkward.
Controller can push things. I've only done the base logic so far, but you should be able to see the vector changes in the debug text on the video above. I've coded it so it knows how many players are pushing on it, and from which directions. This way we should be able to come up with shit that needs a certain number of players pushing on it (or one player that drank strong potion etc).
I tweaked around with inertia since it felt a bit off. This time it records the player's velocity over 8 frames, and the player's velocity minus its parent over 8 frames. Then when the player leaves a parent it tries to add to the player only the velocity from the parent.
The issue I'm battling is that I want inertia to work when stuff is rotating, so I can't just add the parent's velocity to the player because I need angular velocity too. I think I just solved the problem when typing that last sentence so I'll try again soon.
I had a problem that avatars weren't showing up in the scoreboard. After a bit of searching I found that Photon has an option called "PublishUserId" when creating a room. If it's set to false (default) you won't recieve the userid's of other players.
This meant that when you were on a server all other player's were showing up as userid = 0, so obviously their avatar wasn't working.
A few people have been asking about creating their own levels. That is something I want to enable at some point, but I don't want to derail stuff by creating an editor and a workshop system just yet.
I want us to get better at level design, so it's something I want to force us to do. I'm going to try to rope some of the team into trying to make levels, if no mega-stars emerge I'll look into hiring.
If you want to follow this project you can sign up to the mailing list.
We'll only update you about this project, we won't spam you about other stuff or sell your email address.