Posts Tagged ‘blog’

[NO SPOILERS] Fun with shaders for LD37, part 2!

Posted by (twitter: @avaskoog)
Saturday, December 17th, 2016 9:45 am

Hey! Posted earlier about some of the custom shaders that were written for our LD37 entry, LOCK AND RELOAD. c:

Since the posts easily get a bit lengthy, I decided to divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. This is part two, about one of two shaders that make use of separate cameras and render textures!

(ノ◕ヮ◕)ノ*:・゚✧

Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.

Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.


 

Inventory inspection

This one is not a spoiler! c:

When picking something up, or clicking something on the inventory bar that was picked up earlier, the player will see a 3D view of the item in question along with some descriptive text.

View post on imgur.com

This view is rendered by a separate camera than the main one to get a nice 3D render of the spinning artefact. The main camera that renders the room (still visible behind the UI) cannot see this model, and the camera that renders the inventory view cannot see anything except the inventory item.

Separate camera setup

This is achieved in Unity by setting inventory items to a render layer of their own, and then unchecking that layer from the main camera, while unchecking everything except that layer on the inventory camera.

ld37_shd_insp_cams

Then you’re free to render your inventory and your game world in the same place, without them actually interfering with each other, like so:

ld37_shd_inv_scene_game

Render texture

Next, we need to create a texture for the inventory camera to render what it sees onto, since we don’t want it to render into the main game view and replace what the main camera sees. A render texture can be added by right-clicking somewhere in Unity’s file inspector and finding the option in the create menu.

It then needs to be connected to the camera, but we’ll not be using the field in the inspector for this, as it won’t work as intended. Instead we’ll be creating a small script that sets the camera up with the texture as the game starts. Something like this at the top:

[SerializeField] private Camera m_cam;
[SerializeField] private RenderTexture m_tex;

This way we’ll be able to drag and drop the camera and the render texture onto our script. Then as the game starts we’ll call this:

m_cam.targetTexture = m_tex;

Simple as that! Finally we’ll need to draw the texture somewhere so that we can see it. We’ll do this by adding a “raw image” to our UI canvas which will take the render texture as its sprite/texture, and that’s it. Now during runtime the UI will show what the inventory camera sees in that image, and we can edit the UI element as usual to get it to appear where we want it!

Remember we can also adjust the resolution of the render texture by opening it up in the inspector, in case the default 256×256 is too small, or has the wrong proportions.

The shader

You may have noticed we haven’t actually done any shader work yet! ヽ(゚Д゚)ノ

We can see there is a white border around the inventory item’s model, and also a circle behind it. But of course that’s not automatic. Without any shader, the inventory would now look like so:

ld37_shd_cabl_0

Not very fanciful, nor stylised. And potentially difficult to see, depending on the background! And of course this game’s UI has a dark overlay, so we want that white border around the model to make it stand out nicely no matter what’s below!

Border shaders can be tricky or not depending on the circumstances. In our case we’ve got a mostly transparent image with some non-transparent pixels in the middle; namely, those that make up the model. This makes it simple: we look for pixels that are transparent but have an adjacent non-transparent pixel at a particular distance from it (which will determine the thickness of the border), in which case we make those pixels as opaque as we wish and then assign the border colour to them! (◕‿◕✿)

Remember that we get the colour of the pixel/fragment at any given position in the texture by sampling a UV coördinate. To get the currently processed pixel, we just use the unmodified x and y that we got from the vertex shader:

fixed4 col = tex2D(_MainTex, i.uv);

To for the alpha value of any pixel around this one, we need to offset the UV coördinate by as much as it takes to move on to the next pixel. We’ll start simple, by only sampling the nearest pixels above, below, to the left and to the right of the current pixel. This gives us a less smooth border, but is easier to keep track of.

UV’s are normalised between 0.0 and 1.0, so to get the size of a pixel at this scale, we will need to divide 1.0 by the width and height of the texture’s resolution (in pixels). If we want our border to be thicker than one pixel, we can multiply the result by some value.

fixed2 one = fixed2(1.0 / width, 1.0 / height) * thickness;

Now we can get the alpha values around the current pixel by sampling the surrounding UV’s and only storing the alpha value and ignoring the RGB components.

fixed left = tex2D(_MainTex, i.uv - fixed2(one, 0.0)).a;
fixed right = tex2D(_MainTex, i.uv + fixed2(one, 0.0)).a;
fixed up = tex2D(_MainTex, i.uv - fixed2(0.0, one)).a;
fixed down = tex2D(_MainTex, i.uv + fixed2(0.0, one)).a;

