Games Biosignature: Aliens-inspired 80sSciFi TopDownShooter (4 Player Couch/Online/Mixed Co-op)

(I'm currently not able to work on this project due to lots of good things going in my life, but this is to be continued!)



~ Remember when you gathered in your basement for all night long playsessions?
To fight critters and try keeping your eyes open at 4am? We do, and we want to have it all again. ~

▼Latest Update: 05-Dec-2017 - Stepping sidewards▼​

Theme: 80s Retro-SciFi, I'm looking for something that looks, feels and sounds like Aliens (J. Cameron)
Oh, that film! <3

Latest media:

Gameplay:

• 3D Top down view
• Mouse/KB and/or Gamepads
  
• Shooter with ammo and reload mechanic
  
• Coop, with up to 4 Players on the couch, online, and also mixed if you like
  
• 4 Characters with differing basic stats (you can still finish the game alone - looking at you, alien swarm tech!)
• A set of weapons, not too much though. We don't care about "a bazillon gunz".
• There will be a story.
  
• You start in a hub section. When the story progresses, new areas(levels) unlock.
  
• Varying set of mission objectives (story driven)
  
• Probably semi/full procedural levels, if that won't harm the experience/us/you/neighbors/pets
• No permadeath (at least not mandatory)

About me:
My name is Philipp. I'm a professional software developer from Germany working in the simulation/eLearning business. Game development however is my passion. In spring 2016 I started working on Biosignature in my spare time.

Links:
biosignaturegame.com – the official game website.
biosignature on indiedb – they rock indie games one pixel at a time.
myself on twitter – I will update it on a more regular basis, twitter style.
g-phil.com – still the best place

Development progress and imagery will be posted below! Thank you for your interest!

 

Dev Update 4-Aug-2016:

So I'm working on this game for about 3-4 months now.
I am very focused on tech, so I worked a lot on all the technical base to make sure everything is hooked for further development.



Implemented Features:

• UNet based networking in place, with matchmaking (Make new matches with or without password, join matches).
• Some test levels and a lobby scene which will be the hub later on, where you can select your character and gear up.
• More local players can join there by hitting a button on their controller.
• Camera keeps track of all the active local players, but you have to stay together (it zooms out to a certain distance though). Theres no splitscreen because thats more drawbacks than benefit. You need to render everything multiple times which is bad for performance, and you can also forget about 3D audio, which is bad for atmospheric experiences.
• Shooting, ammo and reloading is in place.
• Basic HUD is in place, but it will probably change over the course of development
• Basic enemies (melee/range combat) are hunting the player
• Generic environment interaction system. One player may interact at a time and can select actions from a list.
  Theres things like keycards(pick up), doors(unlock/open/close/weld), terminals(retrieve data)
• Shop where you can buy weapons with credits
• All progress and stuff like the current inventory is written to disk. I took care of that because if the games host loses connection or his machine crashes, we really don't want to start all over again! Every player will have the last games state and can restart from there, also as the new host!
• Theres already a system that cares about level progression based on if a levels mission objectives are fullfilled

 

Dev Update 17-Aug-2016 - Procedural Level Generation and porting to 5.4

Hello! Just came back from a little vacation in italy Now its time for an update:

The project keeps going well. I do think a lot about what to focus on next, and to me, highest priority in development is to get something playable as fast as possible. So now, it was already playable but piecing levels together by hand is a task I don't enjoy so much (mostly because I'm unable to do that from the couch on my laptop easily, I prefer hacking code while I hang out).

So I thought and read a little about procedural level generation and I decided to give it a try.
Here is what I got after three crunchy evenings so far:



Thoughts on generation:

• First and foremost, I wanted to have a logical traversable tree. Why? Because now I can do things like locking branches and putting keys in other branches without accidentally placing the key behind the locked door.
• The generation is seedbased. That means I can put in a fixed value per level and will always get a fixed generation result. Thats not only perfect for testing but we will also probably give the player the option to enter a seed-base for a new game (for a more measurable experience) or let them roll dice.
  
• I think, while this might be a valid infrastructure in reality, it might probably suck for gameplay, even more if it was the only type of layout presented. So I will use multiple algorithms and let them calculate multiple connected areas lateron. These areas could also vary in theme, like what you see up there would be a maintainance area, another one with broader corridors might be a sewer etc.
• Generation and multiplayer will probably be tricky. Only the server may place netobjects like doors or enemies.

A word on the port to unity 5.4:

As we all know, UNet is still in development, and so I was curious what might break. Fortunatly it wasnt that much. I had to adjust some overridden functions in my network manager because arguments changed a lot in the base class functions. In my test, everybody could connect and disconnect/reconnect also seemed smooth. So I guess everything is fine again but who knows what further testing will reveal.

 

Dev Update 02-Sept-2016 - Procedural Level Generation Progress

Hi again! This is just a little update, I'm still working on level generation.
Good news is I made some serious progress:



I could identify four major steps in the generation process:

