next »

[SebastianGioseffi]

It keeps getting better and better! Go Negspace!

[TheWing]

#58: The shredder

Here´s a singular design problem:

I want to add a "killer wall".

1-Regular Negspace walls are black, usually solid-black, but they can have patterns too. Ships can bounce and hit them quite hard and stay prefectly healthy, in fact, grinding walls is encouraged.

2-Friction chargers are like walls, but solid white, and as soon as a ship touches them, they turn into the ship´s color. Ships can be any color. Grinding chargers is especially encouraged.

The killer walls, then, had to be neither solid black, nor white, nor colored with any color... weird!

3-Grinding a friction charger at high speed makes charging more effective and produces lightning, therefore, lightning is "a good thing". So... using lightning, at least in the same color as the player, is not allowed either.

What have other games been using as killer walls?
Traditionally, spikes. Having 8 pixels for tile makes it hard to convey the idea of "sharp spikes", since 1px wide looks thick already. Also, spikes in space, seriously?

After quite a bit of iterations and head-scratching, here´s what I came up with:

Why?
-1 All the other "safe" walls are static, therefore an animated pattern ought to at least catch the player´s curiosity, making them expect something particular out of that wall.
-2 Small lighting in a random color helps with catching the player´s eye, while being a random color each time conveys that it´s not necessarily "safe" as the lighthning from the charger (which is always the same color as your ship).

How?
Having lots of animated tiled teeths would be cumbersome, therefore, I coded a shader that procedurally generates the pattern in the GPU, allowing for kilometer-wide shredders with a single static quad, allocating for as many individual teeths as needed.

TL;DR?
Whenever you end up playing Negspace, this pattern will make you sweat

Loving it to pieces already

[pnch]

Thanks a lot!

#59: Gravity assist

Using the tech shown on the first pages of this devlog, maps are extremely quick and easy to setup. However, I try to add them only in order to debug / playtest features. Why? I´m sure any map done before locking the feature-set is liable to be discarded (Of the 5 deathmatch maps I´ve done, two are currently not available in the exhibition builds: one resulted too big for first time players that don´t yet know how to use the radar, the other, too difficult to navigate).

The other day, playing Negspace with friends, we quickly looped through the available deathmatch maps three times in a row. I figured it was time to add more, even if just for the sake of having a good time with friends (hey, what´s more important than that?).

A new deathmatch level was added. On the other hand, I HAVE new features to test:

Remember the centrifuge level? I was communicating the new mechanic by reaching to instintive knowledge: with every background spinning at high speed, the players instantly understood that "gravity" went outward from the center of such spin. There are toys for kids in almost every park working with that principle.

What if I want to add more complex "patterns of gravity"?

A ship on a stable-ish orbit around magnet C, no button is being pressed.

The previous update added the magnets shader, a distinct effect which makes players able to visualize the pull from magnets in the environment (yes, I switched back to rev2 shader, loving the concentric circles better).
Since the pull can now be visualized, players can mentally plot and anticipate trajectories counting on said pull to slingshot and orbit themselves around - as in every classic "2d planetary gravity" game - and actually as ships actually do in space (google gravity assist).

Maneuvering through orbits and debris

In the games that traditionally use this mechanic, planets are clearly visible and there´s not usually too much else going on visually. In Negspace, the pull from magnets is just one more factor to have in mind when piloting, among lots of other factors encoded in a highly visual way. That´s why being able to show that using a distinct effect was particularly important.
Also, now that I have the shredder, careful navigation became even more important, and the accumulation of debris that happens during a match forces you to adjust quickly to a changing environment:

Wrong calculation + debris + the shredder

[pnch]

Quick reminder for fellow gamedevs: Take info from the web with a grain of salt!

This quick experiment:

proved that sprite rotation doesn´t break batching (I´m getting the exact same number of draw calls than in the previous gifs).
A while ago I read somewhere that they DID break it, and systems were developed with this wrong assumption in mind, now there´s plenty of possible optimizations to do... Getting back to that!

[pnch]

#60: Marching tiles revengeance

Added support for automatic tile rotation, but ended up going WAY overboard with the possible optimizations:

I now have the seeds of a sweet alternative interactive mesher!

It´s built on top of all the previous "marching tiles" tech and tutorials shown previously (expanded set of cases, linear interpolation, automatic polygon reduction,etc).

Notice the "auto stitching" feature, preventing the generation of single colliders with a huge number of vertices (Unity throws tantrums at these sometimes). In the following GIF I´m highlighting four collider batches that are seamed together.

Improved the fill algorithm used to detect separated chunks, allowing for previously unsupported 1 tile wide corridors (not really, but each wall of the corridor had to be at different layers) and other previously problematic shapes.
The tileset was completely black, so have in mind the black shapes are still being built with 8px wide tiles.

It´s still hackish, and has yet to support 90º angles and decorations, but I believe the hardest part is over. Hopefully I´ll stop dreaming about debugging grid arrays 

[TheWing]

 

[Scifa]

I've been following this for a while, and was wondering if you wouldn't mind elaborating on your shadow casting a little more.

[pnch]

Hey Scifa, not at all! Here´s the previous paragraph about the subject, which I´ll do my best to elaborate on:

I solved it by first doing the standard "raycast a bunch of rays around the player", and then offsetting the contact points by a small multiple of the distance to the player, in a direction opposite to it (this is what creates the feeling of an upward perspective). Also, I setted a minimum distance from the player, effectively creating a soft rounding when the player is near a wall.

