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

Login with username, password and session length

 
Advanced search

1318840 Posts in 59249 Topics- by 50341 Members - Latest Member: TheFrayWorkshop

October 20, 2017, 11:44:12 am

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogs♜ Kingdom ♜
Pages: 1 [2] 3 4 ... 7
Print
Author Topic: ♜ Kingdom ♜  (Read 39479 times)
chriswearly
Level 3
***


prince slugcat


View Profile Email
« Reply #20 on: December 17, 2014, 10:59:55 am »

Well I just played the original. Day X.
Well, the FIRST time I played, on Night 1 I went right and got killed by a zombie. But me actually trying got pretty far Smiley

So, can't wait for this sequel!

Also, looooove the art! So cinematic, actually :D
Logged

Taber
Level 0
**



View Profile
« Reply #21 on: December 20, 2014, 04:47:47 pm »

Great stuff guys, I like seeing your progress. Original game was fun too!
Logged

Alike Studio
Level 0
**


Game Developers of Love You to Bits


View Profile WWW Email
« Reply #22 on: December 23, 2014, 05:12:16 am »

I've been playing the original game and it's really fun! The new graphics look awesome, I love the waterfall animation and the water reflection Smiley
Logged

noio
Level 1
*



View Profile WWW
« Reply #23 on: January 23, 2015, 09:06:04 am »

Stuck with a little problem!

http://gamedev.stackexchange.com/questions/92737/discard-transparent-pixels-in-z-buffer
Logged


Check out twitter @noionl for regular updates
dhontecillas
Level 0
***


View Profile
« Reply #24 on: January 23, 2015, 02:40:57 pm »

I don't actually know anything about Unity3D, but looking at your shader code, it looks like it doesn't have a fragment shader. You are using a vertex shader, and a surface shader (that it looks to me that is something like a post processing pass).
If it is so, you should write a fragment shader where you can discard the fragment, or depending on the alfa valua set the depth to the maximum value.

Found something like this:


            struct C2E2f_Output {
                float4 col:COLOR;
                float dep:DEPTH;
            };     
           
            C2E2f_Output frag( v2f i ) {
           
                C2E2f_Output o;
                half4 c = frac( i.uv );
                o.col=c; // this is not iteresting
                o.dep=0; // this is what I want to output into Z-buffer (0 value is just an example)
                return o;
            }
Logged
noio
Level 1
*



View Profile WWW
« Reply #25 on: January 23, 2015, 02:48:21 pm »

Thank you!

A surface shader (that it looks to me that is something like a post processing pass).

The surface shader is Unity's magical mysterious equivalent of (everything including) a fragment shader. It is evaluated per pixel and it is (I think) compiled to a frag shader plus some other junk.

I didn't know it was possible to set depth values explicitly! However, that still wouldn't solve my problem: I don't want to "overwrite" the existing depth value (even with 0), I want to leave the depth value alone for certain pixels (the ones that are transparent on sprite).

Actually, everywhere I read it says that AlphaTest should prevent anything from being written to either frame or depth buffer. That's exactly what I want. I am thinking now that perhaps my code works, but one of Unity's magical mysterious lighting passes is still writing to the depth buffer.
Logged


Check out twitter @noionl for regular updates
noio
Level 1
*



View Profile WWW
« Reply #26 on: January 30, 2015, 08:40:52 am »

Long explainy type post time!

WATER

So, spent a few days fixing up the shader that we use for water, and I get asked regularly how it works, so I'll try to explain in some detail.

Applying Displacement Maps
The fundamental step of the water rendering consists of fetching part of the screen[1], flipping it upside down, then running it through a Displacement Map/Filter. I took that path because it was a built-in operation in Flash. A displacement map works as follows:

When rendering a pixel at (x,y), instead of grabbing from the texture at texture(x,y), we grab from the texture at an offset: texture(x + ox, y + oy) . These offsets are looked up from a special displacement texture, o = displacement(x,y). The displacements are stored in the red and green channel of this displacement texture. In my shader, that looks as follows:

half2 displacement1 = tex2D( _Displacement1Tex, i.uv.xy );
float2 adjusted = i.uv.xy + (displacement1.rg - .5);
half4 output = tex2D(_MainTex, adjusted);


So far so good, Also, have a look at this great explanation by Emanuele Feronato.

[1]: Note: in Unity, "fetching a part of the screen" requires rendering the entire game to a texture first (a Pro feature). We were doing that anyway in order to get pixel-perfect upscaling.

