Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1379144 Posts in 65666 Topics- by 58033 Members - Latest Member: rosalindmc

July 12, 2020, 02:18:50 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsGravBoots - Zero-G FPS with Procedural Levels - DEMO | DEVLOG #4
Pages: [1]
Print
Author Topic: GravBoots - Zero-G FPS with Procedural Levels - DEMO | DEVLOG #4  (Read 2051 times)
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« on: June 09, 2016, 09:08:35 AM »

GravBoots

DEMO HERE (Windows & Mac): https://markwpearce.itch.io/gravboots

You are the lone survivor facing off against a horde of killer robots in a space station in Zero-G. Can you kill all the robots before they kill you?

Wearing your magnetic boots, you can walk on the walls and ceilings of a procedurally generated space station, facing off against robots intent on killing all humans.

You know the trope in sci-fi, that even though there's no gravity,  characters are wearing "magnetic boots", so they basically walk around like normal anyway? (See: Star Trek VI, Firefly, The Expanse, etc. etc.) Well, I made a game that uses that mechanic. Except - if you really could do that, you wouldn't be constrained to walking on the "floor" - you'd be able to walk on walls, the ceiling, a fridge, your cat (if you had a metal cat), whatever.

I wanted to make a game that was a short burst of FPS fun, that was always a different experience - so this game also features a procedurally generated space station invaded by killer robots seeking your destruction.

Features:
  • FPS where player and all agents do not react to a common “gravity”, but instead are “magnetically” attached to any level environment mesh
  • Movement in Zero-G maintains conservation of momentum - entities keep moving in a straight line until they are close enough to something that magnetically attracts them
  • Procedurally generated levels - every time you play, the setup of the space station you are fighting in is different every time you play


Screenshots









Dev Log

I'll be adding some posts later dealing with some specific challenges I've had - how to do "gravity", how the 3d level generation works etc.

Open Source stuff

GitHub: https://github.com/markwpearce/GravBoots
Trello: https://trello.com/b/Zb2uVdOU/gravboots
« Last Edit: October 06, 2016, 09:14:13 AM by Columbus007 » Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #1 on: June 09, 2016, 05:21:43 PM »

Dev Log 1 - Gravity