1. Generate an abstract area tree, based on parameters we define in the editor per level. This includes main- and sidebranch depth as well as an extendable set of room layout types (different generation algorithms) and their appearance probabilty. This is completed.
   
2. Generate the floor plan: Generate rooms based on the input algorithms and connect the generated rooms along the given tree. Tests showed that a breadth-first algorithm is much more reliable for generating a floor plan than a depth-first algorithm - depth first does often fail because it tends to trap itself much like in a game of snake. This is done but can still be extended by writing more generation algorithms (i.e. cellular...).
   
3. Place geometry based on the floor plan. Each room knows its tiles and is provided with a design pattern (sets of meshes as well as placement algorithm settings). This is what I was working on recently. Most important is that I need to take care of tile reduction, as there can be millions of tiles and I don't want them be all unique game objects. In the gif, different mesh sizes are identified by different colors from red - small to blue - large. Also, the environment will be more believable if things don't all look grid split evenly.
   
4. Create gameplay, means placing gameplay relevant elements. This is what I will do as soon as I finished step 3. This will also be refined/extended until all development is finished.

To me these last two weeks were the hardest in all the development process and I'm glad its finally working.

Now I am pretty excited to see how the levels will look when the generic tiles are replaced with actual art

 

Created a personal development blog
If you're interested, visit:
http://g-phil.com/

 

Dev Update 12-Sept-2016 - Integrating generated Levels.
Also: Moving our project repo to a vServer

Hey hey, time for another update!
Last week I put some more effort in the generation process:

• Added Furniture: What I had was the placement of floors and walls prefabs. Now I added furniture support. Furniture might be a) attached on wall prefabs: terminals, shelves, whatever is attached to a wall or b) stand free in the room: Everything from crates to desks or pillars or actual rooms (like cell rooms, server containers etc) is possible.
  
• Controlled generation of networked content: I added a mechanism that is seperated from the generation code itself and takes care of spawning network objects on the server. Example: The generator puts a doorframe. The doorframes prefab has a script that will spawn the actual netobject door on the server.
• Navigation(AI): Since the levels are nonexistent before runtime, Unity navigation falls under the table as long as it does not support generating navmeshes on the fly :-| So I moved to the free version of the A* Pathfinding Project and use its gridbased navigation system instead. That meant I also had to write a navagent but actually it wasn't all that hard to get this figured. Currently they don't have any avoidance, I'm going to add that later. Now, as soon as generation is finished, the pathfinder is set up properly and scans the generated geometry.

And here is me walking around in the generated level:



Project management: Leaving dropbox and moving the project repository to an actual server
Yes, I did actually run SVN with my dropbox account before. While this goes well when working on a project alone, as soon as there is more than one person accessing at a time, it can lead to corrupting the svn, yikes. With that fear in mind and looking at all the expensive cloud version control offers I decided to rent a Linux vServer and install svn by myself. Total nerdstuff but now I have a server with 300GB diskspace running svn for 8€/month, which I think is quite awesome

 

sweet concept

 

Cool stuff.

 

Dev Update 23-Sept-2016 - Adding gameplay elements and level flow to the generation process.

Hi guys! The geometry generation is stable now and I started working on adding actual gameplay to the generation process.

Adding gameplay object slots:
I figured that I will need a place where I can put any gameplay relevant object. The problem is that when you're procedurally generating, you have to:

1. Somehow be able to identfy valid spots to place your specific gameplay element.
2. Make sure that you always have enough options to add all or at least a significant subset of the gameplay elements you want to have in your level.

In the previous step, I did not only generate the empty room but I already filled it with furniture.
So now I decided that I do not want to interfere there by placing logic during that step, but afterwards (mainly to keep the code and the process clean).

The way I do now is that I add slots to all the assets generated before (Floors, walls, furniture etc.) and put my gameplay objects in random valid slots:

The slots do also have types so I can not only place items but also replace a complete asset with a gameplay object, like replacing a wall with a vent where I can spawn enemies.

Locking areas:
Before I started working on generation, I did already implement a locked doors and keys mechanic. Now I successfully integrated it in the generation process. This mechanic will help to motivate the player explore the level instead of rushing through. I do not only want to use keys and locked doors lateron but also lock areas in various other ways, like the player will need to flip a switch to restore power in an area, or opening airlocks to extinguish a fire.

To make sure that such mechanisms will always work, I generated the level from a tree structure like so:


The nodes represent rooms, the edges represent doors.
Now I can place the lock and key in a way it won't break the level (key behind locked door problem):


Note that I locked two doors, as I identified two motivations for the player:

1. Overall progress - lock the main branch to keep the player from finding the exit/mission objective early.
2. Loot/Treasure - you will want to open this door. These are always leafs in the tree. It makes no sense to ask for a key when you already passed a door where you needed that specific key, so such a room is never beyond the main branch lock.

The locks mechanism can also be chained along the main branch.

Bonus track:
I found a nice video about H.R. Gigers Alien and decided to write a litte about monster design, read it here:
http://g-phil.com/the-beauty-of-the-beast/

 