Generating the Displacement Map
You might wonder: how to generate the texture used for displacement? The Flash game generated a Perlin noise bitmap on the fly. But to improve performance, I am now generating a normal map using Fluid Noise Generator. A normal map stores normal vectors based on a heightmap, it's not quite the same as displacement, but close enough. This is the normal map that I use:



In order to make the water look dynamic, I simply scroll the heightmap (by modifying the texture offset in Unity). Without any extra refinements, the result would look a little like the following: (tweaking the scroll speed and displacement values will actually make it look acceptable).



You might notice some "unrealistic" factors:
  • The water doesn't really look like a horizontal surface because there is no perspective correction of the waves.
  • It is easy to spot that a texture is being linearly scrolled.
  • The reflection is as bright as the scene
So, let's fix some of these!

Perspective Correction
I want the waves "closer to the camera" to look bigger. So I simply stretched the uv lookup based on the x-coordinate:

half2 perspectiveCorrection = half2(2.0f * (0.5 - i.uv.x) * i.uv.y, 0.0f);
half2 displacement1 = tex2D( _Displacement1Tex, i.uv.xy + perspectiveCorrection ).rg;


Unfortunately this operation has to go in the fragment shader instead of the vertex shader, because the uv interpolation is affine. (Yes, graphics cards actually do perspective correct texturing, but only if your shape is actually in perspective, and not a camera-facing quad. This is a typical situation where faking 3D in 2D gets messy).



The result is as follows, when rendering the displacement map itself. (I see now that it is wrong since the lines aren't straight! Have to look into that..)



Texture Scrolling
On to point two! Let's make the water look a little more chaotic. Generating Perlin noise on the fly would still be an option, but I found another workaround. You might have guessed it from the fact that all my code mentions "displacement1": I simply use multiple displacement maps overlaid. I generated another normal map that has a higher level of detail, and for each pixel I add the offsets together. Additionally, I scroll the displacement maps at different speeds.



Current Status
Then I added some ambient multiplier based on the waves and I did some math magic to get nicely "rolling" sparkles. Now I'm afraid it looks too "hi-fi" for a pixelart game.



Happy to answer any questions!
Logged


Check out twitter @noionl for regular updates
Canned Turkey
Professional Otter
Level 10
*****


Always The Devil's Advocate


View Profile WWW Email
« Reply #27 on: January 30, 2015, 10:57:39 am »

This water might just be the best water in a 2D game I've seen.
I just love it.
Showed my brother, he agrees.
Logged

and
Level 6
*



View Profile WWW Email
« Reply #28 on: January 30, 2015, 12:35:13 pm »

I honestly can't believe how awesome that looks! Makes me think I need to learn some shaders  WTF
Logged

Mable & The Wood was funded on Kickstarter and is coming to Steam in 2017!
eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #29 on: January 30, 2015, 12:43:52 pm »

FTW :D
Logged

MOONMAN devlog WWW FORUM
happymonster
Level 10
*****



View Profile WWW
« Reply #30 on: January 30, 2015, 01:25:28 pm »

That is some amazing water..  Shocked
Logged
Kyzrati
Level 7
**



View Profile WWW Email
« Reply #31 on: January 30, 2015, 06:32:13 pm »

Just wow Kiss
Logged

Cogmind - Sci-fi Roguelike (devblog) | [email protected] - The X-COM RL | REXPaint - ASCII art editor
Olsen
Level 1
*


somervillegame.com


View Profile WWW
« Reply #32 on: January 30, 2015, 06:35:27 pm »

Played the demo.  Really nice atmosphere and mechanics.  The tired horse had me screaming at times.  Got super addicted before I was caught out at work.
Logged

oldblood
Level 9
****


Hanging around...


View Profile Email
« Reply #33 on: January 30, 2015, 07:14:58 pm »

Backed this KS and so glad to see this game is still around. Looking amazing.
Logged

dhontecillas
Level 0
***


View Profile
« Reply #34 on: January 31, 2015, 11:53:50 am »

Great post!

Have you timed how big is the win for having the normal map pre-rendered in a texture? I thought that texture fetches in a shaders were more expensive that the actual math operations.

 


Logged
noio
Level 1
*



View Profile WWW
« Reply #35 on: March 01, 2015, 07:27:13 am »

Great post!

Have you timed how big is the win for having the normal map pre-rendered in a texture? I thought that texture fetches in a shaders were more expensive that the actual math operations.

I haven't! I always thought texture lookups were kind of cheap (I guess I equated lines of code to performance Durr...?) ! These are favorable conditions though: very small textures with lookups of neighboring fragments accessing neighboring texels.
Logged


Check out twitter @noionl for regular updates
alvarop
Level 8
***


ignorant


View Profile WWW
« Reply #36 on: March 01, 2015, 10:50:32 am »

Wow, I'm late to the game but the water looks amazing. Gives it a very unique touch too.
Logged

i make games that can only ever be played once on http://throwaway.fun
NinthPower
Level 2
**



View Profile WWW Email
« Reply #37 on: March 01, 2015, 07:34:34 pm »

I'm thursty. also happy this is still a thing. Somehow missed it for awhile Smiley
Logged

Currently developing SCRIPT KIDDIES, \\\"It\\\'s...like Tapper but for nerds.\\\" - Kurt Indovina - IGM Magazine
lagdog
Level 0
**



View Profile Email
« Reply #38 on: March 02, 2015, 04:21:06 am »

found the original pretty fun, tho a bit frustrating dealing with the ai at times
looking forward to seeing where this goes : 0
Logged

noio
Level 1
*



View Profile WWW
« Reply #39 on: March 06, 2015, 12:01:03 pm »

Dev Report #2 Crumbling Ruins

The objective: For an intro sequence of the game that foreshadows the theme, we want the player to encounter big, stone-built letters spelling out KINGDOM that crumble as the player passes, leaving only inrecognizable ruins. There are many options for realizing this, such as frame-by-frame animation or using the physics engine. These kinds of problems that ask for a hybrid of engine This post attempts to explain the problems and method that we ended up using, with many pictures of course!

1) Proof of Concept

