Savanna Sam: Browser 3D Action Game

[MaxDidIt]

This is the first game project after taking a break from making games for several years.

For a while now, I had this idea of a cartoon giraffe flying a comically tiny airplane stuck in my head. At last, I sat down and drew a character design:

I like how "vertical" the design of this character is. It's an unusual silhouette for anything airborne. I liked the character, so I proceeded to create a 3D model based on it:

Now that I have the 3D model, I want to try and make a game with it!

I've already created a working animation rig for the character in Blender!

And I've already taken the first steps and implemented some very basic gameplay.

• I'm using three.js to render the 3D graphics in the browser
• I'm using cannon-es for collision detection
• I'm using three-nebula for particles

Currently, I only have a test level where randomly placed boxes are thrown at you, but for the moment this is enough to test out movement and basic mechanics like avoiding obstacles.

I already really like the dynamic animations of the neck, it is a very satisfying feedback to the player's actions!

It's very much a work in progress, but you can already faintly see where this might be going.

[3p0ch]

Looking forward to seeing it! I'm a fan of flight and my first 3D game was a flight sim (Espionage), although I used Godot and wouldn't be able to pull off something like that in Javascript. Feel free to shoot the breeze with me while you're working on it.

[MaxDidIt]

I’m developing the game to run in browsers, to make sure it’s quick and easy to access it. Another step to make sure it reaches a broad audience is to implement control schemes for different platforms.

I expect mouse and keyboard to be the most common control scheme for playing the game. You use the keyboard to control the airplane, while the mouse is used to let our giraffe pilot to roll into the desired direction. I’m using the browser’s pointer lock feature to capture the mouse and then to simulate behaviour similar to an analog stick.

I myself like to sit on my couch and play on my iPad, so it just makes sense to also implement touch controls. I’ve implemented on-screen analog sticks which already work quite nicely. The analog sticks appear wherever the player touches the respective half of the screen, which makes it more comfortable to play the game, since it adjusts to your preferred finger placement.

Having touch controls on a tablet means that technically, you can play the game on a phone, as well. I’ll be honest though, I don’t know if I’ll be able to design the game in a way that works well on small screens…

I was delighted to learn that you can use game pads in browsers! I’ll be honest, I didn’t know that all modern browsers support game pad input, but I’m very happy they do. This means that you’ll have the option of using a game pad when playing the game on your PC.

[larrynachos]

Such a creative mechanic! I'm excited for this project!

[tydaze]

It seems like you could simplify the controls a bit more.

Something like WASD for controlling the plane's position, right arrow key for clockwise rotation and left arrow key for counter-clockwise rotation.

I think it would be more accessible that way. Though, it would have the downside of not being able to control the speed of rotation manually. So I guess it depends on how complex you want the controls to be.

[MaxDidIt]

At 2/17/24 05:13 PM, larrynachos wrote: Such a creative mechanic! I'm excited for this project!

Thank you! I'm so happy to hear that! I will post any news to this thread!

[MaxDidIt]

At 2/18/24 01:39 AM, tydaze wrote: It seems like you could simplify the controls a bit more.
Something like WASD for controlling the plane's position, right arrow key for clockwise rotation and left arrow key for counter-clockwise rotation.

I think it would be more accessible that way. Though, it would have the downside of not being able to control the speed of rotation manually. So I guess it depends on how complex you want the controls to be.

Thank you for the feedback! I gave it a shot and did a quick implementation of a version of the controls you suggested:

My impression is: Yes it, could work. You have to get used to it, of course. Especially if you are flying upside down, in order to rotate the head to the right, you have to press the left arrow button, since you still would want to rotate counter-clockwise. But that is something players would likely learn after a short while.

However, I wonder if it is more intuitive? With the present control scheme, you basically just point in the direction you want the head of the pilot to point towards.

• If I move the mouse/stick in the upper left direction, the head will point to the upper left direction as well,
• If I move the mouse/stick to the right, the head will move to point to the right,
• etc.

In comparison, while the alternative control scheme uses fewer buttons, it feels a bit more indirect to me.

However, I will keep the code in the game for now. Once the game is at a point where I feel comfortable having other players test it, I can make that one of the things that people can experiment with. And in the end, it can always be an option in the settings menu. :-)

[Czyszy]

I'm posting here just to let you know that I'm amazed by how cool this anthro character design is IMO! Just perfect! OwO

[MaxDidIt]

At 2/18/24 07:03 AM, Czyszy wrote:
I'm posting here just to let you know that I'm amazed by how cool this anthro character design is IMO! Just perfect! OwO

Thank you so much! I like the design as well, so much so that I'm basing a game on it! :-)

[3p0ch]