Dev Update 06-Oct-2016 - Equipment System, also: Aliens in the air duct.

Hello! In the past few weeks I have put a lot of work in existing systems as well as new ones.

Overhauling the Equipment System:
Before last week, you could carry one weapon and swap/buy new ones from a shop in the lobby. Now actually, that does not quite fit to the story outlines. So I decided that a more “survival” approach would fit better.

Now a character can carry a primary and a secondary weapon, ie a rifle and a pistol. If you find another weapon, you can swap it out.Your previous weapon is dropped and can then also be picked up by another character. Another decision was that the pistol has infinite ammo, so for now, this system is a lot like L4D’s:



However, chances are that infinite ammo will be removed later in development and I'm gonna add more options to avoid or kill enemies without firepower. I hope this will result in a more thrilling, adrenalin kicking experience.

Aliens in the air duct:
With the procedural generation I do now also always have to make decisions about how to distribute new features within the process. However, it also allows me to introduce mechanics that would be much harder to implement otherwise.

Do you know Duskers? I can really recommend it – if you like typing Anyways, its about that you board space vessels with drones. Now Duskers presents you a very reduced top down view of the ship from where you can command your drones by typing a set of console commands. Of course there are hostile lifeforms on the ship, and those are usally trapped within a room. You can use motion sensors to check whether there is movement in a room or not, without entering it. Knowing that there is a threat before actual confrontation is really tense.

This is why I implemented a “roaming swarm”. The swarm invisibly moves from room to room. When the swarm is over you, it will break in the room and you are in trouble! You can however a) hear it moving in the air ducts and b) also see its motion on your minimap as soon as you have unlocked motion sensors.

You can now not only prepare for a confrontation but instead, you can also avoid it. One option is the players will be able to hide in lockers or under tables. When the swarm is on your room and everyone is hidden, it will move on. Hopefully everyone found a spot to hide though! The second option is that you seal any vents in your room. That will take some time but once its done, you have created a save room. Sealing vents is of course limited, so choose wisely!

 

Dev Update 24-Oct-2016 - The Minimap

I’m back from a trip to Greece and now it’s time to get things rolling again.

The Minimap:
It sounds so unimportant and tiny, but it is literally a gamechanger!

In a first person perspective game, you can only always see a “slice” of the world, which is the cameras frustrum/the viewcone. However, that slices length is infinite(almost), and you can simply rotate the camera to get the full picture of your surroundings. But when you play a top down perspective game, you face a dilemma: You can just always see as far as where the screen ends. Especially in large rooms this is a problem, since you will always have to roam around in all the room to find out what it contains and where the doors are. This is just as very tedious as it sounds.

The Minimap blows that frustrating task away. You can easily find your way around now:

 

Dev Update 10-Nov-2016 - Meaningful decisions

Unfortunatly the 3D artist who was helping me bring this game to life decided to step back. I can totally understand everyone who is working on such a project and at some point leaves. It is hard work, and you spend your valuable sparetime, not knowing if your project will succeed or fail. Still, meh!

Anyways, luckily I have a good design background myself, so this is at least not a showstopper.
However it means much more work on my desk now. Challenge accepted!

So, over the last week I took the chance to take a step back and look at the general direction the project is going. I thought about setting, plot, progression, everything that will set the tone of the game. Not everything is set in stone now, but I know just enough to return to development and I’m already hyped to tell you more in future updates

So long,
Philipp

 

Really cool project, I hope to see it come to life!

 

Interesting project you are working on! I'm keeping an eye on this.

Checking your profile I just noticed that you are from Ulm. Did you know there's a dev studio in your city?
http://www.digitalmindsoft.eu/
Afaik they are still looking for programmers.

I'm just mentioning it because it'd be a shame if you live so close to them and didn't know about them.

I've been in a kind of similar situation. Some day I found out that 2 minutes walking distance from where I lived was a media-design agency that I had been living close to for years, without knowing about them. I only found them when I was looking to rent an office, and met some cool people there.

 

Hey Martin, Thank you!

Actually, I already have a full time position as Unity Dev, I'm in the Simulation/ELearning business though.
I did in fact not know about the studio ^^ I always thought Ulm is kinda the black hole on the map for game devs, seems I was wrong

 

Oh well, if you are ever looking for a new job you now know one more option . Or maybe you stumble upon someone else in the area, who might be interested. I've already sent a 3D artist to them, who seems to be pretty happy with his new job there.

 

Dev Update 22-Nov-2016 - Switch to semi-linear game flow

While I was poking around the games story I figured that I need to change the games current progression system to fit new requirements. What I had was one lobby/hub level where players could join the game and from where they could choose from a set of game levels. Once you solved all the levels, you solved a stage. Once a stage is solved, you get a new set of game levels to choose from.

Thing is that this system gets in the way a lot when you want to write a story for a game, because in most cases it just doesn't work out without a change of location.