The case may well be that up actually means positive values rather than negative depending on your coördinate system, but it makes absolutely no difference to the end result of this effect, so we need not worry about it. ᕕ( ᐛ )ᕗ

Now we can accumulate alpha values by adding all of these together, then clamping the result to 1.0 and do some more maths to finish up, which will be explained below the complete line of code.

fixed border = min(1.0, left + right + up + down) - col.a;
col.rgba += border * transparency;

Finally we subtract the alpha value of the original pixel that we are currently processing.

  • If all surrounding pixels as well as the original pixel are transparent, the end result will also be transparent, and we’ll either get no border at all, or a semi-transparent border pixel, which will give a nice and smooth result so long as the original model was also rendered with anti-aliasing.
  • If the original pixel was not transparent, the border value will be reduced (all the way to 0.0 if the original pixel was completely opaque; otherwise a semi-transparent value) and the original colour will overtake the border, since there will be nothing to add when we finally add the border value to all of the channels (RGBA) of the final colour.

We can also multiply the value we add by some factor below 1.0 to only apply a semi-transparent border. Et voilà!

ld37_shd_cabl_1

This border actually also samples pixels diagonally from the original pixel to make it even smoother. Note that this doubles the number of texture lookups, which can be slow, so choose carefully whether to add this extra overhead depending on the needs of your own application.

As you can see we still haven’t added that circle, but this post is getting lengthy, and you can get an idea of how to render a circle all in shader from the previous post. It’s one of the easiest things one can do, actually! Or you could just add a circle image to your UI below the UI image with the render texture if you’re not feeling up to it!

 

That’s it for this part! In the next one (and I won’t be posting it right away as I don’t want to be spammy), we’ll be talking about some UV scrolling shaders (one of which is a spoiler) before we move on to the second effect in the game that required extra cameras and render textures, which will be a SPOILER, so play the game first! c:

Remain at the edge of your seat! ☆

[NO SPOILERS] Fun with shaders for LD37, part 1!

Posted by (twitter: @avaskoog)
Friday, December 16th, 2016 2:34 pm

Hey! They’re not all too advanced, but I still thought I’d share a little something on the custom shaders that were written for our LD37 entry, LOCK AND RELOAD. c:

Since the posts easily get a bit lengthy, I’ll divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. We’ll start with the main shader that gives the game its look and feel!

(ノ◕ヮ◕)ノ*:・゚✧

Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.

Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.


 

Post effect filter

This one won’t spoil a thing as it is the very first thing to see upon starting the game: the wonky colour effects and checkerboard overlay. There’s also a dark vignette as well as some increased contrast.

View post on imgur.com

This effect applies to the whole final rendered image rather than individual objects and is therefore done in one step at the end of each frame, simply applying the shader to each pixel, or fragment.

Let’s go! ᕕ( ᐛ )ᕗ

The low-fi colour effect

This is achieved by first multiplying the colour values (which are all normalised between 0.0 and 1.0) by some factor, then rounding the numbers so that any resulting decimals disappear, and then dividing the values back down again by the original factor. This effectively decreases the colour variation. The smaller the factor, the greater the effect.

col.rgb *= factor;
col.rgb = round(col.rgb);
col.rgb /= factor;

ld37_shd_couleur

Contrast

The contrast effect is fundamentally not so complicated. It can be done in different ways, but for this particular game what I found worked best was to subtract some of the intensity of the colour if the original colour was below some tolerance value, but multiply it by some factor if it were above it.

col.rgb += (col.rgb < tolerance) ? 0.5 : 1.5;

ld37_shd_contr

Checkerboard

Alternating dark and bright squares are all over the screen. This isn’t some texture; just a little bit of maths. By checking the position of each pixel on the screen and figuring out whether it’s even using the modulo operator (which gives the remainder of a division), we can figure out whether the number is evenly divisible by two and thereby whether it’s odd or even.

If we multiply the coördinates by some factor to pretend that the screen is smaller or bigger than it really is, we can control how big the squares get. We apply the effect by darkening odd squares and leaving even ones untouched or vice versa.

col.rgb -= ((floor(x * s) % 2.0) - (floor(y * s) % 2.0)) * darkness;

ld37_shd_chekrs

Vignette

In this case, a vignette is a darkening of the corners of the screen. We’re basically applying darkness to the whole screen except an oval in the middle, leaving the corners dark but the middle unaffected. Circles are easy. We can achieve an oval by pretending that our rectangular canvas is in fact square.

