Hello there!
My name is Henrique, I'm from the PigDev channel.
I make some game development tutorial in Brazilian Portuguese. The link is in the description, please
do check it out :3
In this video we will talk about the design process of an infinity runner me and Nathan
developed.
First of all, let's talk about what makes a game an infinity runner.
Think about an endless game in which the major objective is just to score points based on
dodging obstacles now add a scrolling background to it.
Yep that's all that make an infinity runner.
And that's a problem, think about it for a second... what would you add to make the game
more enjoyable?
The mechanical constraints are so tight, we could make the character run, jump, maybe
sprint...and yeah, nothing funny.
At first, we thought about add some platform mechanics, like a jump, and basic character
movement.
It was supposed to be simple, so yeah, a platformer was simple enough.
But we immediately thought: we will need more action.
We needed add something to raise the player's actions per minute.
Then we thought: let's keep it simple, let's add a slide mechanic to help player avoid
the obstacles, the jump of course and let's try to make the player avoid some gaps on
the ground, if he falls, then is game over, also if he collides with the instantiated
objects he will die too.
It was at that moment that we thought about something that would completely change the
game and would add the action that we needed: a hook shot.
But, since implementing the stuff in Godot was my responsibility, and I had never programmed
this mechanic before, we chose to make the game so that before adding the hook, it would
play like any runner.
Due to time constraints, the game couldn't have a big scope, so we would have to make
the basics first and then, if time allowed us, we could add some other stuff.
To make this kind of development approach we tried to make everything as modular as
possible, in such a way that we could remove anything from the game, and everything else
would still work.
To do so we went up for this setup: both spawners are inherited from a basic spawner scene.
This is an awesome feature Godot offers, you can create a basic object, and start to build
more complex ones based on it.
It's kind of an Object-Oriented Design.
Both need a PackedScene that is used as reference to instantiate objects at runtime, so we could
make each one spawns different objects.
PackedScene handles saved scenes of your project.
This way, we can use it to load scenes at runtime.
In this case, the obstacles the player has to avoid.
About the player object now, that's something important.
I made it a Rigidbody2D, which is a class that uses Godot's built in physics engine
to apply forces to an object, and make it react to forces as well.
I went for it because I thought that by having all physics working without any code it would
be easier to make the behavior we wanted the character to have.
It was a lazy approach and we lost time with that.
The character was very bugged with some weird moves.
I should had listened to Nathan when he told me to code a KinematicBody2D, which is a class
that interacts with the physic engine, but does not use any built-in forces.
By coding it from zero, it would allow us have more control over the behavior.
Anyway, we ended up using it.
To be able to better fit our design approach, we used a simple state machine to handle the
character states.
This is very important: only use Finite State Machines if you have the need to do so.
In this case, we find out it would be good to have one since the character could only
be in one state at time and we had very few states, which were: RUNNING, JUMPING, HOOKING
and SLIDING.
Even if the hook wasn't implemented yet, but as I said, it could be.
About the loss conditions, I secretly implemented one.
Since the objects would be moving towards the player, I thought that it would be cool
if the character dies when hitting an obstacle from a horizontal collision.
Like if the obstacle and the character crashed, to give a feel of a dangerous speed crash.
And I removed the gap condition, because it wouldn't make sense to have a sliding mechanic
if anytime the player could slide to death.
After implementing everything we ended up with something like this.
Nothing compelling yet, to be honest.
This is the worse design scenario you can imagine, the game isn't fun, and we would
still add a feature... that's dangerous.
In most cases, you will want to go for a subtractive design, where you remove features until the
ones you have are already good and compelling.
But what would we remove from it?
I asked Nathan to give a chance to an additive by allowing the implementation of the hook
shot.
He agreed and I started to design it.
As I said I had never done this before, so I searched for references, and I remembered
Spiderman & Venom - Separation Anxiety, for super Nintendo.
And the ninja rope, from the Worms series.
I tried to replicate them.
To be honest, I should have looked for more references.
To implement it I stuck with the modular design, I made another scene, the hookgun, and created
some references for the player node.
After the first implementation of the hook mechanic this is how the game looked like.
Ok, the game has a new mechanic, it has potential to be more action based and dynamic.
But, as before, the player didn't have any incentive to use anything but the boring slide.
We realized it when I asked Nathan to evaluate the hook shot implementation...
He didn't say it, but I know he screamed a loud and clear "BORING" off screen.
Yeah, we needed to fix it.
Nathan suggested that we could make the player use the jump if we had stick with the plan
and make some gaps in the ground, so that the player would need to avoid them by jumping
on the spawned objects.
I didn't say to Nathan, but I prefer to give positive feedbacks to players so that they
pursue what the game offers by themselves, so they can receive more positive reinforcement
for using what we wanted them to use.
It's like a motivational thingy.
So instead of punishing the player for not jump a gap, I asked Nathan if we could add
a colletable mechanic, making every obstacle have an item attached to it that would increase
the player's score, if the player collect it.
But we were concerned about our time constraint, and we couldn't add more stuff to the game,
this would take some time to evaluate and polish, and the game wasn't near to be even
playable.
We needed to polish what we already had, and then add more stuff.
Besides that, I agreed with every word he said, I tried to implement the items to the
game, and since Nathan believed in the game potential and gave me a greenlight to tweak
the game, I opted to add more stuff.
Please, do not follow my bad example.
After implement the whole thing, and fix some other stuff Nathan wisely pointed, like the
feel that the hook was sliding on the ceiling, instead of attaching itself to it.
This was the final implementation we had, before Nathan makes his sorcery Now it was
looking more like a playable thing.
The player now had to effectively move to increase the score, and then compete with
his/her friends.
The player would have to use everything to collect as many points as possible.
I'm very happy that I could collaborate with Nathan in this project, I really hope that
we can do this again sometime.
That's all for now, guys, I hope you enjoy, please hit the like button and keep developing!
Không có nhận xét nào:
Đăng nhận xét