Now I redesigned the game management so it supports multiple lobby/hub levels which are chained linear or even non-linear. Now I'm able to build a much more interesting game flow like so:



Multiple scenarios here:

1. Multiple levels in a row that connect to a new lobby. This is pretty useful if I want to connect levels that have different themes.
2. Choose from a set of levels that unlock the way to the next lobby. Imagine you need to complete a set of mission objectives, like say powering a door and additionally find a keycode to unlock it.
3. Forking parts are also totally possible. This also adds some more replayability.

Needless to say this also affects how the save system works. The game progress and the players inventories will be saved on all clients whenever the players successfully complete a level. If the players fail, the server will reload the last savepoint and the players restart from there.

 

Dev Update 29-Nov-2016

Just a little heads up, I'm currently working on the playercharacters

 

First player character is ingame. Here a first glimpse - it's getting dark and cold....

 

Dev Update 03-Jan-2017: It's alive!!!

Long time no see! I started working on the player characters. After setting up a solid technical pipeline I did some modeling and rigging and successfully imported the first character into Unity:



Cpt. Runar "Rune" Sigmundsson

From there I worked on the animation system.
I didn't want to break the currently quite fluid player movement, so I decided against animation driven moves but instead moving the player is driving the animation. This is also much simpler considering it needs to work in multiplayer. You usually just send transform data so you need to work with that anyways.

So the idea is that the players character is disconnected to the actual player object, observing the absolute position and rotation data and interpretes it in a way that feels not rigid but how a human would actually move along that input. The body and legs rotate according to the movement vector, while the upper body and head rotate towards the actual view vector. I also use a maximum twist constraint, which will decide whether the character needs to walk forwards or backwards to resolve the input transform.



The next step was to enable the character to wield weapons and get the aiming to work. This is actually not that easy, because you need to decide between two approaches: a) the more arcade like, turret type system where the weapon is always centered. You can see this in action in the Alien Swarm game. However I feel this works fine there because of the more cartoonish look of the game. But it would probably not look good here, so I went for b), which means you have the weapon on your side, with a significant offset to your body center. This unfortunatly means that players need to work harder to get their aiming right, however I think I could minimize that issue. Probably It'll need some retouch later though. Anywas, see the system in action:





Good thing with the offset is the players will have more benefit when finding upgrades like laser pointers ;-)

Thats it for now, I hope to show you more soon

Cheers,
Philipp

 

This is awesome work

 

Second player character is in the making. With the workflow I established now it takes about three 8h workdays to get one character game-ready. Can't work on the game fulltime unfortunatly but I will just keep going!

 

I like the effort you put into this project and I'll be watching this thread. Keep up the good work.

 

Thanks a lot! It's a tough journey so far ^^

Here's a screenshot of the new character

 

Just tweaked some textures and material settings, and like to share this screenshot with you

 

Dev Update 26-Jan-2017: New playercharacters, also: Rendering

Hello there!

I just finished the third player character! Phew! This is an in-engine, realtime screenshot:


Pretty amazing result considering when I think six, seven years ago at the university, we had to wait minutes for rendering a single frame like that!
And this is an actual ingame shot of the latest protagonist, the pilot:


Getting my rendering right:

So when I started working on the player characters and tried to feed my textures into Unitys standard shader, I failed to get the results that I was expecting. I recognized that it would make sense to take some time to actually read the documentation first So I learned about Unitys physical based rendering approach and with some little hints from Sascha (thank you, really!) on how to work with the textures color channels I was finally able to get the materials working. These sheets here are really handy also.

Now when you start reading the docs, you will also very likely read this page about HDR Rendering. What I learned from it was: If you want to have all the nice rendering, you should really have your project using deferred rendering path and also work in linear color space. Which is not set by default. Yep! So what is linear color space anyways? Turns out your screen screws you over all the time. And your digicam also. Usually all that media works in gamma color space, which is basically dark colors are saved more precise than bright ones. However rendering on your GPU is done linear. So when you work in gamma space, you will get different results as if you are working in linear space. Turns out lighting is pretty S*** in gamma space! This site explains it in detail, a must read!

See you next time!
Philipp

 

Dev Update 08-Feb-2017 - The crew! Plus: Title announced & more 3Dness

Hello! Time runs by fast! In the past few weeks however I did several things: Finally the game has a title! I also finished the player characters (first iteration) and I added camera rotation control for more emphasis on the 3D aspect of the game.




So this is it! This is what I have dedicated and will dedicate countless hours of my sparetime to! A tribute to my beloved SciFi genre. My attempt to bring fun and thrill to your homes.

As I wrote in the games description, there will be a story. I won’t go into detail here, but in case you didn’t notice, theres a hint in the title

After wrapping up the identity I decided that its time to go social and spread the word more offensive.
I built a small network of places where you can follow the project from now:
biosignaturegame.com – the official game website.
biosignature on indiedb – they rock indie games one pixel at a time.
myself on twitter – I will update it on a more regular basis, twitter style.
g-phil.com – still the best place