Keep in mind some vector maths kung fu is needed to follow (each time I mention a point, mentally replace with vector).
-Throw a ray from the center of the ship upwards, and get the first collision vectpr.
-If the collision vector´s length is smaller than a pre set threshold, scale it up to that threshold.
-Scale it by a constant amount to your liking.
-Rotate the original ray as many times as you want until you have traced collisions all around the player (you´ll get a ring of  unconnected points)

And some procedural-mesh-building fu are needed for the 2nd part, creating the fan of triangles:
-Create an empty mesh
-For each collision vector, create two points on that mesh, one at the collision vector, and another by adding a pre set length to the first collision vector (the points along the internal and external rim of the mesh in the quoted picture, normally the external points would be outside of the camera range).
-build alternated triangles by connecting together the points in series of 3 (careful with the normal direction).
-Update the points position at every update.

If you followed, you can just put this new mesh on top of the level and enjoy!
Otherwise, let me know of any specific question you may have.

[pnch]

#61: Destructible walls!

What if I were to control the previous update´s tech with in-game elements?
Say hello to destructible walls!

Yet to make it visually appealing and readable, let´s see where that takes us!

[Connor]

this looks like that telespace game, or whatever it was called. ill see if i can find it.

[pnch]

You mean Teleglitch, amazing game and a big inspiration source, among many others! It´s been previously mentioned in the devlog

[Connor]

yeah, totally

[Scifa]

Hey Scifa, not at all! Here´s the previous paragraph about the subject, which I´ll do my best to elaborate on:

I solved it by first doing the standard "raycast a bunch of rays around the player", and then offsetting the contact points by a small multiple of the distance to the player, in a direction opposite to it (this is what creates the feeling of an upward perspective). Also, I setted a minimum distance from the player, effectively creating a soft rounding when the player is near a wall.

Keep in mind some vector maths kung fu is needed to follow (each time I mention a point, mentally replace with vector).
-Throw a ray from the center of the ship upwards, and get the first collision vectpr.
-If the collision vector´s length is smaller than a pre set threshold, scale it up to that threshold.
-Scale it by a constant amount to your liking.
-Rotate the original ray as many times as you want until you have traced collisions all around the player (you´ll get a ring of  unconnected points)

And some procedural-mesh-building fu are needed for the 2nd part, creating the fan of triangles:
-Create an empty mesh
-For each collision vector, create two points on that mesh, one at the collision vector, and another by adding a pre set length to the first collision vector (the points along the internal and external rim of the mesh in the quoted picture, normally the external points would be outside of the camera range).
-build alternated triangles by connecting together the points in series of 3 (careful with the normal direction).
-Update the points position at every update.

If you followed, you can just put this new mesh on top of the level and enjoy!
Otherwise, let me know of any specific question you may have.

I went a slight different route myself instead of extruding from the hit.point out I rendered the mesh to a texture and the put that texture onto a plane using a custom multiply shader.

I don't want to hijack your dev blog thread by going into to much detail but I'll will post a more detailed update later.

Thanks again for the help, really appreciate it.

[pnch]

@Scifa: You´re welcome! Nice twist, that would allow you to do smooth edges.

Random beautiful bug alert:

[pnch]

#62: Destructible walls II

Started working in the visual aspect of destructive walls. Having 8x8 tiles means that in order to get at least a slightly organic shape, I´d have to randomize the tiles quite a bit.

Each color represents a different set of tiles. Each tile is chosen at random from all of the different sets at creation.
(Color is there just for debugging purposes)

[TheWing]

Seeing debug stuff is always cool, and I'd happily see more.. just to see how other people debug and so on!

Will those tilesets then be of different states of destruction, or will they just be "different from each other"?

[pnch]

#63: Destructible walls III

Going with just "different from each other". It´s just a visual cue to note which walls could be destroyed.
I considered different states of destruction (it would be trivial to add at this stage), but discarded it since I believe it will just make gameplay less predictable. For now, blasting walls is already hard and chaotic enough.

What do you think?

PS: I plugged the random environment generation to the test scene, each gif will come in a different flavor

[TheWing]

#63: Destructible walls III

Going with just "different from each other". It´s just a visual cue to note which walls could be destroyed.
I considered different states of destruction (it would be trivial to add at this stage), but discarded it since I believe it will just make gameplay less predictable. For now, blasting walls is already hard and chaotic enough.

What do you think?

PS: I plugged the random environment generation to the test scene, each gif will come in a different flavor

Looking really solid, there's surely no need for the tiles to display destruction.. the holes in the walls do just fine

[pnch]

@TheWing: Thank you for your feedback!

WOOT, managed an early integration of physics into the latest tech as well, add to that a simple bit of procedural generation logic and....

#64: Breakable asteroids!

Super happy with that, since it was was I originally planned to achieve when I started with the interactive mesher.
There´s still stuff to do (updating the mass of the asteroids as they change in area, separating into different chunks when they are split), but it´s a nice breakthrough!

EDIT: The environment shown in the gif wasn´t hand tuned, it´s a direct output from the procgen palette generator, super happy with that as well!

[pnch]

#65

Getting closer to fully-featured asteroids, you can now split them into different chunks, and toss the chunks around.
Each chunk now calculates its area, derives its mass, and builds its own colliders on detachment.

The supercharged beam is there just for debug purposes (don´t count on seeing it in-game, at least not on that tiny ship ).

Yet to fix the swapping of tiles on the chunks detaching, should be a trivial fix...