fixed ratio = height / width;
fixed2 middle = fixed2(0.5 * ratio, 0.5);

We can then check the distance from the center to the current fragment, adjusted for the rectangle’s ratio, to get its position inside a circle, which will appear as an oval thanks to the ratio.

fixed2 pos = fixed2(x * ratio, y);
fixed factor = length(pos - middle);
col.rgb -= factor * darkness;

ld37_shd_vign1

You will probably want to adjust some values by multiplying them by various factors to make your vignette look the way you want.

That’s it for this part! In the next one (and I won’t be posting it right away as I don’t want to be spammy), we’ll be talking about the first of the two effects in the game that required extra cameras and render textures!

Stay tooned! ☆

Im In once again! &

Posted by
Thursday, December 4th, 2014 9:29 pm

I’m officially in! Unfortunately my friend won’t be joining this time around, but hey there’s always next time. Anyhow I think it will still be a great experience! Can’t wait, so excited to see the all the creative minds at work for these upcoming three consecutive days.

As for the software I’m planning to use is
Unity 3D
Photoshop
BFXR sound effects

On the side note!
I’ve started a new little guide to games development on my blog.. The content will be about the fundamentals of games development and later planning to talk about more in depth algorithms and programming techniques that I’ve learnt over the years in games development.  Check it out

http://claumpark.wordpress.com/

I’ll also be updating my ludum dare progress on here!
Anyhow I shall see you ludumdarians on the flip side, take care!

Post Compo Update!

Posted by
Monday, August 25th, 2014 11:23 am

So i decided to contiue creation of my game and created this blog to let everyone who will be interested in what stage game after some minor or major improvement/changes.

Link: BerailTumblr

And First Improvement Logo of my game what do You think about it ? Answer me here or on my blog :)

OfficeMazeLogo1

In for Ludumdare 30!

Posted by (twitter: @strong99)
Wednesday, August 20th, 2014 2:05 am

This will be my fourth year of Ludum Dare and the seventh time I compete. I’m going to write a live blog like I always did which can be found here.

This time I have to put a bit more effort in music rather than graphics 😉 I learned my lesson.

This time I’ll be using InCourse® GameCreator again. A webbased game engine developed by Islandworks and dubbed ‘the GameCreator’. It’s a webbased game engine with an easy and no-coding editor. I’ll be using the Ludum Dare promo code for more statistics. I’m excited!

OS of choice: Windows 8.1

Game engine of choice: InCourse 3.2 – the Gamecreator

Graphics: Photoshop or Illustrator

Audio: Audicity & Anvil.

Hardware: Wacom cintiq (Pen tablet), Space Explorer (3d Mouse), M5 mouse, dual monitors etc.

I’ll post a “How did I do it” on the end as I did the last times.

Other year’s entries include but are not limited to: World AloneBe the Villain and The Dragon Journey.

Strong99's Ludumdare 22 entry - World alone Strong99's Ludumdare 25 entry

Strong99's Mini Ludumdare 49 entry Strong99's Ludumdare 28 entry

And a lot more! Visit my live blog during the event!

 

Good luck fellow Ludum darers!

Tumbling Towers: My Final Entry – Recap & What’s Next

Posted by (twitter: @nick_mudry)
Sunday, December 15th, 2013 3:28 pm

The last two days have been crazy. It’s been a while since I’ve worked on a game, and I was nervous about jumping into a game jam while my skills aren’t up to par, but I am extremely proud of myself and what I built.

What did I build? 

Well, I built a game called Tumbling Towers. I’ve come to call it a reverse Tetris/Jenga style game where you receive a random block and you must build up and try to not knock the tower down. The goal of the game is to build as high as you can and score as many points as you can.

Where the theme “You Only Have One” came into play is where you can only build with one of the three materials in the game, and you can only build in one direction (up); (yes, for some reason I instinctively ended my sentence with a semi colon there… the two days of heavy coding must’ve drilled that into my head much, much more.)

Sounds cool, where can I play it? 

There’s a web version hosted on my web server, here. It has links to download the desktop versions. Those links are also on the game page here on the Ludum Dare website.

Who Helped?

It wasn’t just me who worked on the game, I got some late assistance from a good friend of mine, who did some of the art last night. (Just the building blocks). Also, I used a friend’s music he made for the game.

What’s next? 

I’m not really sure. I really want to continue the project and make it more clean, pretty, polished, etc. and maybe release it on iOS/Android. A few of my friends have been playing it pretty often and have been enjoying the builds I was sending them, and I think it can be a pretty fun game to play on tablets. It needs some optimization for them, but it can be done. :)