Now on to the playercharacters:

IGCSS Ultralight Cargo Vessel “Asimov” crewmembers:



Cpt. Runar “Rune” Sigmundsson




1st Lt. Jenna “Jet” Gauss




2nd Lt. Rufus “Puzzle” Kent




SSgt. Maximilian “Toast” Petit​

Here they are! I can’t wait to see them kick alien ass shoulder by shoulder!

And last but not least, after my excessive 3D session, I did now start coding again. When I was a teenager, I had long overnight playsessions with a very good friend of mine. One of the titles we couldn’t stop playing was Blaze and Blade on the PS1. This one is also a local coop top down game, though its fantasy.

Anyways, its 3D and there you were able to rotate the camera with the bumper buttons. I really liked that, so I decided to bring this feature into Biosignature. Do what you love, right?

See the system in action:



Thats it for today! A big thank you to everyone who is following my project. All the positive feedback is really helping to keep me going!

Cheers,
Philipp

 

Quick heads up, I spent some time upgrading the animation system - now there are additional strafe animations, seperate armed/unarmed movement layers as well as IK recoil (parameterizable):

 

Good progress! I respect your ability to push on despite obstacles. I am digging the camera angle on your project, it kind of makes the player feel small in a big world...while still feeling empowered thanks to the weapons.

 

Thank you!

I'm about to wrap a build for a first little 4 player test session, hopefully I can run it in office on friday during lunchtime.
Planning to do a screencapture and post some impressions with a new devlog update I'm really excited

 

Dev Update 27-Feb-2017 - Video footage and implementing gameplay distribution

So since I’m back on coding again, I started to design and redesign how gameplay is distributed within the generation process as well as live. I also set and reached a milestone last friday, which was having a multiplayer test session and produce some footage for you to watch

Multiplayer Test Session
Having something stable and playable at any given time in development is crucial. It took me some time to get everything running fine again after updates and lots of refactoring, but I managed to reach my goal of letting my colleagues play the game a little during lunchtime on friday and capturing video. I spent some time packing the footage together, adding a little logo animation and producing some audio (the logo audio is also a taste of what the game soundtrack will be like later). Here it is:

Gameplay distribution
Since I use procedural generation, there is little to no chance for me to actually place any enemies, items etc. myself.

Instead, I have to make the generator do the work for me. My levels are very much area based, so I decided to place enemies, loot, hazards, key items on an area basis. They might also be combined. For me, the best metaphor to describe how it’ll work is the generator is playing cards from a given deck. I can define the set of available cards per level, this is how I can control when particular gameplay elements are introduced to the player. Another benefit is I can force certain combinations of enemies, like a melee one combined with range support, or combine enemies with hazards, to create new situations for the player to solve. I also figured I can now deploy a rythm of good cards followed by evil cards, repeat. I call those Area Cards.

Further, I decided to implement a Director AI. This concept was first introduced in Left 4 Dead and I think it is a perfect fit for Biosignature. What it does is it tracks the players stats and their stress level. Then it can react to those to keep a defined stress baseline. I liked the term so the Director does now play Action Cards. It might be spawning additional enemies or help the player out by presenting long needed health packs to them. The chance of the game placing enemies in their backs will also keep the players on their toes much more.

Thats it for today!
- Philipp

 

Dev Update 13-Mar-2017 - Area based directional lighting and cyclic level generation

The previous weeks were really busy! I could spend a good amount of time working on the project during the weekends, mainly on getting lighting work the way I want it to be and also on level generation. And there is some exciting news with the latter, however: First things first!


Area based directional lighting

So this was really a hard one. One of the key features of Biosignature will be how darkness can be really pitch black dark on some occasions. This is, naturally, to prevent you from seeing enemies and your surroundings so you will be forced to use flashlights and otherwise percieving noise:



Another shot, this time with headlight enabled:



On the flipside however, when you turn on the light in a room, light should ideally be nearly equally distributed within the room. This is quite hard to produce without either a) ambient lighting or b) a massive distribution of point/spotlights, especially if you have big spaces. Ambient lighting is off the table because it won’t respect yet unlit areas, and point/spot lights do need shadows to prevent them bleed into adjactent unlit rooms, so that could become quite expensive.

So I was thinking about solutions. One would be to write a shader that uses an additional greyscale texture input. The texture could define where and how much ambient light is added to the surface. But I really didn’t want to do so because then I would always need to stay within the bounds of that very one shader.

Then I had a kinda weird idea. Why not hijack Unitys lightcookies?! After some experimenting I figured it would actually work well enough to do what I would need it to do.This is how it works:

• I place a single directional light with a script attached in the scene.
• The script cares about positioning and resizing the cookie to fit the level bounds (I know the bounds because I procedurally generated the level before).
• Then it writes a texture into the lightcookie input and updates it whenever a light switch is flipped.

See how this looks in action:



And this is the concurring lightcookie texture, getting updated by code:



For ease of use I just write one square meter into one pixel.


Cyclic level generation

Last week I decided to redo how level generation works in Biosignature. That decision is based on a pretty amazing talk by Joris Dormans I recently found on Youtube:
Joris Dormans - Cyclic Dungeon Generation - YouTube

The main idea is that rather than having a generated level be a tree with leaves being all dead ends, you can instead have the leaves circle back into the main branch. With that structure you prevent lots of backtracking and you also create levels that feel much more connected and handmade. The circles do also allow some pretty good game design tricks.

Since I am not under pressure with finishing the game – it’s still a spare time project after all, although a very serious one – I decided to shoot for it! And I figured it is actually doable. The only major issue I had was that I needed to implement my own very condensed A* pathfinding to reconnect branches back to the mainbranch.

My current state is that I successfully generate a mainpath and circle out side paths that can be used for multiple purposes, based on the circles direction (circle forward/circle backward). I also added an extra route that connects the near end to the near beginning of the main path and serves as a shortcut back. Visualized it looks like this:



In Biosignature, the levels will also be traversed vertically:



It works very well and I already planned the next steps in development. Excitement!

See you next time,
Philipp

 

That lightcookie texture generation trick is really clever, kudos to you!
I need to check that talk on dungeon generation out, looks interesting. Thanks for linking it.

 

Small update: The previous days I worked hard to implement the new cyclic generator. It's already generating actual geometry again, thankfully I can reuse most of the old tree generators code.

Now there is still few more things I need to rewire. I guess this will take another week. Then I need to look into how to generate cool substructures into each of the area nodes, because currently it's just a single big room per node. Thinking hallways(grids, labyrinths, circles) or some kind of binary space partition patterns.

I'm sure implementig this will turn out to be worth the effort, but its also really tedious right now

 

I love you´r work! i will follow this game dev .
It´s amazing how you have bean doing this for all this years!

 

Thank you!

 

Dev Update 08-Apr-2017 - Culling floors, the hard way!

Well hello again! The past week was probably one of the hardest for me in all the development process. I ran into a problem that occured as a side effect of me wanting to have the levels spread over multiple floors.

You want to always see your player character!
As simple as it sounds – with a top down camera, it’s totally not. Whenever you are in a room which is below another room on a higher floor, you won’t see anything anymore because your camera will show you the upper room instead:



So what you naturally want to do is to somehow hide that room. Thing is, how do you figure when and what to hide? There are a few options available, but not every option is applicable for my case:

1. A manager script. Pro: Full control over everything. Con: But what will you do with all the non-static content? Other players or agents might enter that room, new renderers might be spawned over the course of play(like shooting bullets etc) and you won’t really want to constantly track everything, because this would be a) pretty expensive to calculate and b) probably very messy, bulky in implementation.
2. Unity Layers. Pro: A Built-In, lightweight solution. I could set all objects layers to their respective floor and just render/not-render based on the current camera position. Con: You still need a manager who sets the objects layers, which makes you run into the same problems. Even worse, as the built in layers are also used for physics occlusion, you would automatically sacrifice that convenient feature just for multi-floor levels.
3. Use the cameras near-clipping plane. Pro: Clips everything away with no hassle. Lightweight, no to little additional code required, the GPU does it for you. Con: Out of the box this would only work when your camera would point down with a 90° angle, but mine is more like 65°-70°.

So the third option was the most appealing to me, however I’d need to somehow force it to cull the way I want it to cull, which means I had to:

Customize the cameras projection matrix
Now what the near clipping plane does is clip away anything closer to the camera than a defined distance. Modifiing the distance during runtime looks like this:


So this is not really helpful yet. I need to find a way to have it clip away along the y-axis instead, and what I need to achive this is: Matrices. I was very good with matrices back at the university, but boy is that long ago. So what I naturally did was Google the S*** out of it. And Google delivered, I found that I will need the camera have an oblique projection matrix to compensate:



Basically the near and far clip plane should align with the xz-plane. And after a rough evening, I had a decent result:



Only that on the very next day, when I moved from the test scene and tried to implement it into the actual game, I learned that this actually does completely mess up the lighting, at least in deferred rendering. When the GPU renders shadowmaps, it needs the original projection matrix to work properly. So changing the actual projection matrix is a dead end for me. But there is one more option:

Customize the cameras culling matrix
Yes, you can also do this instead. However it turns out that you can’t just use the previously calculated oblique matrix. I can tell that because I tried it The results are just plain wrong. Some research on the forums point to the culling matrix is somehow not based on the cameras origin but somewhere else within the camera space, most likely its somehow married with the near clipping plane. If you know how to get the matrix right, please let me know! In the meantime, for me it meant it was time to get creative. Fortunatly the Unity documentation pointed to another interesting direction. They use a second cameras matrix on the main camera. So what I did was this:

1. Create a second camera in runtime, also disable it as we are not interested in it to actually render.
2. Place the camera on room-height, ie 4 units above the current floor.
3. Let it point down 90°.
4. Set a FOV of 180° – so the camera is basically a super-fisheye and sees all the room.
5. Use this cameras projection matrix on the actual main camera!

And thats it!



Addendum: Since the new camera has a FOV of 180° it would actually see far more on the same level, so I also added a light weight manager that additionally culls static room geometry which is more far away, just for more optimization, however thats only the stuff I know from the generation process, so just some lines of code:



PS: New Unity version came out a few days ago, with a new command buffer command that could change the projection matrix during rendering, however it did nothing for me. Maybe that could save me the second camera, if anyone knows more, please tell me!

That is all for this week and I return to finish the cyclic level generator! See you next time,

Philipp

 

I would have never even considered having multiple levels in a top down game, simply because functionally a stairway is little different than a door and so it doesn't offer for any different kinds of gameplay. What happens if you have a character on the upper and lower levels at the same time?

Very nice technical stuff, though, no less. Looking good. Best wishes.

 

Did u have a test version atm ready =)? / hast du auch schon eine testversion feddisch das man sich das mal anschauen kann ?

 

Thank you!

Having characters on the upper and lower levels at the same time is only a problem when playing in local coop mode. There however, the players do need to stay together anyways so they don't get out of the cameras sight (no splitscreen-mode). So they will need to communicate whenever they traverse vertically. I then just use the highest player character as a reference point and show the upper floor whenever that character reaches a certain height. I thought about adding a xray-effect for hidden player characters, but we'll see. Maybe a UI-indicator is enough

For me, the point about having multiple overlapping floors is not the stairways or elevators, but the actual overlapping space. It allows for some interesting settings, mostly whenever you allow the player to see down on the lower area. Again, I got inspired by one of the slides Joris Dormans presented when talking about cyclic level generation, actually it was a lovely D&D map made by Mike Schley (purchasable through this link):



Notice the bridge in the middle of the map, now how cool is that!

Imagine you traverse over the bridge first, but you can't go down yet. However you can see there is a treasure chest down there. Can't wait to get there! Or imagine there is a terrifying monster down there. Now when you finally reach the river, you will be thrilled. Vice versa, imagine you made it through the river and cross the bridge afterwards. You will be reminded how you made your way through this area and feel achivement/progression. You can do many more things, like "platforming", with the chance to fail and drop down to the lower floor.

Another aspect is you gain a third dimension for your algorithm to plan your level. You sure know about how well executed the world layout of dark souls is. Its connectivity is amazing, and I think this is only possible because it is spread across the y-Axis a lot. Ie, my algorithm is trying to produce a shortcutloop from the last third of the dungeon back to the beginning, where it might have placed a comeback place like a shop or similar. This is much simpler when it can create a bridge or a tunnel.

How well all that will work out though, I can't really tell yet. I will just continue explore all this.

 

Momentan nicht wirklich - nachdem ich den Generationsalgorithmus neu aufgezogen hab, liegen gerade noch ein paar lose Enden rum. Aber ich versuche so schnell wie möglich wieder alle Komponenten am Laufen zu haben. Dann sehr gerne

 

Small Update concerning all the custom culling:

So I did some more research and testing and found that my issues with using oblique matrices are caused by actual Unity bugs. First one is that breaking shadowmaps is not considered expected behavior for custom projection matrices. And that is when I ran straight into the second bug that didn't let me use the oblique matrix as culling Matrix, because that bug screws the culling matrix when it is passed to Umbra - the near clipping plane is just plain wrong.

Anyways, happy to say I could massivly improve my current solution by adding selfmade AABB frustum culling:

 

Looks really cool!

 

I love the game so far but here and in the last video with gameplay I see that when you shoot sparks fly out of the gun and you can't really see a tracer. The sparks look sort of like they are bullets too. I'd suggest making a larger tracer and changing the color of the sparks and making a muzzle flash similar to this https://upload.wikimedia.org/wikipedia/commons/thumb/2/2d/FNFLASH01.jpg/1200px-FNFLASH01.jpg

 

Thank you!

Thanks You're right about the muzzle flash. Considering it is a pretty important visual cue for the players, I will try too improve it as soon as possible, prior to the next multiplayer playtest session.

 

Interlude 25-April-2017 - Vertical connections - The effort, the payoff

So I had another really intense week of "getting it right" with my vertical connections. No need to go into detail but it was hard, existential crisis hard.

However, yesterday I succeeded and could finally walk through the first generated Multifloor Level. And it really feels just great to explore and trying to find the keys to locked doors there, it all makes much more sense now. Now I was just watching this video and just hear Warren Spector underlining my thoughts (a bit of point 8 but mostly 9):

It's just perfect

 

Wow this is pretty awesome. Following

Reminds me of one of my favorite PS1 Games Project Overkill

Good luck!

 

Thank you!

 

Dev Update 30-May-2017 - Cyclic Level Generation 1.0

This time it took me a little longer to finish this next milestone – I had some crunchtime at my dayjob, so not much time to spend on working on Biosignature. However, I still somehow managed to keep the ball rolling and I am glad to say that the “dirty” part – getting cyclic level generation running – is finally done! YES!

Why cycles?

And why did I spend so much time reimplementing something I already had?! Well, because I hadn’t. My generator logically built a tree. This is a design choice I made to make sure that levels are always solvable and still give me the chance to put locks/keys without breaking the game. You can read more about this approach here.

A tree however is unfortunatly not really interesting for players to explore, and that is because whenever you follow a side branch, you will always have to walk back to the main branch. Backtracking can be tedious. And if anything, I want to avoid the player has a tedious, boring experience.



So, cycles! Or rather circles. They offer some interesting settings! Example: You come across a red locked door blocking the main path, and you need the red key to open this door, which you don’t have yet. So you go searching for the key in a side path. You find the key, and you also find another red locked door. You can now open this door rightaway, and you figure this is actually a shortcut back to the first locked door! So you never had to walk back. Actually you can push this to a point that you have a hub section with multiple cirlces around it. You will feel progression through exploration as the place slowly unfolds and more and more areas unlock.



Purpose and theme of cycles can vary a lot. Optional cycles may give you valuable loot but come with additional risk. There could be alternative paths that require a different playstyle or skillset, ie combat vs timing.

So, how to do it?
There are for sure lots of ways to get the job done. My generation algorithm is now broken down in 5 steps:

1. Generation of a main path and circles on a simple 3D grid – one node occupies one unit, and multiple units connect to a circle. Every node can have a maximum of 6 connections (North, East, South, West, Up, Down). I implemented a lightweight 3D A* pathfinder, because you need circles to avoid each other and find a way back to their root path.
   
2. Turn the grid into actual spaces or Areas. Initially, every area is the same size. However I want to add variety to minimize the feeling of the level being too gridlike. My requirement is that every node is a box, and that there are no gaps between areas. This is possible with a simple trick. I only change areas with an even xz-coordinate, like (0,0), (0,2), (2,2) etc. Then I only expand/shrink along either the x-axis or the z-axis. The neighbor areas bounds need to be changed accordingly.
   
3. Add Area connections. This is simple for horizontal connections – just find a place for a door on the shared wall. But it is pretty tricky for vertical connections, because they need actual space within the areas for a staircase or an elevator! In the above image, the smaller boxes are staircases. So I tackle this by shifting affected areas bounds, so that there is enough space for vertical connections but I can still keep every area have a box shape. This is important for the next step.
4. Fill the areas with a layout for rooms and hallways. This is the actual playground. You may add as many algorithms for this as you like, the only rule is that every area connection can be reached. I started by implementing a simple hallway algorithm and a circle hallway algorithm. Both can have siderooms which can additionally connect to each other. Algorithms may vary based on purpose and location (main floor, basement, attic, boss encounter, …)
5. Generate the actual geometry for the room layouts. Floor, walls, doors, furniture… Interiour themes as well vary based on the areas purpose and location. I could thankfully reuse this part from the original algorithm I had.

See a complete generation cycle:


Lovely!

Addendum: Runtime Navmesh Generation!

This is possible since Unity 5.6, just in time! I tried it out and got it working within an hour. So while the AStar Pathfinding project was really helpful, this is what I was actually hoping for, because a) I went with the free version and it had just the grid based navigation system for me, and Navmeshes are just not as griddy, and b) Avoidance! I don’t need to care about agents clipping into each other because Unity does it for me now Yes!



That’s it for today! I will now implement more actual gameplay and hopefully there will be a new playtestsession soon!

Stay safe and see you next time,

Philipp

 

Small Update 21-June-2017 - Working on Enemy AI

Hello!

So I decided that I will now concentrate on designing/implementing enemy AI.
Combat is a key feature of a Top Down Shooter, so I clearly need to make sure encounters are challenging and colorful. I'm getting lots of inspiration from Doom and its very chesslike approach:

What can we learn from Doom | Game Maker's Toolkit

I brainstormed different enemy types way back and now I'm glad I wrote that down well. So for different enemy types, I need to create distinguishable and rather predictable behavior patterns in order to enable the player to "dance the choreography".

Currently I am preparing the very basis for my AI systems. One thing for sure is I want to use behavior trees to design the AI which is a pretty common standard for game AI nowadays.

At my dayjob, I got the chance to design AI using Opsive's Behavior Designer extensivly before. However, after some back and forth I now decided that I want to implement my own behavior tree system for my game. I love the behavior designer, but at work I ended up implementing most of the nodes I need by myself anyways. What I really want is a system that is more light-weight, integrates easily and does just and only what I want it to do.

So I just started implementing the basis yesterday night, and it's already looking quite good. Made all the base nodes like composites, conditions, decorators and the behavior tree component ticking its tree.
Next, I will look into serialization. I'm most likely going to design and serialize using XML - did this before and I think it is very straightforward. I estimate it'll take me a week or so until I have the first basic enemy up and running using my system.

Already excited to come back to you with footage of my experiments