next »

[bkslsh]

This week sees more NPC work-in-progress creatures. Watching these little guys walk around makes the level feel more alive. Next up, I’m going to add some alien plant life and keep fleshing out this level’s design.

This week I also went back and re-played a lot of old Mario levels to remind myself what a good level arc feels like. A lot of them force you to work your way upward, usually toward a mountain peak or plateau of some sort, which is helpful for the player since it’s easier for them to orient themselves toward a known goal. Mario 64 especially didn’t give the player a map, so you were on your own to find the next goal of the level. It’s really frustrating to find yourself stuck on a level unsure of where to go next, so coin and enemy placement is used to lead players down a desired path, along with the occasional directional sign or arrow. These are things I try to keep in mind as I work out the flow for this level. Right now this level is more of a scratchpad for ideas to test out than an actual level with a goal. That comes next.

[bkslsh]

This week was a good week for gamedev in Kentucky, because it snowed so much I couldn’t leave the house if I wanted to. Which meant plenty of time to work on a new level design. Here’s the original sketched design and the work in progress level in Unity. Not everything in the sketch has been added, and a lot of things that are there are rough, but it’s progress. Still pretty short for a full level, but it’s a start at least.



You start in the crater in the bottom right (your ship landed there and will appear once I model it). There are 4 courses and a boss area. Only 1 type of animal NPC (not counting the boss) and 2 types of plant NPCs for now. Plus environmental obstacles like hazardous liquids, falling platforms and moving platforms.

Here’s a GIF of the beginning of the level:



And a GIF of some falling platforms:



Game structure idea - at the beginning of each level the game will tell you which animal you’re looking for, then you have to find it and trap it so you can get a DNA sample. (Maybe after you collect the sample, you have to make your way back to your ship so you can send analyze the sample and turn in your report for Earth, or that might get tedious, not sure yet). Then you go to a new level (either a new biome on this planet or a new planet) with a new animal target. As you collect these different DNA samples, you build your own little hall of trophies where you can see miniature clones of the different animals/aliens you’ve found, like a personal zoo. That’s the current thought anyway. Not sure how the trapping mechanic will work exactly, but it will be like a boss battle. Maybe you have to knock the creature out through jumping or with weapons… or maybe it’s like Ghostbusters where you pop up a little box and the creature gets sucked into it magically, and the challenge is more about reaching the alien than battling it? I dunno, people love boss battles. And nothing is more satisfying than jumping on Bowser’s head as Mario, so I should remember that. Just thinking aloud here, curious if you folks have any opinions?

Right now there’s no combat in place, but I am going to make it where you can jump on the creatures’ heads and they’ll go belly-up and reward you with minerals. A double-jump and/or jetpack is also coming soon.

[oahda]

Still a bit rough but I like the look of some pieces like the background mountains and the character himself a lot! I'd say I'd prefer smooth shading to the creatures with visibly divided quads, tho.

Movement is looking really smooth in the last recordings.

Interesting!

[anotheryeti]

Nice! Always a fan of anything resembling the glory days of 3d platformers.

How does the world look w/o the Toon shader? I feel like limiting the lighting in a low poly game might make readibility much more difficult in certain situations. Not to mention your pretty concept art didn't seem to be using it!

[bkslsh]

Still a bit rough but I like the look of some pieces like the background mountains and the character himself a lot! I'd say I'd prefer smooth shading to the creatures with visibly divided quads, tho.

Thanks for the feedback, Princessa. It's definitely still a work in progress with lots of placeholder material yet to be replaced. I'm still trying to get the right level of detail into the models, but the idea is to keep it intentionally angular-looking in style. Personal preference, I suppose.

[bkslsh]

How does the world look w/o the Toon shader? I feel like limiting the lighting in a low poly game might make readibility much more difficult in certain situations. Not to mention your pretty concept art didn't seem to be using it!

Thanks, anotheryeti! I agree, legibility is an issue with a toon shader plus low poly. I'm actually using a basic diffuse shader, not a toon shader, though it has that appearance, especially in the gifs. It looks a lot better with ambient occlusion baked in, but I'm still trying to get the right effect in Unity. You can see in an earlier post with a smaller test level I got a nice AO effect that came closer to the concept art render, but in a level this large I've started getting distortion and artifacts when using a texture for AO (though at a distance it has the effect I'm looking for). I tried baking a lightmap in Unity, but that also suffered from visible artifacts up close. As an alternative I've been reading about shaders that calculate AO in real-time (SSAO), and that seems like an good option. I'd prefer to implement it myself rather than buy something off the asset store, so that could add a little bit to my dev timeline. 

