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.

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.

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.

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

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! I'm so happy to hear that! I will post any news to this thread!

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. :-)

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! :-)

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.

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.

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.

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 :-)

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.

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?

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.

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:

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.

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

I'm happy to hear that!

I hadn’t posted an update over the easter holidays, but I have been busy nonetheless! The game is slowly starting to look more and more like a game.

Rendering the landscape has improved considerably:

• rendering distance works better now
• transitions between chunks of the landscape are more seamless now
• no more “gaps” left, right and behind the landscape anymore

Also, the world we are flying through now has 3D clouds, which I think is quite important ;-)

To make sure rendering the environment isn’t using up too much performance, I have implemented a simple level-of-detail-system. Most level objects will have two versions of themselves, one with fewer details and one more detailed version. The game will render the low detail version if the camera is further away, and switch to the high detail version once the camera comes closer.

This should keep the number of polygons rendered low, which will hopefully make the game run more smoothly especially on mobile devices.

I’m currently building levels for the game, placing obstacles and items to create hopefully interesting courses.

Not using Unity or Godot to create this game means that I don’t have a tool to create 3D levels for the game. Instead, I’m using Blender to place objects and making sure the distances and the timing of obstacles is correct.

Since I’m already using Blender to create the characters and items appearing in the game, using it to create the levels seems logical to me.

Any geometry that I need specifically for a level, like buildings or bits of environment, is modeled and stored directly in the level Blender file. If the object needs to appear more than once, then I will create instances, which generates additional positions for the object but prevent the geometry and texture coordinates to be duplicated.

By using instances, I can see within Blender how the object fits into the level at each position. Later, the game will be able to recognize, which geometry data the respective instances are using and render the correct 3D objects at each position.

For general objects like items, I’m simply using placeholders in Blender. By using a specific naming convention, the game will know which object to use for each placeholder.

Hi everybody!

When creating games, sometimes seemingly mundane things can create the most work. Like giving your game a neat little intro and title screen. Doesn’t sound very spectacular on its own, but it requires a couple of things you don’t think about very much when playing games.

Suddenly, your game needs a logo, for example. I quickly put one together in Inkscape and exported it to Blender so I can animate it in the intro sequence.

Then, I want the player to be greeted by the official Savanna Sam title theme when starting the game! Which, of course, requires me to write and record said theme. So, I dusted off my midi-keyboard and fired up LMMS, and after more than a weekend, I now have the first of hopefully several catchy tunes to set the mood for the game.

I then could load the song file into Blender and animate the intro sequence so that it matches the beats of the song. The intro sequence really isn’t very long, and yet, even animating such a relatively small scene takes a lot of effort! That salad of lines below is the visualization of part of the animation from the intro sequence.

All that effort, just so that the player is gets a neat little introduction to the main character of the game:

There is now a miniature version of Sam!

I have modeled this smaller version of Sam for the overworld map, of which I implemented a first version recently:

As you can see, the map is very much still a work in progress.

While I will continue to implement functionality into the map, I plan to create the actual visual design for it pretty late in the game, when I know which levels there are and in which order the player is going to encounter them.

For now, you can already travel on the map and select the level you want to play:

Another step for this project towards feeling like a real game! :-)

I have switched out the old placeholder environment graphics in my first level for the actual graphics!

Before, I was just repeating a quickly modelled river object that I slapped an earth/sand texture on. It fulfilled it’s job as a stand-in so that the level would have a ground and it let me implement the level-of-detail-mechanics for environment graphics.

But, they weren’t very pretty. The brown colors even look a little bit post-apocalyptic, I think. So, it was time to start and create the actual level graphics.

Since the first levels are supposed to take place in the eponymous savanna, I needed to find a way to somewhat convincingly depict fields of grass. I don’t want to render actual thousands of blades of grass, and I also want something that fits the cartoon style of the character.

I tried several approaches and I found a way to depict this kind of landscape in a way I’m happy with.

This looks much friendlier already. Also, the grass creates a nice parallax effect in motion (It does not translate well to animated GIFs, unfortunately!)

I have also added the hills at the side as an added detail. It’s fun to create little worlds like this.

I’m not quite done, however, I still want to add trees, bushes and rocks to complete the environment.

I have added the second character to the game! It’s an elephant NPC who is first appearing at the waterhole that you fly over in the first level.

First, I visualized the variants of the character I want to show up:

Then, I modelled, textured and rigged the elephant in 3D. Short, chubby characters like this guy can be tricky to animate, especially if you use such a small amount of polygons. At some points, you just need to cheat for certain animations by subtly scaling bones, for example.

And here they are, having a great time at the old waterhole:

They even react if you fly close to them with your airplane:

And another character has arrived to populate the levels in Savanna Sam. This vervet monkey inhabits the baobab trees you will now find in the game:

As you can see, she is having a slow day… until a certain giraffe is almost crashing his biplane into her living room:

I’m still adding more features to the game. One of the more recent additions is the first story cutscene that I created and that now plays when you first start a new game of Savanna Sam.

I’ll admit the cutscenes in the game will not be full motion videos, but 2D comics that you can interactively click through. But I think they still integrate well into the look of the game and are posing a reasonable amount of effort I need to invest into them ;-)

I’m currently busy adding missing details to the game. I want to finish a complete vertical slice before I continue with creating the next playable level.

One of the details I finally have come around to integrating is something I can’t believe took me this long to add: Sam’s plane finally has a propeller!

It’s one of those details that don’t really have any impact on the gameplay, but visually, it makes quite a difference, of course.

I also had some of my friends play the game and found that they got stuck due to missing information about the controls of the game. So, it was time to add tutorial/hint screens, so that players don’t need to find out which buttons to press by themselves via trial and error.

What makes creating these a little tedious is that there are basically three control methods the player might use: keyboard, gamepad and touchscreen. The tutorial screens need to be able to display informations for all three of these. Currently, the tutorial screens will highlight the controls for the method the player used last, with the other two being shown at the side to hint at the other ways you can play the game as well.

I have also added a number of sound effects to the game, which is a little tricky to show here ;-)

Let Sam give you some positive vibes! You can do the thing!

This is a new reaction animation Sam will now perform when you collect an item. This gives the game more personality! I am currently adding more reaction animations for other situations, like receiving damage.

Another thing I have been working on recently is the “level finished” screen. Among other things, I have added a display showing how many lives you still have (Yes, there are lives now!).

Also, there is now an animated UI showing how many (and which!) gold rings you have collected in the level: