Jump to content
  • Advertisement

Unity Weekly Updates #27 - Staring into the 深淵

jb-dev

1371 views

Why hello there, and welcome to this 27th weekly update! I've been cooking up something literally game-changing (sorry for the pun).

Hang on tight and be careful not to fall, and let's get right to it!

Steppin'

In my previous post, I've ended on a bit of a teaser. I've talked about an algorithm that helps to create varied types of floors.

In essence, the idea is to be able to "paint" different floor type onto a 2D array  (or an "image" if this is abstract enough for you). Once that image is painted, we simply render it and generate special floor types all around the level.

The Array

Because I've previously used this Unity tutorial as a basis for building my level generate, reusing it was really ideal. I've simply added another 2D array that describes floor types at a given position.

Because I've also previously worked on another 2D array algorithm for prop placement, I've also taken the liberty to reuse those drawing algorithm too.

By mixing both codes I was able to create a reliable 2D array that was easy to modify and access, which is arguably really nice to have.

The Rendering

Now that the array is set, we now need to somehow render that array to the level, which wasn't as straight forward as it seems...

Because I've followed that tutorial, the algorithm I use is the mighty Marching Square algorithm, which does work nicely on binary maps...

However, my floor map isn't binary. This creates a pretty glaring issue: corners. While I can treat each floor type as their own binary map (and consequently as their own mesh altogether), their corners won't match up and will create holes where there should be none.

image.png.35deb05ba7cfd826e4fbb2978826a826.png
Notice the small bright pink triangles on this map

So we need to tweak the algorithm to fix that: we don't want the ground to be swiss cheese...

Patching-up holes

After thinking about it thoroughly I could list up the "problematic" cases.

First, we could narrow down the problem by simply stating that because a square only has 4 sizes then there could only be as much as 4-floor types per square. this limits the amount of case to search.

Then it was only a matter of visually scanning every problematic case possible.

Here's what I've found:

squareProblems.png.9269d1dba1b52e408b2eb52632dc17d5.png

As we can see, there's a pattern forming. We can state that problems only occur when the following conditions are:

  • The floor type we are currently rendering only has one active node for a problematic floor square.
  • There are more than one floor type for that square
  • The biggest sum of the total number of active nodes between two types of floors is less than 4.

Aside from that, there's also the idea that only non-corner floors can be problematic. 

One thing to note is that there are two configurations that are exempt for it:

squareExceptions.png.dd29dec40a157079396ed4bc2ad58bfd.png

As you can see, when there are exactly 3 types of floors with these configurations then there are no holes at all...

The algorithm

In order to fix those problematic cases, a new algorithm was in order. After snooping around and searching different marching squares tutorial and/or general discussions, I've decided that the best course of action was to use dual squares at these junctions.

For those who don't know, dual squares are the more conformal cousin of marching squares.

marchingVdual.png.ede3a22cb5dcecba167466d4ac2b6068.png
From left to right: marching, dual

In essence, with marching squares, we want to create a "triangular" meshes with "rounded" corners (Think of it as a "smoothing" function for pixels), while with dual square we take their dual point.

Like marching squares, dual squares also works by building indexes for particular squares. It's just that when it comes to rendering, duals are far more square that their marching counterparts.

To illustrate this, here are the possible configurations for marching squares:

msquareindexes.png.99236cf0fe12189222db23eedcc9aebc.png

And here's the same thing for dual squares:

dsquareindexes.png.91b60bdb0535905f244c39e28d95ed1a.png

One particularly alluring thing about dual squares is that I can simply reuse the code for building marching cubes meshes but just create another vertices-creating function which creates those squares meshes.

This is far easier to plug into the previous code.

Walkable floors types

Another important thing to note is that even though we now have a hole-free ground we also need to do another step in the rendering.