When I decide to jump into doing that has yet to be decided, but maybe early January once I’m done with my One Game a Month project for this month.

If anything, I might use this as a base for a Physics based puzzle game I had an idea for a few weeks ago. It could go hand in-hand with it.

What did I learn?

This is something I want to write down to allow myself to reflect on my skills and learn how to improve next time I work on a game.

Art – Art isn’t my strong suit. I should have found an artist at the beginning. The artist I worked with mid-way through only had enough time to do work for a small bit of the game.

Scope – I applied a rule I made for myself long ago, which was to keep it simple and not go out of scope. For once, I followed the idea of just creating a simple mechanic and working from there. For game jams, this works wonderfully well. Definitely something I’ll consider again next time.

Testers – This was the first time I actively put out builds during a game jam. Twitter friends as well as my personal friends were more than willing to test out the game in it’s early phases, which helped me discover a bug that wasn’t showing on any of my 3 computers. Test early, and test often!

Programming – Holy crap, I programmed this entire thing?! I still don’t believe it. I know C# and Unity, and have made things before, but never completed anything. I consider what I did a completed product, even though it has it’s obvious flaws. This has boosted my morale and while I know I can’t take on a super crazy, out of scope project just yet, I do know I can create simplistic games in Unity 3D.

Unity’s 2D is Really Easy – Oh yeah, Unity has a really easy 2D system. I thought it’d be a bit challenging, but it works extremely well and is easy to pick up. Definitely using Unity’s 2D development tools from now on.

Until next time…

Well, that’s all. Thank you Ludum Dare, and the Ludum Dare community. I made some good friends during this jam that I didn’t expect to make. It’s been fun chatting in the chat rooms, checking out everyone’s live stream, and tweeting with you all while I took breaks and relaxed. I can’t wait for the next one and am happy I finally have a completed project for the Ludum Dare/Jam. :)

Time for me to shameless plug myself: 

If you’d like, please follow me on Twitter. My handel is @AngryFacing.
You can also check out my website, http://mudry.me, which I’ll be updating with game development blogs, and so forth. If you want, you can also check out some of my shipped games and other projects.

Thanks again everyone and see you all next jam! :)

Oh, I recorded myself doing a lot of the development. If I can pull the videos from my Twitch stream, I’ll post a time lapse. :)

Ludumdare 28

Posted by (twitter: @strong99)
Wednesday, December 11th, 2013 4:44 am

This will be my third year of Ludum Dare and I’m going to keep a live blog which can be found here.

This year I’ll be using InCourse® GameCreator. It’s  a webbased game engine developed by Islandworks and dubbed ‘GameCreator’. It’s made in HTML5 and such, it will be quite different from my previous entries which were made in C++ and the 3d graphics engine Irrlicht. It’s going to be a challenge to make a game using only 2d art :)

OS of choice: Windows 8

Game engine of choice: InCourse 2.0 – Gamecreator

Graphics: Photoshop/Illustrator

Audio: Audicity & Anvil.

 

I’ll post a “How did I do it” on the end as I did the last times.

Other year’s entries were: World Alone and Be the Villain.

Worldalone - the lost bedroom The deathray

Have a great Ludum Dare everyone!

Quick tip: How to keep track of your posts

Posted by (twitter: @caranha)
Thursday, April 26th, 2012 10:04 pm

So you posted on someone’s else blog. How do you know if they replied to your post or not?

Very simple: use the search feature! In the control panel, go to “comments” and type your own username in the search box, and it will list all the comments that you made, plus comments from other people mentioning you. Then you can quickly go to posts that you’ve commented to check for replies.

This may be obvious for some people, but I didn’t know about it the first time around on LD22, and could never really keep track of replies to my comments in other people’s blogs.

As an extra, if you search for your username on the “posts” section, you can find out if people are talking about you/reviewing your game. Try it out too!

New development blog

Posted by
Saturday, April 7th, 2012 2:30 pm

Hopefully I will have the next ludum dare off if I do not that is okay I will participate next time in the mean time I will be working on my new game that I will be publishing 3 months from now. If you want to check it out visit my blog here simbstudio.tumblr.com or directly play the demo here http://dl.dropbox.com/u/70771337/WebPlayer.html This blog is to help me feel motivated to keep programming and having fun if you have any suggestions or useful tips or programs to use drop me a message or comment here or follow my on tumblr. I am posting this here because I know this is a great supportive community. I wish everyone luck in the next compo have fun guys :)

[cache: storing page]