Before investing a lot of work into anything elaborate, we tried the most naive method to see if we're headed in the right direction. The movie below shows the letters animating independently, sliding out of view or toppling, covered up by simple particles.



This is obviously very crude, but it does show that even basic particles can cover up a cheap animation. Also, the letters themselves need a lot of work.

2) The Dead End

The animation above is nice but we want the letters to actually crumble. My first thought went to somehow slicing the letters dynamically, in real-time. Subdividing the collider polygons would be doable, but I would have to somehow subdivide the sprites and map the texture correctly to the fragments. Unfortunately this is a bit of magic that is abstracted away under the SpriteRenderer. I would need the original texture coords (the pink polygon) to compute the sliced coords (the green line).



After some searching I found the Sprite Slicer plugin. I also found the source code online somewhere, and had a look at the method that Sprite Slicer uses to create new objects that map to parts of a sprite. Through there I found that it is possible to get the mapping of a sprite in the atlas, but:

Quote
Sprite.textureRect: Get the rectangle this sprite uses on its texture. Raises an exception if this sprite is tightly packed in an atlas.

And we definitely do (and need to) pack our sprites tightly into the atlas! So it seems there is no way to recover the coordinates of the sprite on the atlas. Dead end.

EDIT: It seems I overlooked Sprite.triangles. Was this property exposed before Unity 5? It's great though! That would allow dynamic slicing of packed sprites.

3) Work is Unavoidable

Okay. If the dynamic code-driven route is unavailable, it's time to do some actual work: let's make each fragment a sprite of its own. Then we'll figure out how to animate them later. The first problem I encountered was this. Even if I can draw the cracks, it still is a PITA to extract fragments into separate images or layers. And I would have to repeate that process every time I changed a single pixel.


Cracks drawn in pink over the title

So! I dug up my old Python and Numpy and I wrote a script that would split the sprite automatically based on Connected Components. I like this because it still feels like I'm avoiding actual labor! Wink



Each sprite is saved on a transparent background that is the size of the original sprite, this makes aligning them all inside of Unity easy!

4) Physics

When simply dumping all the sprites into Unity and adding a PolygonCollider2D, Unity adds colliders that are roughly the shape of the sprite. However, this will not do at all since those colliders will overlap, causing the fragments to 'explode' as soon as physics simulation starts.



So I wrote a little script that draws Gizmo lines for all colliders in a group even while editing one of them, so that I can precisely align the polygons.



Finally, I don't want all the fragments to crumble simultaneously, so I added an Animation that controls the "isKinematic" property of each fragment. This was kind of a hassle to do right since it's not a real animation. The physics simulation has to run for the pieces to move, so it is impossible to preview in the editor and it is impossible to rewind.



The Result

And there you go: crumbling letters. It took manual cutting and sequencing, but with a little help from the physics engine. It needs particles and more grime and vines and whatnot, but I'm very pleased with the results, we might use the same technique for other destroyed buildings too!

« Last Edit: March 20, 2015, 05:20:45 am by noio » Logged


Check out twitter @noionl for regular updates
Pages: 1 [2] 3 4 ... 7
Print
Jump to:  

Theme orange-lt created by panic