The way the enum is organized is that there are certain floor types that are marked as "non-walkable" (i.e, they aren't your typical floors). Every non-walkable floor type has a chance to be completely invisible.

This means that the player could see holes where those type of floors would be. Not really aesthetic if you ask me...

So, in order to fix these, I've decided to create walls that would surround every walkable floor. Thus, if a non-walkable floor is completely invisible, there would be a wall and possibly a dark "bottomless" pit too.

Because the tutorial also shows how to create walls you would think that just reusing that code would be great, and you'll be partially right. 

Although that walkable floor map would be binary, we also need to take into consideration the aforementioned junctions, and more specifically their configuration.

If we have one of these dual junction squares then the extended walls need to only encase walkable floor. Otherwise, you'll get holes in the floor again.

image.thumb.png.8e0da186d17cf83836d773dea7141faa.png
Notice the black triangle on the upper-left.

To fix this we'll simply store an additional square for each junction that actually describes not whenever or not there's a floor there but whenever or not that node relies on a walkable floor.

This way, while building those extended walls, we could simply check these "junction" square instead of the real ones.

Paired with a nice fading shader this makes for a believable bottomless pit.

Foor patterns

Much like the props placement algorithm, this one also comes with room-specific floor patterns.

It works much like the prop placement ones, but it renders directly onto the floor type map. 

Right now, aside from a generic random one, there's only one other arrangement: the Island pattern.

Basically, the pattern consists of a central island surrounded by non-walkable floors. There are also ridges along the rooms' entry and exit wall side.

image.thumb.png.e3f5e7d417481c22e15b703741d5db5f.png

Everything is connected by semi-procedurally generated bridges.

There will be a lot more different floor patterns... There will also be huge structures here and there too, like lakes or chasms.

Of course, some room patterns will override these, but not all of them.

Floor types

Now that the technical stuff is done then let's talk about the floor types.

Normal Floors

image.thumb.png.671e671ee76edc2ceef88ab479c25255.png

This is your typical floor. Nothing special here

Grass Floors 

image.thumb.png.f179dcf651211870d109ee2d2e1585c0.png

A typical grass-filled ground. It is very noisy and will get instantly noticed by enemies while walking on these.

I'm not sure how to make this type of floor more interesting...  (A Geometry shader perhaps, or maybe an actual separate mesh of simple billboarding triangles...)

Grass Wetness

One particular thing to notice is that this type of floor will have different coloration depending on the wetness level of a room. 

To achieve this I've decided to have another 2D array of the float that describes the wetness of a particular square. Like the floor types 2D array, there are many utility functions to draw on that array.

I've also wanted to have some blur going on so I've decided to look into the gaussian blur algorithm, which is quite useful here.

With it, I can control the amount of blur applied between different zones.

After that, I store the wetness of a particular floor square in an unused UV map.

In the shader, I just sample the U coordinate of vertices to get their wetness and that's it.

Take a look:

image.png.83cf16aa4616a9dc9fb246a9eee31d5e.png

Here's the algorithm I've looked at.

Sand Floor (WiP)

image.thumb.png.116ee82d100087572d2f6cdc95e4860f.png

This is a sandy floor. Jumping from it yields a really low jump.

Mud

image.thumb.png.efbe9f72b8e01476b20d01c26cdbebc5.png

Ew, mud! Careful not to get yourself dirty!

You can't go really fast while walking in mud.

Chasm

image.thumb.png.3fe1a1345b38687fddac8e414ecbeacf.png 

This is a chasm. Falling into them results in death, so be careful.

Lava (WiP)

image.thumb.png.317780b10f2a25f31093b2d8bd98e9d4.png

This is your old friend lava. It is a heart-warming friend that is always there for you. 

But seriously, don't get in there or you'll catch on fire.

Ice

image.thumb.png.72a9b79d78af64541770ea3e4c3ebbca.png

A nice clear floor, yet it's quite solid. It is quite slippery, so be careful.

Water

image.thumb.png.8bd371cf207037ef96c6b3da0b2c03ac.png

Ah, nothing feels quite like a nice swim, especially when you're on fire.

Poisonous Water

image.thumb.png.74c3de1647afd84d457473f5f7845e21.png

This isn't like your normal water. Bathing in it will poison you, so be careful not to slip!

Liquid Nitrogen (WiP)

image.thumb.png.fa50650377547b5aab9359553d9f75d9.png

This is quite a scene: a sea of liquid nitrogen. 

It's impossible in real life, but this is a video game.

But like real life, touching this will freeze you, so be careful!

Spikes (WiP)

image.thumb.png.400ab6eec636c841f7dd508942bab47c.png

I didn't finish their design yet, but it's your old friend the spikes.

You get the gist: stepping on them will hurt you so be careful!

Love Potion (WiP)

image.thumb.png.cb0eda73adb8c288b1e89ec530e4b8e7.png

A bit of a stretch, but it's there!

Stepping in this will make you frenzied, so be careful!

Liquid Floors

Another thing to mention is that I've also cooked up a wavy vertex shader that makes models wavy, which is quite useful to simulate big bodies of liquids.

Here's a good look of the shader in action:

I've followed this tutorial to achieve this if you're interested

Minor updates

  • I've finally decided to fix most melee weapons hitboxes. Previously I've used the actual weapon's hitbox to basically see if the attack hit something. This was unreliable at best, mainly due to by both animation and code being wanky. I've changed it so that hitboxes are now more reliable and will always hit where the player aims their crosshair. This makes weapons like sword relevant again!
    • This applies to both players and AIs

Next week

Last week was insane! That floor algorithm really took a lot of my time and I think it can really pay. With things like chasms, jumping now gets the importance it should have.

Lately, I'm trying to somehow fit AI in this. I want to give the player the ability to "push" enemies in chasms. Right now AIs are restricted to their navmeshes, which is neat but it makes them immune to chasms, so there's a lot of thinking ahead.

There's also some polishing to do with, especially with floor formations and stuff. I also need to change the visual of some floors, like for example the spikes or the grass.

Afterwards, I really want to diversify enemies. This would be an important step towards having a public demo of some sort.




0 Comments


Recommended Comments

Nicely done sir.  This just keeps looking better and better.  I'm super curious to give it a whirl. :)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By RoKabium Games
      Aura enemies – ”Heeble” is a spider-like creature that is closely related to the Creeble, Greeble and Beeble and it can crawl across any type of block. The ice-webs this one spins causes a lingering damage so stay clear and burn those webs from afar.
    • By Shadowsane
      My project started in 2014 but recently ended due to no funds.  AltarisNine was a Minecraft project based on RPG. The concept was nine islands that you explore at a time to follow an in depth lore based on our own production team. This is where the 'Nine' comes in. With skepticism of future success we hope to make this tale into chapters. Such as the first one introducing Nine islands at time.
      It wasn't always the same though, my world did evolve over time and now I have a better idea of what it is better than ever. In the first island, Main Isle, is themed around jungles and wilderness. There's lore that stretches throughout the chapter which will engage the player. There would also be kinds of characters you can be such as any other RPG which could be talked about (because i'm still  about what I have lol)
      My former team was designing a world players would get into interact with in various ways. Boss battles would be minigames and the RPG lore would be engaged in and something indie platforms would enjoy and talk about beyond platforms.
      In the minecraft varient I was a builder, the leader, and the story director which everyone respected. I led my own team of builders and story writers. While I chose certain individuals to be the head department of development and art design.
      The reason I am here is to find a new team to help take this away from minecraft and hope we can be successful about it. I'll happily commute each and every person that volunteers and will be accommodated down the line with promotions, wages, and definitely praised for helping start my dream up.

      Here are some questions that were frequently asked and that I can thoroughly answer:
      What is the goal of the game? If you've ever heard of Wizard101. I got inspired by that game a little. I like the concept of making yourself in this world of mystery and impressing people with new mechanics and events that they enjoy. I'd like for the game to be successful and be mostly on PC but if this keeps up we could reach out to other consoles. But for now, PC, one platform at a time lol. My goal personally is to give people the entertainment and enjoyment I think they'll deserve. Something thats not cheesy, not cliche, something new to keep evolving the gaming community Is this in first-person or third-person? This will be a third person game. We can play around with the camera angles but I kind of want it from a aerial pov I saw RPG in the post so can I assume that the game will have generic RPG elements, e.g. quests, npcs, story-line, items? Yes this will have generic RPG elements. But with a few surprises that make the game different. Such as making boss fights some type of minigame. I don't know how the audience will like or even if it'll flow with game play. But I'd still like to take the idea on for now. Will there be combats, e.g. vs. monsters, vs. players(?) ? There will be tons of concepts. As i've said before the 'Nine' comes in the Nine isles of this world we haven't named yet lol. Each nine islands we come up with will not only give players plenty of content to play, but something we break up into story chapters. Each island will have its on set monsters tied to the story or even monsters that are just natural in their environment. There will also be a PvP aspect which can't be brought up too much because its difficult to try to come up with a player style culture that isn't too predictable or generic or even cliche. I was wondering if it should be an initiated fight or a head on duel like world of warcraft. Is this a single player game or a multiplayer one? Definitely multiplayer. Will the game look like Minecraft? like a voxel/blocks game? I imagined it not looking like minecraft but maybe that can be a concept of its own down the line (like an island concept). I was thinking along the lines of a 3D style and not like minecraft. What are the core mechanics to be included, e.g. player movement, enemy movement, enemy AI? This question is more technical but there will be interactive things in the world, things to collect, natural occurring crafting supplies to make new loot and weapons with. There will be NPC's and thats a broad topic enough lol. I'd even a imagine a pet, housing, and gardening system. But thats for accessories in coding and to give more content in the game for later polishing. Is there a storyline already made? There is an indirect storyline. We've made a script for voice actors (and just what to make the NPC's say in general) in A9 v1. Are there goals already planned out? There are many goals to set out. One each at a time for separate upcoming departments The first 8 pictures were of our hub, the other 9 was our factions world. The factions world doesn't retain to this project I wanted you to see how dedicated I was to making this project. I built everything in the hub myself except for the giant pagodas. The last two photos were all the ones I could find of the RPG world
       




















    • By bzt
      Hi,
      I was looking for a way to effectively interpolate between skeletons represented by list of bones with position vector + orientation quaternion pairs. To my surprise, I couldn't find any good solution, not to my taste that is. I can't use NLERP because I need a general solution, and NLERP is only good for small distance interpolations. SLERP would be perfect, but I couldn't find a decent implementation, only slow ones, so I spent a lot of time looking at game engines and quaternion libraries and reading academic articles on the topic. Finally, I decided to collect my findings and write my own optimized version of SLERP, which focuses on performance over precision, and which I now would like to share with you.
      Optimized cross-platform SLERP
      I've started from the well known formula, as implemented by most C++ libraries, and used all the tricks I could find on the net. Then I took it to the next level, and made some more adjustments on my own speeding up a little bit more. Finally I ended up with two solutions:
      1. one that is cross-platfrom, ANSI C solution that is easily embeddable in C++ and compatible with any C / C++ quaternion class (provided their data can be seen as 4 floats), very simple, very minimal. Use it freely if you want, MIT licensed
      2. a SIMD version, which I had to leave half-ready, because my compiler and Intel disagree on what intrinsics should be provided for SSE, moreover the compiler does not work the way its documentation say it should :-( Shit happens. I would only recommend this for experimental purposes, also MIT licensed
      Both versions are simpler and much faster than any implementations I could find, designed to be called in a loop several times. The only dependency they have is lib math (acosf, sinf). The SIMD version is half-ready, but even in this form it's almost 1.5 as fast as the other one, especially if you call it in a loop with memory prefetch on the quaternions.
      If I made any mistake, miscalculated or mistyped something, let me know. If anybody has an idea how to overcome that intrinsics blockade I have, that would be appreciated very much, because I can clearly see the path how to make the code several times faster, only if I could get rid of the library calls. I also plan to create an ARM NEON port once I have that.
      Cheers,
      bzt
    • By TheAGamer39
      Hi, I'm currently working on this game by myself and was wondering if anyone wanted to help I'm looking for programmers, illustrators, pixel artists, sound designers and developers. I'm a young teen and I prefer to program, I have a basic idea for the game but need help creating it and giving it some more uniqueness. Basically the game is a 2D, could be 3D if someone can teach me how to code games in 3D, and a large world adventure game were you have to fight monsters to level up and collect increasingly powerful items . There is also going to be a mysterious part of the game where you have to find certain artefacts and decode messages to get the best gear. I really hope people are interested please join my discord server: https://discord.gg/c5Ce9Q4 or contact me via email; theagamer39@hotmail.com if you want to help. Hope you have a nice day!
    • By JeremyAlessi
      In PixelCast 7, Jeremy hangs out at Pixels = Pints + Bytes for the latest PixelFest Devs meetup and chats with two local indies about their studios. Joshua Jané demos 'Bouncy Bear' and explains what makes 'Just Bare Games' tick, including the fact that all their games contain bears! Meanwhile, Joseph Musso of Sunset Studios let's us in on the game he's been pondering for 10 years ('Santa's Sleigh Ride Sacrilegious Arcade Action'... say it three times fast), which is now playable after coming out to a PixelFest Devs meetup back in August.
       
       
       

      View full story
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!