Here's the result of some experiments I did today. You can only see the effect in the terrain, as it's not applied to the character or platforms. The lower arrow points out the visible artifacts, and the upper arrow points out an OK-looking distant feature. The Unity lightmap didn't do so hot a job at the distant features, and it still has artifacts up-close, though they're not so bad:



I'm sure this is old hat to the game dev pros out there, so if anyone has any reading suggestions or best practices I'd love to hear them. 

[anotheryeti]

If you have Unity pro, there's a built-in SSAO camera effect you could play around with.

I've been playing around w/ the light mapping in Unity a lot for my own project (with a similar low-poly style), and am using it purely for AO baking. Since you're not using a ton of GPU memory for textures on models, you could probably up the light map scale of your world geometry (or just reduce the worldspace texel res) for a nicer result. Also, play around w/ the ambient occlusion distance to see what fits. I upped the max distance to 4, since I'm so reliant on it for depth cues. You could also manually unwrap the light map UVs to deal with problem areas in your geometry. Those nearby artifacts are due to pixel grid not lining up w/ the geometry in heavy AO areas.

Last fun fact: I don't know if the light itself is dynamic or static, but if it's dynamic and you're purely doing an AO bake, go into render settings and set the ambient light of the scene to pure white. The default is pretty dark, and that messes up an AO bake.

[bkslsh]

If you have Unity pro, there's a built-in SSAO camera effect you could play around with.

Thanks, anotheryeti. Sadly I do not have Pro, though I may end up having to get it in the end for this purpose.

Last fun fact: I don't know if the light itself is dynamic or static, but if it's dynamic and you're purely doing an AO bake, go into render settings and set the ambient light of the scene to pure white. The default is pretty dark, and that messes up an AO bake.

Aaah, so that's why my first few bakes were so dark. Thanks for the tip!

[bkslsh]

I spent most of the week finishing little things to make the game playable in its rough state, so I can start play testing with a few friends. That included fixing the pause screen and linking up a working level select screen. I also started on the enemy AI, which is coming along but doesn't have a visible result yet. My friend momarkmoproblems has contributed a few new models for the plant life (ignore the placeholder HUD display):



The soundtrack is in the works too, with awesome music by BBass. Once we finish the first level I'll post a video so you can sample the tunes.

[bkslsh]

One thing that's been missing so far is a good description of the overall goal and structure of the game. So here goes...

Goal of the Game:
Astroman is an interplanetary explorer whose mission is to scout out new planets for colonization by humans. He has to discover new alien creatures and capture them so Earth can research them. Once the planet is explored thoroughly and threats from the alien creatures are identified, the planet can be opened for colonization and you win the game.

Game Structure:
At the start of each level, you're told what creature is your target and what habitat they can be found in. You move through the level, avoiding obstacles and other enemies, until you find the target creature. You then have to lay a trap (kind of like the ghost trap in Ghostbusters) to ensnare the creature. Later creatures may have defenses you have to remove before trapping. Once you trap it, the level is complete and you'll see a level complete screen with score etc. Your score is based on time remaining in the level + total minerals collected. You only have a certain amount of oxygen, so you have a limited time to complete the level. Once you beat the level you can choose to move on to the next level or to visit the trophy room. The trophy room will show all the creatures you've captured so far.

The end of the game is when you've beat every level on the planet. Then we'll say we now have enough knowledge to colonize the planet, and your work has made this possible. We'll end with a scene of ships landing on the planet with other humans.

Here's a rough storyboard sketch of this basic flow:



So my question for you folks is – does that sound like fun? I think so, but I'm also a science nerd so I need some outside opinions.

It's a little different than the traditional rescue-the-princess or kill-all-enemies structure. I was inspired by Kerbal Space Program, which is more open-ended but also focuses on the "science points" mechanic, where your goal is to collect samples and scientific readings to get science points, which are redeemed for new better equipment... Also inspired by Dwarf Fortress, where you can build a zoo to keep the goblins and monsters you trap. The "collect objects" mechanic is pretty traditional. Maybe you could also redeem minerals you've collected for new equipment in a store screen, giving the player an incentive to collect minerals for something other than just points.

My only concern is replayability – once you beat a level, is there any reason to replay it? Mario 64 uses the star mechanic, where each level might have several goals, one for each star... that's a feature people either love or hate it seems. Still thinking on this one...

[bkslsh]

Today Astro learned how to take out an enemy.





Continuing to tweak the jump physics – it's hard to get just right.

[bkslsh]

I'm testing out a new idle/slow jump animation for Astroman. It's a little less wonky than the free Mixamo animation I was using before. Still trying to get the speed and gravity just right:



After testing out a few toy levels, I've started designing the first full-length level. Finding the proper scaling and pacing for the design is a slow process, at least for me, since this is my first 3d platformer of any sort. I've been reading articles about best practices and analyzing the level design of old favorite games. The idea of using horseshoe or loop for a level keeps coming up, so I've used that here. The player ends the game next to where he starts, but at a height inaccessible from the starting point.

At the bottom is a 2d top-down map (made in Illustrator) that was used as a starting point for the 3d version. Models for different elements were made in Modo then laid out in Unity. Still need to add a lot of details, but the basic flow and terrain layout is in place. After testing it I have a feeling it's still too small, and that I'll need to double or triple the length of it to make it feel like a full level.

[bkslsh]

I've been doing some homework on what makes a good level design. Along with replaying lots of Mario levels, I've been reading articles about platformer level design, both 2d and 3d:

• Game Feel by Steve Swink
• Making Platforming Games - Subtractive Design
• A Hat in Time’s Level Designer Talks Platformers
• r/truegaming thread - What makes for good level design in a platformer?

Game Feel should be required reading for all game devs (especially because it's available for free online). It was very helpful in giving a name to a lot of intangible qualities that are vital to good gameplay. Subtractive Design's post contained a lot of level-design-specific advice that I keep coming back to:

Anything you plan to do is going to take 3-4 times longer and require more effort than you will anticipate at first.
Even knowing this in the beginning, I still underestimated the time required for just about everything. Which is why three months later, I'm still trying to nail all the basic character movements – run, jump, slide, fall, etc.

The jump is everything!
Amen. I've tried lots of approaches to handling the jump, and I've finally settled on a method that works well, but tweaking the specific values of acceleration, hang time, jump height, and gravity is unending.

Forgiveness systems in jumping
Like allowing late jumps, sliding up the lip of a platform if a player hits just below the edge, etc. After a few frustrating playthroughs of my test level the need for these player-friendly systems was clearly apparent. The reddit thread also contained strong opinions against requiring pixel perfect jumps.

Players don’t like to hit their head while jumping unless there is a reason to do so.
This is a small detail that makes a big difference. My first level design had low platforms and ledges, and it totally broke the game feel to jump and hit the character's head on an overhanging ledge or low platform. Now, if these were coin blocks it would be a different thing, but they're not, they just disrupt your movement, so avoid them.

You always want to know when you are going to fall off of a ledge so try not to round edges or get crazy with the art.
Yes. My first couple levels, despite the low poly style, were fairly organic in trying to imitate natural rock formations. Jumping off those ledges could be frustrating though – because the ledge edge wasn't straight, when exactly the jump took effect felt somewhat unpredictable. After that, the relatively simple polygonal structure of Mario 64's terrain made much more sense. Now it's a matter of balancing art with playability.

New Feature:
Working on sliding down slopes, something the default character controller in Unity doesn't provide. Previously if you jumped and landed on a steep slope, you'd stay there. No more! Now you slide, and if you continue running upwards you slow the slide. Still need to add a sliding animation though:



This means the slope of every surface of the terrain is important, because a player needs to be able to read whether they can climb that slope or whether they'll slide down it. I'm planning on avoiding slope angles close to the slope limit to help with this, which means revising a lot of terrain models.

[bkslsh]

This week I spent a stupid amount of time trying to sync footstep sound effects to the walk/run animation blend tree with math wizardry before discovering Unity's animation events, which made doing so way easier. So now Astroman has footstep sounds that match when his feet hit the ground at all speeds. Also added some dust particle effects for sudden acceleration:



I'm working on a detailed write-up of how sliding down slopes is handled, so that's on the way. Lots of vector math, I'll tell you that much.

Oh, and this terrain model (just for testing!) is from the awesome Super Mario 64 HD by Roystan Ross assets.

[bkslsh]

Putting the dev in #devblog... Today – animation finite state machines in Unity!

Top-level:



The animation state machine contains 4 Blend Trees – Locomotion (which contains the Idle state and walking/running) and 3 Jump animations. The JumpUp animation includes the initial take-off and holds its ending pose until the jump’s apex is reached. The JumpLoop animation is a short looped clip of the character in mid-air. JumpEnd contains the landing and occurs when the character is a certain distance from the ground. The character’s distance from the ground is determined by a CapsuleCast in the direction of movement. That result from the CapsuleCast is also used to detect if a character runs off a ledge without jumping. In that case, JumpUp is skipped and the JumpLoop is entered. Like this:



Locomotion Blend Tree:

The speed variable controls the blend from Idle through Sprint. The angularVelocity variable controls the amount and direction of turning. Somehow sprinting without the sprint-turn animation looked better, so that's why there's no turning animations here:



And that, along with an ever-growing C# script, is what controls the animation and movement of Astro.

[bkslsh]

This week I continued development of the character controller. New features:

• jump is now variable height (you can stop jumping half-way through)
• started working on a double-jump
• footsteps now have sound effects synced to their animation
• jetpack model started

Also lots of bugfixes related to sliding down slopes. 

Here's v1 of the jetpack (the terrain is all for testing only, not actual game terrain). It's hard to see from this angle, but there's a fuel meter on the back:



I'm almost ready to post a video of the character controls in action. Coming soon... (!!!)

[bkslsh]

Been working on the HUD this week... got some 1/2 way decent graphic placeholders in there now at least. I suspect the helmet won't be easily recognizable as a "lives" icon and will have to change, but for now it's ok. The hearts will eventually be displayed as 1-3 individual hearts instead of as numbers.



I also finally got a fully working game cycle for player deaths and level resets. This required a lot of tweaks to a buggy NPC-Player collision system, and a minor reworking of the game's code organization. But it's super satisfying to be able to hit "restart" after death and keep jumping on enemies. Here's an early version of the player's death, I'll add particles and sound later:



How do we decide whether a collision should result in damage to the enemy or player? I took a cue from Mario, where running into a Goomba will hurt the player while jumping on top of one will hurt the enemy. Just look at the difference in vertical position between the player's feet and the top part of the NPC. If both are at roughly the same vertical position (or the feet are higher) then it's damage to the enemy, otherwise the player takes a hit and bounces backward. Here's a mildly interesting view of Unity's editor window. The yellow wireframe sphere represents the feet position, the cyan is the NPC:

[HughSJ]

Early days but you've got some nice lookin stuff. You spaceman makes me think of Üter or Ralph from the Simpsons, which is awesome. He's got this goofy roly poly quality to him that should make for fun animation, and which you'd do well to keep with.




Definitely worth taking a critical eye to golden age platformers as you have (Banjo Kazooie, Crash Bandicoot, Super Mario 64 etc), but particularly to do so continuously as you work your way through development. Something you'll find is that your sensitivity for game mechanics in a genre will skyrocket as you work on one of the same type, so it's worth looking back at inspirations periodically-- that's something it took me a while to properly understand working on my own projects.

Regarding your physics, from the gifs it looks like you're using linear models of speed and acceleration, which is a very inorganic system of motion. Life is all about curves, both in art and in motion; quadratic models will serve you much better. And if you're not following him already, have a look at Willy Chyr's devblog on TIG for Relativity. His game is more puzzle than platformer, but he's got an excellent sense for game-feel, and better still does a great job of explicating his process and decision making. As an added bonus he's also working in Unity.

Also, people have dissected most older games to figure out the equations used for movement and other things. There's a really comprehensive breakdown for the physics of Sonic here, worth a look. I'm sure if you do some searching you'll come up with similar results for other titles.

One of the reasons why those early platformers are so successful (ignoring the strength of their control mechanics) is because the design of the levels inherently modulated difficulty. Notice that most of these games could by completed by retrieving only a fraction of the collectibles, and that at any given time there were multiple areas one could access in order to progress. If you got stuck/bored with one puzzle or area, you could always swap out. Also, Mario 64 gates harder difficulty zones by requiring a minimum threshold of stars to be collected-- that didn't need to be put in there, but what it achieves is that players are forced to hit a certain level of competence before they go up against more challenging content. Something you might consider in the design of Astroman is utilizing a similar layout, especially since you're applying a similar visual style as well. Just as important though is to look at what those games did poorly. Camera control, unskippable elements, and the occasional cheap/janky puzzles are some of the biggest ones that crop up. If you can hit good game-feel and avoid some of these problems you've a guaranteed fan base.  

The other project I'd recommend looking at besides Relativity is Overgrowth. It's this weird action/platforming hybrid, but it has honest to goodness some of the most satisfying movement and animation in a game that I've seen. Not only did those guys (Wolfire) write their own engine over the course of years, but they've openly documented almost the entire process. David Rosen video blogs updates, and also has technical posts about changes/additions.

Anyway, best of luck. My recommendation is to keep fiddling with mechanics and see what works to build your game around. As a platforming game, you live and die by your jump and run, so nail that sucker down and polish it to a sheen.

[bkslsh]

Thanks for the thoughts, HughSJ! I really appreciate your insight.

Early days but you've got some nice lookin stuff. You spaceman makes me think of Üter or Ralph from the Simpsons, which is awesome. He's got this goofy roly poly quality to him that should make for fun animation, and which you'd do well to keep with.

Ha, he totally looks like Ralph. I knew he seemed familiar somehow...

I have indeed been replaying a lot of golden age platformers, as you suggest. I grew up on those games, so revisiting them now with a critical eye is both a lot of fun and really interesting. It seems like there's not a whole of people making 3d platformers nowadays, and as I struggle through level design in 3 dimensions and encounter the artistic and technical difficulties of the genre, I can see why. It's impossible to make a full-scale 3d platformer level that plays well without spending years of man-hours designing, play testing, and creating art assets with a large team let alone as as a single/small-time developer. I figure if I can get a solid character controller and a single really excellent level to make a free demo with, I'll be satisfied. It's a learning experience.

Yes, all the models are linear at this time. I experimented a bit with non-linear models early on but lost them when reworking the code a while back. You're right, quadratic would work better, and I plan on working on that.

Hadn't really looked at Relativity or Overgrowth before, I'll check them out. I think my favorite part of gamedev might actually be the "research" part.

Thanks again for your comments, I get so excited when I see there's a new post on this board that's written by someone other than myself, ha.

[bkslsh]

This week was all about the camera. The old camera pretty much just trailed behind the player, giving you a nice view of Astro’s backside. (Side note, Crash Bandicoot’s early working title was “Sonic’s Ass” because of that inherent challenge in 3d platformer cameras). This week still doesn’t offer a front view, but I added a few other possible positions for the camera relative to the player. Now if an obstacle appears between the camera and player, alternative camera positions are evaluated until a workable position is found. Very similar to the same way the Unity stealth tutorial handles it.

Here’s a screencap of the rays we’re checking – from possible camera positions to the player’s position. The red lines are possible camera positions, yellow are rays that collide with something other than the player, and blue is a ray that finally hits the player. Since only the topmost ray is clear, that's where the camera is positioned. The bottom of the screen shows the in-game view, where the top of Astro's helmet is visible. Click the picture for a better resolution imgur image.



Clearly not perfect, but a hell of a lot better than trying to look through the ground, which was the previous strategy. Here's how it looks in motion:



Now to get the camera to stop spazzing out when it's confused...

On the HUD... it's clear to me now that the hearts/lives thing in the HUD doesn't work - it's confusing people. Mario was brilliant because health was indicated through the character itself (the panting out of breath sound and hunched over posture of Mario 64, the mini-size Mario in all the 2d games, etc). Expressing state through the characters' features is better than relying on a HUD. So I'm rethinking that.

On progress... Every day I dig deeper into this project, I find whole new areas for exploration and development. I was starting to get overwhelmed by the scale of the task compared with my rate of progress – even getting a workable demo together – but then I read The Poor Man's Character Controller by Evan Todd and felt better. He's been working on a character controller for 4 1/2 years, so I guess for 3 months I've made good progress. It really does take that long to do it right. Something as simple-sounding as a jump is not so simple to get right.