Yes, gamepads can work in browsers, but they're a bit tricky. Some testing I did when I was making Quad revealed that different controllers on different hardware can generate different JavaScript signals, and in particular the cheepest Switch controller I could find when I was making that game confused the heck out of Godot's web export. Maybe XBox and PlayStation controllers are more consistent but IDK for sure.

The solution I came up with was to write some code to make the browser ask the player to move all the axes and push all the buttons on their controller while it listens, and store which signal belongs to which axis/button, so the game can map things correctly. It might make more sense to see it in action -- I used it in Quad (made in Godot) so you can see how it works, and also wrote examples of how to do it in other engines/frameworks including an example with pure JavaScript and linked to the source code. Unfortunately the D-pad seems to usually get mapped as an axis instead of a button on most controllers, and I haven't found a graceful way of handling it, so I just haven't used the D-pad.

When I originally wrote it, my plan was to take advantage of the fact that data in LocalStorage is shared among all pages from a domain. That means that if one "game" on NewGrounds goes through the gamepad configuration process, then every other game on the site could read the configuration data, so a player would only need to configure their gamepad once on NewGrounds and any game that wants to read the data could read it. I also posted that tool at Itch in case anyone wanted to use it there. But I think that browsers might change in the not-too-distant future so that each individual webpage and not the entire domain will have its own LocalStorage data, in which case if you use it you might want to download the gamepad configuration page's source code too (which different from the source code showing how to read the configuration data that it generates and use it in your game) and include it in your own project too.

[MaxDidIt]

At 2/18/24 08:14 PM, 3p0ch wrote: Yes, gamepads can work in browsers, but they're a bit tricky. Some testing I did when I was making Quad revealed that different controllers on different hardware can generate different JavaScript signals, and in particular the cheepest Switch controller I could find when I was making that game confused the heck out of Godot's web export. Maybe XBox and PlayStation controllers are more consistent but IDK for sure.

That's true! Usually, I test the game with an old XBox 360 controller, and that works fine.

However, I tried to connect a Switch Pro controller to my PC and play the game with that and that didn't work at all. To be fair, that might not be the browsers fault, Switch controllers seem to be tricky to get to work with PCs in general. Even after installing some custom drivers, the browser would still be confused with the input it was getting.

The solution I came up with was to write some code to make the browser ask the player to move all the axes and push all the buttons on their controller while it listens, and store which signal belongs to which axis/button, so the game can map things correctly. It might make more sense to see it in action -- I used it in Quad (made in Godot) so you can see how it works, and also wrote examples of how to do it in other engines/frameworks including an example with pure JavaScript and linked to the source code. Unfortunately the D-pad seems to usually get mapped as an axis instead of a button on most controllers, and I haven't found a graceful way of handling it, so I just haven't used the D-pad.

That's a really good idea! I also was thinking about wether I can rely on every controller registering the same input axis'. This is probably the best way to make sure that players with different game pads have the same experience in the game.

[MaxDidIt]

I’ve added some basic, but important features, making this feel much more like a game already: A health bar!

Currently, the health bar is split between Sam’s health and the state of repair of the plane.

If Sam himself gets hurt, then the player loses one (or more?) hearts.

The plane’s health is further divided into segments. If Sam hits an obstacle with the edge of his plane, like the tip of the wings or one of the wheels, then he only loses one segment.

However, if Sam crashes his plane into anything dead center, then the equivalent of a full wrench is taken off.

If Sam’s plane is in poor shape, it starts to leave a trail of smoke:

And, of course, if Sam runs out of health, then the player sees a game over screen (which I am going to make prettier, I promise)

My next step would be to implement collectable items that will replenish Sam’s health :-)

[MaxDidIt]

So far, it was only possible to avoid obstacles, now there is also something to fly towards! I’ve implemented items! Another basic, but important building block for the gameplay.

The player can now collect coins, increasing their score:

They can collect wrench items to repair their airplane:

And they can collect heart items to regain health points:

Most basic gameplay elements are here, the next steps will be to build actual levels with the elements that are there already.

[MaxDidIt]

I’ve added a small quality of life feature to the game. I found that the character model is often obscuring items that you are about to collect, making it tricky not to miss them.

To prevent this very basic gameplay element from being frustrating, I’ve added an x-ray shader for these elements. So, whenever the the character is in front of any of these items, a colored silhouette is rendered. This is done for hearts:

for wrenches:

and for coins:

I think the shader works pretty well already, and it fulfills it’s purpose. Maybe a bit too thoroughly, though. In some cases, the character is full of colored shapes. Often from objects that are still quite far away and not really relevant yet.

I’ll try and optimize this. Maybe I can try and fade the effect in when the item gets closer to the player?

[MaxDidIt]

So, I’m in the middle of implementing actual levels.

I’m currently trying to figure out how to best manage and display level geometry and objects appearing in the levels like buildings and obstacles.

I think some of my basic approaches already work quite well, like creating a file format that combines 3D geometry that is needed for the current level with placeholders that tell the game where the geometry needs to be rendered.

However, I have a good amount of work still ahead of me. At this step, some of the challenges of the perspective the game is rendered in become apparent:

• Rendering parts of the landscape from far away requires that the landscape geometry extends quite far to the sides, otherwise the landscape ends too early on the left and the right when rendered at a distance.
• When approaching the landscape, the parts on the left and right will vanish outside the screen quite early, so it’s important not to put too much detail into these parts.
• I will probably need some kind of LOD system for landscape geometry and larger objects in the game. It doesn’t make sense to render an object at full detail if it is too far away and too affected by fog.
• I will probably need different viewing distances for small and large objects. It doesn’t make sense to render a coin or an item when it is basically only a pixel large, but I don’t want large objects to pop into existence in the last second either.

There is already some early version of the level system visible in the game. Some of the problems are quite visible, but should be fixed relatively easily:

When flying a little higher, the problems with the viewing distance become very apparent:

I hope I will make some progress on this in the coming days and weeks.

[tydaze]

At 3/11/24 02:19 PM, MaxDidIt wrote: I’ve added a small quality of life feature to the game. I found that the character model is often obscuring items that you are about to collect, making it tricky not to miss them.

To prevent this very basic gameplay element from being frustrating, I’ve added an x-ray shader for these elements. So, whenever the the character is in front of any of these items, a colored silhouette is rendered. This is done for hearts:

for wrenches:

and for coins:

I think the shader works pretty well already, and it fulfills it’s purpose. Maybe a bit too thoroughly, though. In some cases, the character is full of colored shapes. Often from objects that are still quite far away and not really relevant yet.

I’ll try and optimize this. Maybe I can try and fade the effect in when the item gets closer to the player?

It seems others who came before you ran into this problem as well, because when I think of flight based games, they often involve flying through rings or popping large round balloons, and I'll bet that's so they are big enough that your aircraft doesn't block view of your target.

Personally from looking at this footage, I think the silhouette shader messes with my depth perception, as it makes the collectibles appear like they are closer to the camera than the plane. So I'm not sure if it's a good solution.

If you want to increase the visibility of the collectibles without increasing the size of their hitbox, perhaps something like a colored aura could work?

Maybe you could also trying having the camera at more of an overhead angle to see if that helps

[MaxDidIt]

At 3/18/24 05:54 AM, tydaze wrote:

At 3/11/24 02:19 PM, MaxDidIt wrote: I’ve added a small quality of life feature to the game. I found that the character model is often obscuring items that you are about to collect, making it tricky not to miss them.

To prevent this very basic gameplay element from being frustrating, I’ve added an x-ray shader for these elements. So, whenever the the character is in front of any of these items, a colored silhouette is rendered. This is done for hearts:

for wrenches:

and for coins:

I think the shader works pretty well already, and it fulfills it’s purpose. Maybe a bit too thoroughly, though. In some cases, the character is full of colored shapes. Often from objects that are still quite far away and not really relevant yet.

I’ll try and optimize this. Maybe I can try and fade the effect in when the item gets closer to the player?

It seems others who came before you ran into this problem as well, because when I think of flight based games, they often involve flying through rings or popping large round balloons, and I'll bet that's so they are big enough that your aircraft doesn't block view of your target.

Personally from looking at this footage, I think the silhouette shader messes with my depth perception, as it makes the collectibles appear like they are closer to the camera than the plane. So I'm not sure if it's a good solution.

If you want to increase the visibility of the collectibles without increasing the size of their hitbox, perhaps something like a colored aura could work?
Maybe you could also trying having the camera at more of an overhead angle to see if that helps

That's really good feedback, thank you!

It's true, I wasn't happy with the x-ray effect either. It adds a lot of visual clutter and it feels a bit like a band-aid gamedesign-wise.

I thought about changing the design of the airplane so that you can somehow look through it, but I couldn't come up with a convincing idea for that.

You've mentioned rings as a way to make collectibles visible even if you fly in front of them. Making a flying game where you navigate through rings feels a bit like a cliché, but I guess there is a good reason they are used so often in this genre.

I've changed the coins to rings for now and turned off the x-ray effect for them, and I have to say, it does work better:

[MaxDidIt]

So, I've changed the rest of the collectable items to be (somewhat) ring shaped, too.

The wrench items are now cogs:

And the hearts are now heart silhouettes:

I actually like the look of the new items, especially the turning cogs look neat if there are several of them on screen.

Apart from that, I'm currently putting a lot of work into how to build levels and how to render the environments.

[WillKMB]

looks pretty cool, I'm looking forward to playing it