So this game is being in Unity… I’m pretty new to game dev, but I’ve been a professional software developer for over 10 years, and have dabbled in motion graphics and video editing, so I have a little experience in 3d. I made a few games in Unity before this (check out Evolatic - it’s pretty cool:  https://markwpearce.itch.io/evolatic). It’s always something I wanted to get into, and I’m fortunate enough to work at a place with a games department and we do game jams every couple of months, and this game was born out of a game jam there.

The first thing I had to work out is “gravity” (or magnetism really, but gravity has less characters, so it’s easier to type). I basically wanted the feel of movement in a regular FPS, but as you approached a wall and walked toward it, it would become your new floor - that is, that it’s normal vector would become your up vector.

So this meant that I basically couldn’t use a lot of existing things that Unity does for pretty much free - AI character movement, nav meshes, lots of physics stuff, etc.

Because the entities in the game are supposed to be attached to surfaces via magnets, I needed a way to discover what surfaces are around a player. I settled on raycasting out from the location of the entities’ feet 27 rays every physics update:

float[] coords = { -1f, 0f, 1f};
for(int i = 0; i< coords.Length; i++) {
    for(int j = 0;j< coords.Length; j++) {
        for(int k = 0; k< coords.Length; k++) {
             float rx = coords;
             float ry = coords[j];
             float rz = coords[k];

             Vector3 rayDirection = new Vector3 (rx, ry, rz);
             rayDirection = transform.TransformDirection (rayDirection);

             Debug.DrawRay( FeetPosition, m_gravityThreshold*rayDirection);
        }
    }
}


This code basically makes the rays that point out from feet of the entities in lots of directions, and go up out for the distance up to some threshold for which the magnets can no longer attract (I think I use 3 meters or so). I keep track of what rays hit, and the ray that hits the closest surface dictates which surface is applying “gravity” to the entity. I take the normal of that surface and then rotate the entity through a linear interpolation of their current rotation and what the desired gravity rotation should be.



This picture should give you an idea of what’s going on. The cyan lines are the rays looking for surfaces that could supply gravity. You can see the emanate out from a little yellow sphere at the bottom of the character (this is the “feet position”). The current ray to “closest surface” is represented as a red line, and the surface has another yellow sphere. Once we have the normal of surface, we just apply a gravity-like velocity in the opposite direction.
« Last Edit: October 04, 2016, 11:07:26 AM by Columbus007 » Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #2 on: June 10, 2016, 11:17:54 AM »

Dev Log 2 - Assets

So this is a Unity project, and to get a proof-of-concept working, I went straight to the asset store. I have no shame in that - plus everything I've used so far is free, because I'm cheap.

Here’s a list of the assets I’ve used in the demo:

Cyber Soldier - https://www.assetstore.unity3d.com/en/#!/content/52064

Used for the player’s weapon (Archtronic) and the gun the robots use (Hellwailer). These are just models - no animations for these…

Animated Crosshair - https://www.assetstore.unity3d.com/en/#!/content/54897
Right now, it’s just a simple crosshair in the middle of the screen. Future plans would be to animate it to grow based on player movement, and have weapon spread match (e.g. the faster you move the more spread there is)

Head Look controller - https://www.assetstore.unity3d.com/en/#!/content/4
This is pretty full featured, but I modified it to allow the character to either just look at a position, or follow another game object.

3 Skyboxes - https://www.assetstore.unity3d.com/en/#!/content/25142
Used for the space skybox

Game Jam Menu Template - https://www.assetstore.unity3d.com/en/#!/content/40465
Wicked. Plop in menu that does a lot for you off the bat. I modified the sizing a little.

Mixamo Pro Rifle Pack - https://www.mixamo.com/store/#/search?page=1&type=Motion%252CMotionPack&query=pro%2520rifle
Most of the enemy animations are blended from the standard unity third person animations, but I use some of these animations for holding the robot holding the gun, etc., with an animation mask that only allows it to change the torso and up of the character. In the future, I will override all the animations with these, but I think animations are a dark art in Unity, especially with importing them and applying them to a rig they weren’t designed for. I got enough working for what I needed, and then moved on to something else.

Sounds & music - Mostly from http://www.freesound.org
Search for “Robot”, “laser” or “Space station”. I probably used it.


I did the environment models myself - I'll talk about them later.

« Last Edit: October 04, 2016, 11:08:59 AM by Columbus007 » Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Xonatron
Level 4
****


Be yourself.


View Profile WWW
« Reply #3 on: June 13, 2016, 06:37:17 AM »

Coming in to watch your progress. Looking good. Curious, where did you work as a software developer for 10 years?
Logged

Matthew Doucette, Xona Games
- devlogs: xona.com/tigsource
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #4 on: June 13, 2016, 06:45:54 AM »

Coming in to watch your progress. Looking good. Curious, where did you work as a software developer for 10 years?
I worked for a while at a GPS tracking firm. I'm currently At REDspace, in Bedford, doing web development.
Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Shirsh
Level 0
***



View Profile
« Reply #5 on: June 13, 2016, 06:54:50 AM »

Looks very promising, and I hope you will really put metal cat in it, as npc or companion or furniture Coffee
Logged

Xonatron
Level 4
****


Be yourself.


View Profile WWW
« Reply #6 on: June 13, 2016, 06:55:02 AM »

Columbus007,

I know REDspace well. I met them many times at GDC San Francisco. We shared the same booth: http://xona.com/2011/03/14.html
Logged

Matthew Doucette, Xona Games
- devlogs: xona.com/tigsource
Sentionaut
Level 0
**


View Profile WWW
« Reply #7 on: June 14, 2016, 06:41:22 AM »

Hey! Finally, today I had some time to try it!

At first I felt a bit dizzy, but then I got used to it, and I think it has the potential to become a quite fun FPS. I actually enjoy this genre, and I also like games with these kinds of gravity mechanics, so I would definetly play something like this.
It would also be interesting if changing gravity implied a different meaning in the level structure, but I don't know if that fits with the kind of things you have in mind. I think Prey had some gravity mechanics, maybe? I haven't played it yet...

Keep it up! Smiley
« Last Edit: June 17, 2016, 06:22:51 AM by Sentionaut » Logged

Shirsh
Level 0
***



View Profile
« Reply #8 on: June 14, 2016, 07:06:54 AM »

Weapon to temporary turn off other's gravity boots and/or to shift their gravity source from boots to other parts of body could be delightful, destabilizing grenade or something Evil
Logged

PythonBlue
Level 2
**



View Profile WWW
« Reply #9 on: June 14, 2016, 11:26:13 AM »

Just tested it for myself. The concept is interesting, though I'll need to get used to the controls. XD

Still look forward to the finished version! Smiley
Logged

Python Blue - composer for NeonXSZ
Official Website
Bandcamp
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #10 on: June 16, 2016, 04:37:02 PM »

Thanks to everyone who played it. Feedback is really useful.

I'm working on another dev log entry on how the space station is procedurally generated.

Until then, here's a gif of a random space station being built:

« Last Edit: October 06, 2016, 09:02:00 AM by Columbus007 » Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #11 on: June 21, 2016, 09:28:39 AM »

Dev Log 3 - Procedurally Generated Levels

I knew that when I started this project that GravBoots would need procedurally generated levels. Mainly because I wanted the experience to be short, fun and different every time you play. Since the game takes place in space, I also wanted the levels to fit a certain sci-fi aesthetic of cylindrical sections joined together. This lends itself to creating a bunch of these sections and trying, somehow, to automatically join them together in some sort of logical way.

The first step is to create a bunch of cylindrical sections. Like I’ve said previously, I’m not great at 3d modelling, so I didn’t want to start messing with 3ds Max or whatever, but Sketchup is so darn easy to use. You can export directly from Sketchup Pro to a FBX file, so you can model and paint an object, and get it into Unity in like 2 clicks. All the models would probably look better in a better 3d modelling tool, but I understand Sketchup, and work pretty well inside of it.

After figuring out the rough sizing of the walls needed for a octagonal cylinder with end caps, I modelled a few “walls” and a few “ends” and exported them into Unity, cleaned them up a bit to set up the mesh correctly and add lights, then slapped a bunch together in configurations that made sense.



I also wanted each section of the space station to be logically consistent - a botany pod, a command pod, etc. So one I made up the walls of the pod, I put some other objects in them to give them a little character. It’s also important that each capsule has at least two ports, or exits on it, so they can be chained together indefinitely. All ports are the - hexagons about 3 units in diameter, so when it fits together with another port, they are consistent.



The capsules need a lot of work. In the demo, there’s only 4 different kind of pods:
L - one port on the end, one on the side
T - one port on end, two on the side
Command - half length capsule with screens and consoles
Botany - capsule with lots of windows and trees

Other than dressing these up a lot more with better textures and some greebling, I also thought things like an engine/reactor room, science labs, docking bays, entertainment pod, crew quarters, etc. would be nice to have as other possible sections in the space station.

Once I have a complete pod, I needed to give a collider so that it when placing the capsules together, I can guarantee they wouldn’t intersect. The collider contains the main capsule, but on ports (places where sections can be connected together), there’s a little bit of model outside the collider, so there’s enough overlap that there isn’t a hole in the space station.



Also, at every port, I placed an invisible cube in the middle of the port that was oriented such that its z-vector went straight out and its x & y vectors were oriented properly with the hexagonal port.



Now comes the fun part - writing the code that makes it all go together. I’m not going to paste actual code here (if you want to see it, let me know), but the algorithm for building the station basically goes like this:


ExistingPorts = []
Sections = []

Pick a station at random from the list of prefab sections
Add its ports to the list of ExistingPorts

numberOfSections = 1

while(numberOfSections < totalSections) {
  newSection = Pick a station at random from the list of prefab sections
  exsitingPort = Pick a port at random from ExistingPorts   
  newPort = Pick a port at random from the new sections
  Orient newSection such that newPort is pointing the opposite direction as existing port
  Rotate newSection by a random multiple of 60 degrees along the z-axis of newPort
  rotationAttempts = 0
  while(newSection collides with other colliders && rotationAttempts < 6) {
    Rotate newSection by 60 degrees.  
    rotationAttempts ++
  }
  if(rotationAttempts == 6) {
    Delete newSection
  }
  else {
    Add the rest of the ports of newSection to existing ports
    numberOfSections ++
  }

}

forEach(port in existing ports) {
  Orient and add a port cover
}


Now for placing the enemies and placing the player. To each of the prefab sections I used, I added some more locations (as red cubes) that were starting locations for either enemies or the player. The difficulty slider in the demo basically adds enemies randomly at these places either a multiple of 1, 2, or 3 of the number of sections in the space station.


Watching the space station go together was one of the coolest parts of the game, so I dressed it up a little with some animation and a sort of staggered build. Each game begins this way. Theoretically, it should give you an overview of the entire space station, so when you’re navigating inside of it, you already have an idea of what’s around you. In practice, it’s still completely disorienting. Smiley

[img width=700https://dl.dropboxusercontent.com/s/5iprpqm9m6te79b/GravBoots%20Space%20Station%20Creation3.gif[/img]
« Last Edit: October 04, 2016, 11:14:10 AM by Columbus007 » Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #12 on: July 05, 2016, 10:37:14 AM »

GravBoots was the subject of a Let's Play! Cool!




Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #13 on: August 09, 2016, 04:20:37 AM »

Just a note here that I do intend to get back to work on this soon - my next steps are:

  • Refactoring "gravity" to be a truly physics based system. Right now, I'm doing a lot of faking movement. This is with the goal of dealing with the very glitchy movement at corners and around ports.
  • Work on solutions for enemy movement. I would like the enemies to be able to move logically around the environment, which means that that I need to introduce nav-meshes in my weird 3d space. Anyone have any solutions for this. btw?
Logged


GravBoots - A ZeroG FPS: DevLog | Demo
io3 creations
Level 10
*****



View Profile WWW
« Reply #14 on: August 16, 2016, 10:10:23 AM »

Work on solutions for enemy movement. I would like the enemies to be able to move logically around the environment, which means that that I need to introduce nav-meshes in my weird 3d space. Anyone have any solutions for this. btw?
Looks interesting. Smiley

I've done some 2d path finding and am looking into 3d now.  As a first guess, since your code is generating the module locations, you could use that to start generating a "main" navmesh.  That navmesh could be used to help AI to move from module to module.  Then, as a guess, if you need other navmeshes inside the modules (e.g. both for path and cover checking), it might be enough to have separate navmeshes for that purpose instead of adding those module navmeshes to the "main" navmesh.  If you want AI to move mainly on the surface of the modules then the navmesh could be considered a 2d type mesh that wraps around the inside of a cylinder.  If you would want to fancier moves where the AI could also move along the diagonal of the module then you could connections to the navmesh.

As an optimization, would it be enough if the gravity checking rays would only be applied in the direction of movement?  For example, if the character is moving forward, then is it necessary to check what's behind it?   Or are there some situations where that approach wouldn't be able to detect the "best" surface?
Logged

Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #15 on: September 15, 2016, 07:23:22 AM »

Looks interesting. Smiley

Thanks. Smiley

As a first guess, since your code is generating the module locations, you could use that to start generating a "main" navmesh.  That navmesh could be used to help AI to move from module to module.  Then, as a guess, if you need other navmeshes inside the modules (e.g. both for path and cover checking), it might be enough to have separate navmeshes for that purpose instead of adding those module navmeshes to the "main" navmesh.  If you want AI to move mainly on the surface of the modules then the navmesh could be considered a 2d type mesh that wraps around the inside of a cylinder.  If you would want to fancier moves where the AI could also move along the diagonal of the module then you could connections to the navmesh.

I'm going to have to ask some questions about this... The only experience I have with NavMeshes are the automatically generated stuff in Unity.

As an optimization, would it be enough if the gravity checking rays would only be applied in the direction of movement?  For example, if the character is moving forward, then is it necessary to check what's behind it?   Or are there some situations where that approach wouldn't be able to detect the "best" surface?

Good idea.



So I haven't been putting any time on this during the summer. Life changes a little in the Fall, and I'll have some more time to put toward GravBoots. My first game dev task, however, is to add a dump truck to a construction game I'm making for my 3 year old son.



Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #16 on: September 25, 2016, 05:43:06 PM »

I decided to make (for now) the code and project management stuff open source:

Open Source stuff

GitHub: https://github.com/markwpearce/GravBoots
Trello: https://trello.com/b/Zb2uVdOU/gravboots
Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Columbus007
Level 0
**

Creator - GravBoots


View Profile
« Reply #17 on: October 06, 2016, 09:13:19 AM »

Dev Log 4 - Unintended Floating and Stable Movement

So I’ve started working on the project again (in my free time, which turns out to be about an hour a week). I want to be a little more pro-active and diligent about what I’m working on and goals for this game, so I started a Trello board (https://trello.com/b/Zb2uVdOU/gravboots) and got the project into a git repo, so I can do proper branches and merges without worrying about losing or messing up code.

So my first task getting back into development of GravBoots was to fix the feeling of first person movement. There were three goals I wanted to accomplish:
  • 1. no wobble or noise when standing still
  • 2. jumping across station structures should limit disorientation as much as possible
  • 3. walking or running to a port should automatically funnel you into it, without being disorienting

Number 1 (no rotation noise when still) was actually fairly easy to solve. In my player controller code, there’s a function that handles first person camera rotation and it needs to accomplish two things - logically match the current “forward” direction of the player and also handle mouselook. I narrowed the rotation noise down to the fact that I was doing spherical linear interpolation between the current rotation and the target rotation, based on time elapsed (in Unity, Quaternion.Slerp). This achieved a nice manageable rotation speed, but it also never fully reached equilibrium, because the camera moves, but so does the player’s body, and there’s a feedback loop.

I changed the code so instead of doing a Slerp, I do a bounded rotation (Quaternion.RotationTowards). This solves the noise issue (as long as my bound is high enough). It takes away the “gentleness” of the Slerp, though, and I do like the gentle rotation at slow player speeds, as it really sells the idea of floating in space. I’ve tried to mitigate this with a rotation bound that increases as the player’s speed increases, but I’m not entirely happy with it yet.

Number 2 (jumping should be less disorienting) was actually pretty easy to solve. In the code that rotates the player’s view, I made the rotation based on how much gravity the player feels. This means that if a player jumps up and needs to do a complete 180 degree turn, as the player starts feeling the gravity of what was the ceiling, the initial rotation is quite gentle, and you can easily telegraph how you’re moving and where you’ll end up.



I actually started with number 3, (running to a port should funnel you in) because that was the most difficult for the player in terms of actually moving around the environment.

Here’s what was happening before I fixed it. When the player is running toward a port or connection between space station sections, they should be thinking “I’m going to stick to the floor, so even if the floor changes orientation, I will follow that orientation.”




However, if they ran too fast, their momentum would make them continue in a straight line, and they would lose contact with the ground.



Because the force of “gravity” (actually magnetism) is inversely proportional to the distance away, the player would not be sucked back to the ground, but could easily run so fast they would just float.



As the player moved, they would get closer to the other side of the hole. It was quite common to run right over these ports that allow travel to other sections of the space station.



Because this happened rather quickly (at full sprint, in about 4 frames), and because the player wasn’t expecting this to happen, you’d get fairly disoriented, and not know exactly where they were.

I realized that I could play with the physics a bit to make what the player expected to happen actually happen. When you’re running, you don’t expect to be floating in the air. You only really expect to be in the air when you jump. So I decided to reduce player velocity/momentum when they find themselves floating but didn’t jump to do it.



Because they have reduced velocity, gravity pulls them in much easier.




And they can continue running, without floating, and with just a momentary decrease in speed.




If they did intend to hop over the port, a well timed jump still lets them float over it.


« Last Edit: October 07, 2016, 04:28:38 AM by Columbus007 » Logged


GravBoots - A ZeroG FPS: DevLog | Demo
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic