Posts Tagged ‘unity’

Last weekend to play/rate BreakAround!

Posted by (twitter: @xanjos)
Friday, December 30th, 2016 4:19 pm

Click the gif to play!!

Well as the post title suggests, seeing as tomorrow is New Year’s Eve (which means some of you will probably be off partying somewhere) and there’s only 3 days left until voting ends, this is the last weekend to play and rate my entry BreakAround (For those of you with a Google Cardboard VR headset do give the postjam version I made a go as well).

I still have my little Google Form set up for anyone who would like to play/rate their entries as I’ll most likely be at home during the weekend (otherwise I’ll probably go through them all on Monday) and I might try doing a small rating livestream but to sign off, here’s a few clips of people playing my game.

Clip from a Twitch livestream (Click here for the full video)

 

Have a happy new year peeps! 😀

Thank you all and Happy New Year!

Posted by
Friday, December 30th, 2016 2:51 pm

I just want to thank everyone who played our game and left a valuable feedback. You guys are awesome!

I played a lot of interesting games during this LD. It was an epic journey. We got more than we expected. There is still some time left so let’s push this to the limits. You can try our game (find a link below). If you like it leave a comment so I can try your game too. Have Fun!

THANK YOU AND HAPPY NEW YEAR!

HourGlass Collector

Click here to learn how HourGlass Collector was made.

Click here to play HourGlass Collector

Cardboard Drift – WebGL Build

Posted by
Monday, December 26th, 2016 5:33 pm


Cardboard Drift

WebGL build is now available. Try it out.


Cardboard Drift WebGL

Added Linux Build!

Posted by
Monday, December 26th, 2016 9:08 am

“Ludum Dare: The Game” Post-Mortem!

Posted by (twitter: @ddrkirbyisq)
Thursday, December 22nd, 2016 4:14 pm

If you haven’t already, go play and rate my entry, Ludum Dare: The Game!

postmortemtitle
This time around I entered the compo division and decided to spend my 48-hour LD making a game about…making a game in 48 hours for LD. So meta! xD It’s lightly inspired by Game Dev Story, but certainly has its own unique spin on things.

postmortem1

I came up with a couple of other ideas for the “One Room” theme, including some sort of game where you need to tetris-pack furniture pieces into a gridded room, but the LD game seemed particularly exciting to me and I was already coming up with a bunch of ideas that I wanted to implement for it, so it was a no-brainer that I should run with it. It was a relatively obvious play on the theme — I mean, there I was in my room thinking “Hmm…if there’s only one room, what kind of room could it be? …oh, what about the one I’m literally in right now?“…but even so, I decided that I should just go with it and not overthink things too much.

Overall I’m really happy with how the game turned out! It’s a completely new style of game for me and is heavily UI-focused — you play the game using your mouse only, which I’ve never done for LD before! Getting to branch out and try something new was pretty fun, and although I definitely ran into some troubles and rough spots (more on that later), everything turned out alright in the end. I also managed to achieve my goals for this LD, which were pretty simple — to take care of myself, do a good job, and have fun!

As always, let’s take a look over what went well and what didn’t go as well.

 

What went well:

Game idea

The “LD game” game idea was one of the first main ones that I came up with and even before I had settled on it my mind was already buzzing with different interesting ideas that I wanted to incorporate. Sometimes you get a good idea and you just feel great about it! There are actually a ton of unused ideas that I would have loved to include but didn’t have time to implement, including:

– An entire “pre-compo” phase where you get to choose what to prioritize: purchasing supplies, getting rest, watching the keynote, making an I’m In post, writing starter code, etc.
– Having to select between multiple coding frameworks, e.g. Unity vs C++ SDL vs GameMaker, each with its own pros/cons
– A pet cat that you can feed, play with, and pet to improve your happiness
– Animations for each of the actions, like coding, making music, etc. that would change in intensity during high productivity (a la going Super Saiyan)
– Random events, like power outages, bluescreens, getting sick, kitchen fires, telemarketing calls, noisy leafblowers waking you up from sleep, etc.
– Option to “phone a friend” for help, either with debugging, remotivating yourself, playtesting, etc.
– Different “moods” for the character portrait (right now it’s always just the same smiling face)
– Very simple minigames that you play for the different actions instead of just waiting for time to pass. Different coding frameworks and game genres/design ideas could correlate with different minigames
– More choices for what to work on when designing/doing artwork/etc.
– More choices for what direction to take the game, e.g. focus on speed but sacrifice quality
– A “brainstorming” phase where you get random ideas and have to decide which one to stick with — affects starting points and other bonuses

As a result of me being so hyped about the game idea, I actually did a record-breaking amount of work on Friday night. Usually I spend Friday night purely on brainstorming as well as setting up a basic project and then going to bed, but this time around I kept chugging along until pretty late in the night doing artwork and implementing things. Here’s what I had at the end of Friday night already:

progress_1

While none of the actual gameplay is there, the basic room is already fully drawn, the dialogs are working, and all of the basic tech is in place! That’s pretty good for Friday night!

 

Unity (specifically, coroutines and UI implementation)

Holy cow, I would NOT have been able to pull off this game using my old Haxe toolchain. This was my first time using Unity for a solo compo entry, and it overperformed again! For this game I needed to create a whole bunch of different UI dialogs, complete with word-wrapping, 9-slice background images, etc. and doing all of that programatically would have been a legitimate nightmare — having to deal with a full compile cycle every time I wanted to tweak the positioning of a UI element would just take way too long. Thankfully the Unity 5 UI system worked out really nicely and I was able to just place everything using my visual editor. Whee!

Screenshot 2016-12-22 13.06.01

I also made =extensive= use of coroutines, which are basically a way for you to have a function yield and execute across multiple frames. A lot of the flows in my game were time-based, so it made much more sense to write something like:

// Displays a dialog box, then waits until it closes.
yield return DialogBox.Show("Starting a new atcion!");
// Start playing sounds, etc.
...
// Wait for 5 seconds until action completes.
yield return new WaitForSeconds(5.0f);
// Show results, then wait until results display is closed.
yield return ResultsBox.Show(
 "I finished!",
 new[] { string.Format("+{0} Art", art) },
 new[] { "icon_art" }
);
// Cleanup, stop playing sounds, etc.
...

There was a little bit of trickiness around making sure that there were no messy interactions between different flows (I used simple locks to guarantee that only one dialog sequence could be showing at a time), and making sure that you could interrupt a flow if you decided to start a different action (in that case, I needed to ensure that we still did the appropriate cleanup for the old action, stopped playing any action-related sounds, etc.).

postmortem2

One thing I did miss slightly was the ability to get return values from coroutines. I had a common case in my game where I needed to show some sort of selection UI, such as picking between two choices, or selecting a new action to do, and it would have been nice to write:

// Yield on a coroutine that returns an int value.
var myCoroutine = StartCoroutine<int>(ChoiceBox.Show("Which thing should I do?", "Do this thing", "Do that other thing"));
yield return myCoroutine.coroutine;
// Use the int value for something.
int selectedChoice = myCoroutine.returnValue;

While you can’t do this out-of-the-box with Unity, you can write your own coroutine extension methods that will allow you to achieve the same thing. There are several different proposed extensions, and I’ve actually used this particular one before to achieve exactly what I described above, but unfortunately I just didn’t have that tech set up and I couldn’t be bothered to re-implement it again during the compo. Instead I had a rather janky approach where I passed in an anonymous lambda method into the coroutine which it would invoke with the return value:

// Pass anonymous method to set selectedChoice to either 0 or 1.
int selectedChoice = -1;
yield return ChoiceBox.Show("What thing should I do?", "Do this thing", "Do that other thing", {val => selectedChoice = val; });
// Use the int value for something.
...

This is a bit uglier, but works just fine in practice.

 

Overall gameplay

While there are a bunch of things I’m not quite as happy with about the gameplay (more on that later) and a bunch of things that I didn’t have time to implement, the gameplay and content of the game turned out to be pretty fun overall despite its rough edges, and the feedback that I’ve received so far indicates that people are having a good time with it. I think the main thing is that it’s just FUN to think about trying to manage your time by doing these different things and seeing the results that happen. When you first start playing the game you don’t really know in advance what kinds of benefits or disadvantages each action has, but I think that’s sort of the fun itself in that you’re sort of exploring the different options available to you. This also gives the game a bit more replay value as when you play it a second time you’ve got a better handle on what needs to be done and what options are important.

I also learned my lesson from Grow Your Love (which was way too punishing with its grading) and ended up with a completion/grading scale that I think people will have an easier time with. It’s always hard to balance your own games because you’re always the foremost expert on them and as such have such a huge leg up on everybody else, but I came up with the “requirements” system that would serve as a rough difficulty adjuster, and then made it so that you could aim for a higher overall score on subsequent playthroughs.

postmortem7

In the beginning I had this hastily-thrown-together algorithm that would calculate your final overall score and just spit out a number with absolutely no explanation, and one of the features I decided to spend my last precious hours working on was the detailed scoring breakdown, along with revamping the scoring system itself. This was WELL worth it, as being transparent about how you’re actually graded means the player actually understands why they received the rating they did and allows them to know what to change during their next playthrough. Plus it’s just fun to be given a detailed report on your actions :). A lot of key changes like this happened during the later part of the compo and I’m really glad they made it in.

 

Artwork

While pretty much all of the artwork for the game was static (I had noooo time to put in fancy animations), I’m actually pretty happy with how the room came out, and had quite a bit of fun drawing it as well. This is probably the most intense pixeling I’ve done for LD (art is definitely my weakest area), and I’m happy with how the game came together stylistically. I used a few different references for the room graphics, including random pixel art rooms that I found via google, as well as Earthbound / Undertale graphics. The dialog box visuals also fit very well, as did the font that I chose.

 

Random names, comments, and the “refresh page” joke

One of the funnest parts of the entire creation process was developing the random game name generator, which can come up with hilarious titles such as “Tabla Hero”, “Retroidvania Maker”, and “Bullet Hell: Championship Edition”. The generator isn’t actually that complicated, as I didn’t have time to make anything fancy — it just selects from a random bank of prefixes and a random bank of suffixes and puts the two together.

Here are the prefix/suffix lists for the Rhythm Game genre, for example:

prefixes = new[] { "Bongo", "Tabla", "Dubstep", "Chiptune", "Bagpipe" };
suffixes = new[] { " Hero", " Band", " Karaoke", " Idol", " Raver" };

So you can have “Bongo Band”, “Dubstep Idol”, “Bagpipe Hero”, and so on and so forth.

The random theme selection is a little more simple, as I just put in a list of all of the themes from the theme voting rounds for LD37 and have it randomly pick one.

The randomized comments were also fun to make, and I think add a nice touch to the final scoring. All of the comments are pre-written, but the game selects different ones to give you based on your ratings in each of the categories. Also, you get more comments if you have a better community rating (mostly from posting to the LD blog).

progress_3

Finally, the “refresh page” theme announcement joke at the beginning of the game is something I just knew I wanted to have, as it’s (funnily enough) such a consistent and iconic part of LD. So that made it into the game pretty early on.

 

Posting animated GIFs

Lastly, this is a minor point, but I have to say that posting progress updates got a lot more fun now that I can capture animated GIFs and post those as well. I’m using ScreenToGif for this at the moment and it’s been working well!

 

What didn’t go as well:

Gameplay balancing

Thankfully, I managed to do an initial rework of the gameplay balance and tweaked a lot of the numbers during that pass. Some changes I made that got into the final game:

– In the beginning productivity affected the speed at which you completed actions! I changed that so that it instead affects the amount of “points” that you earn for each action.
– Point values used to be much lower. For example, a single coding action would get you between 2-3 points. I restructured all of the point values so that your overall ratings would be on a ~rough scale between 0 and 100 (though you can go higher of course), and I think that worked out better.
– As mentioned earlier, the overall rating system went through a big rework. It used to be much more nebulous and also penalized you very heavily for your weakest category by weighting it more heavily in the final average, to encourage you to diversify your efforts.
– A lot of minor tweaks to numbers, including the rate at which each “need” counter goes down.
– For most of the project’s lifecycle there were only the “standard” variants of actions — for example when you coded a new feature, it would always take 4 seconds and you’d get ~20 points (and sometimes a bug). Now, there’s a 25% chance that you get an “I’m stuck feature” that takes 6 seconds, for which you can chose “Read the Manual” or “Search StackOverflow”. One of these choices gives you ~20 points and the other gives you ~30 points, so depending on your choice you could actually be less efficient than normal. There’s also a 25% chance that you get a “long feature”, where you can choose to “Finish it ASAP”, or “Take your time”. Both result in ~40 points, but the “Finish it ASAP” option is 3 seconds faster at the expense of creating a random amount of bugs. There are similar variants for the other actions as well.

postmortem3

These changes did a lot to clean up the overall gameplay. However, even after all of these changes, the game could probably still use some rebalancing. Some issues off the top of my head:

– Having only two food options is pretty limiting, especially since both have their drawbacks (homecooked meal takes a long time, frozen pizza isn’t consistent in providing enough substance). That’s not the worst, as it creates and interesting decision, but I think more choices would have been better.
– Some of the actions are just not beneficial on average right now. I think that’s fine to some extent, but it should probably be a little closer.
– The relative timescales work out really weirdly, as microwaving a pizza takes 30+ minutes for some reason (!). This works out just fine in terms of gameplay, but makes no real-world sense.
– The medidate and bounce on bed actions aren’t too great in terms of their outcomes. They have a 50% chance of a negative/nothing effect and 50% chance of a positive effect, but the positive effect isn’t really enough to outweigh the cost.
– Browsing other people’s posts is pretty cost-inefficient as it gets you the same amount of motivation as posting to the blog, but gets you much less progress points.
– It’s a little too easy to meet the requirements of the harder genres. I DO think that it’s correct to allow people to be able to hit the MMORTSRPG requirements, and I think it’s better that I erred on the side of too easy rather than too hard, but right now it’s a bit =too= easy.
– I did a good job of raising dialogue notifications when your need levels fall below a certain point, but it can be jarring when two or three of these happen at the same time, especially if you’re in the middle of a task.

 

Gameplay format (?)

This one is a bit more nebulous, but at the end of Saturday I was really concerned about the direction that I had taken with the gameplay, as it didn’t really seem very interesting at all. You just chose the actions that corresponded to your requirements, consistently got points (remember, there were no variations yet), and did the corresponding “need” action whenever your need levels were low. There wasn’t a lot of strategy, nor was there a lot of real decision-making. More importantly, there just wasn’t much zany action going on!

In the end I managed to salvage things by at least adding some interesting choices such as the variants mentioned above (which I added for coding, art, music, and design), as well as adding some more “fun” actions such as bouncing on the bed and meditating. But I wonder if it would have been better to focus more on the “storytelling” aspect of the game rather than on the strategy / time-management aspect, especially given that the time-management aspect didn’t involve that many decisions (maybe it would be different if you had to play minigames for the different actions??).

postmortem4

So I wonder if it would have been a better call if I had come up with an experience that was a little more scripted instead. Something akin to a visual novel, perhaps, with randomized events pulled from a large set. Each choice you made would still affect your games’ stats, but instead of becoming a game about looking at numbers it would be more of an interesting story with zany things happening. You’d have less control as the player, but as the creator of the game I’d be able to ensure that you experienced many more different events. It would play out similar to a choose-your-own-adventure story, I guess. Again, I’m not entirely sure that would have worked out better and by the time I was considering this option seriously I decided that it was unfortunately too late to really make that design chance.

 

Minor Unity audio issues

This is a really small silly one that I already knew about, but still annoys me so I’m still writing it here.

The current build of Unity has an issue with WebGL builds such that the beginning part of every sound is cut off when played back. The result is that the start of each sound sounds a little different (noticeable especially for the kick drums in the intro sequence, and the text dialog sounds), and more importantly, seamless music looping doesn’t work because there’s a gap. I haven’t tried every possible compression type, but I DO know that making your build with an OSX machine instead of Unity on Windows does fix the issue. So it’s just a platform-specific bug with the Unity build process that hasn’t gotten fixed yet. Luckily I have an OSX laptop so I was able to replace the build after the fact, but this still annoys me. I’ll have to file a bug report for this at some point to make sure it gets fixed.

There was also a minor issue with a small pop/crackle effect that occurred at the end of sample playback, which was especially noticable with the text dialog sounds since I was playing so many of them each second (resulting in a buzzing noise when they all ended). Again, minor stupid things, but just annoying.

 

Overall this entry was a blast to make and I hope you guys enjoy it too!  I don’t have plans for a post-compo version, as I think I like the game enough as it stands.  But thanks for reading through my detailed post-mortem!

One last note: the soundtrack for the game is also available to download for free on my Bandcamp site at https://ddrkirbyisq.bandcamp.com/album/ludum-dare-the-game-original-soundtrack.  Go grab it now! 😀

 

BreakAround – LD37 Jam Entry

Posted by (twitter: @xanjos)
Monday, December 19th, 2016 5:31 pm

Well I was going to post this earlier (I’ve been busy this past week as well as being mostly lax about judging for some reason) but here’s my jam entry for Ludum Dare 37 (otherwise known as my “comeback” after failing LD36) which I like to describe (in my own personal opinion) as some horrible combination of Breakout with a 1st person 360 view. Desktop and web builds are available (Although for performance reasons the desktop version is recommended) and there’s also a version of the game on Android/Google Cardboard for those that like their VR.

breakaround

Click the gif to play

Anyway as usual I’ve put up a little Google Form which you can fill in if you would like me to come and play/rate your entries (I’m going be mostly busy for the next week as I’ll be working on important stuff for my main indie game project but I’ll try to go through each submission as soon as possible).

Interrogation Room

Posted by
Monday, December 19th, 2016 5:04 pm

Play and vote Interrogation Room!

ezgif.com-optimize

It was an awesome LD! Thank you all!

Swinging the axe – Attack Animation HowTo

Posted by (twitter: @gipzo_)
Monday, December 19th, 2016 9:29 am

Hello again,

I’m continuing postmortem posts about our game – Cure4Life.

And in this post I want to explain how we did axe attack animation.
Other weapons behave simpler as they don’t have any animation at all :)

title

(more…)

[SPOILERS] Fun with shaders for LD37, part 3!

Posted by (twitter: @avaskoog)
Sunday, December 18th, 2016 5:03 pm

Hey! Posted part 1 and part 2 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 three, about two shaders that make use of UV scrolling (sort of) and number two is a spoiler, so do play the game first! c;

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

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.


 

Animated TV noise

In the small room that the game takes place there is a television set, and at the start of the game you’ll find that the screen is turned on, but showing nothing but static. Moving static, of course, and not just a frozen image!

View post on imgur.com

So how does this work? We could of course have gone super fancy and generate noise programmatically right there in the shader, but since we were not looking to do anything procedural here, that was completely unnecessary, and we’re only using a static texture with the noise already in it. The movement comes from randomly jumping around (rather than scrolling) the UV coördinates! ᕕ( ᐛ )ᕗ

UV scrolling

What does it mean to “scroll UV’s”, or “move UV coördinates around”? Well, the UV’s are what determine where and how textures will map onto a mesh/model. By moving the x and y positions of the UV’s along the surface onto which a texture is being rendered, the position of the texture will move. There are many neat uses for this, so let’s look at a few before we move on, just to make sure you understand! (◕‿◕✿)

View post on imgur.com

A waterfall is easy to achieve by scrolling a repeating texture vertically along a simple rectangular plane. In this particular case, there are multiple layers of textures moving at different speeds on top of each other, as well as some particle systems to help sell the effect further.

This next GIF was recorded from this YT video from the channel ClassicGameJunkie and their show How did they do that?, so go check that cool channel out! Its creator is also working on the 3D platformer Clive ‘N’ Wrench!

View post on imgur.com

The flat, cartoony eyes in The Legend of Zelda: Twilight Princess are best animated by scrolling the UV’s of the texture around the flat geometry rather than trying to actually move any vertices.

The noise texture

I admit! The briefing on UV scrolling was a filler, to some extent, because there isn’t very much to say about it. It’s very easy, at least now that you know how the concept works! c:

When UV’s scroll enough that we’re able to see one repetition of the texture meet another, there are two ways to go about rendering it. It can either be repeated/tiled, or it can be clamped. You may have seen these option before when looking at a texture in Unity’s inspector. To make it clearer what’s going on, let’s look at the noise texture in both modes:

ld37_shd_rep_clm

As you can see, clamping means that the last pixel of each side of the texture will be repeated indefinitely in the corresponding direction, while repeating means, well, repeating. This is what we want, since we want to be able to move to random locations on the texture and still get the TV screen filled up nicely with static.

The noise shader

Finally! As you would know, perhaps from the previous part, the basic way of going about shaders is to run the program on each pixel, or fragment, of something to be rendered, and process the final colour and alpha to output for each. To get the colour from the currently processed pixel, we just use the UV coördinate in the texture that we got from the previous part of the shader, the vertex part. Like so:

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

What we can do now is to add some numbers to the UV’s—an offset—that will move to a different part in the texture. We want this to happen in a way that looks random, and we want erratic jumping, not smoothly sliding over to the next part in the texture.

The thing to do when one does want to move smoothly around a texture would be to move by a constantly increasing value, like the game’s time. This might alternatively be plugged into some function, like cosine or sine, to move around in wavy or circular fashions.

We won’t do exactly that, of course, but we still need the time variable to have the conditions keep changing. What we can do to get the jagged movements we want is to make use of the modulo operator to see if the current time is divisible by some number, and use that as the basis of our stuff. We’ll even use some wave functions!

Since the rounded number will remain divisible by something until it has changed into something else that no longer is divisible by that number, we’ll be seeing each position where the UV’s end up for at least a few frames, which is of course what we want. We want this to change over time, so we’ll modulo the time by the time itself, but multiply each operand by a different number.

float factor = (time * 10) % (time * 22);

Something like that! That determines how much we move. Now to determine how far and where to move! We’ll use cosine and sine for this, again plugging in the time, multiplied perhaps by something else (or even nothing at all—i.e. 1.0—this time). This will make it move around in circles, but of course we won’t be able to see that as we only skip around on those circles.

float2 movement = float2(cos(time), sin(time) * distance;

The distance variable ensures that we move about a fair distance on the texture, so that the difference between each position is clear. And honestly, we might as well plug in something like time % 100 in there as well to make the noise as varied as possible!

And so we modify our initial line of code:

fixed4 col = tex2D(_MainTex, i.uv + movement * factor);

That’s it! Incredibly cheap cheating for some fake randomness that looks good enough for something like this, where the texture is already very random to begin with. I only used a texture that’s big enough to precisely cover the screen, but in retrospect I’d say this works even better with a texture that’s much bigger than the TV screen, to make any repetitions less obvious!

 


 

!!!ヽ(゚Д゚)ノ NEXT UP IS A SPOILER, SO THE “READ MORE” TAG WILL NOW BE INSERTED! ヽ(゚Д゚)ノ !!!

Thus you may want to play the game before you move on! c;

 


 

(more…)

[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! ☆

Hi guys!!

My game “Fat Hero Adventures” (I began to develop it in the past #LD35) is already available on GooglePlay and AppStore.

ANDROID VERSION: https://play.google.com/store/apps/details?id=com.HisteriaGameDev.FatHeroAdventures

IOS VERSIONhttps://itunes.apple.com/us/app/fat-hero-adventures/id1184880424

Fat Hero Adventures
I hope you like it!! :)

Regards,
S.

Dethroned – Post-Jam, Post-Mortem

Posted by
Tuesday, December 13th, 2016 3:15 pm

Dethroned_title

So, I did say I’d write a post-mortem, since it was my first Ludum Dare ever, and actually the first game I’ve made that could be considered potentially finished. I definitely want to record my mistakes for future reference, and to just share my experiences and maybe see if someone possibly had similar problems.

I’ve really only made rather convoluted solutions to game mechanics than games themselves up to this point, and as such, the timeframe and workflow kinda caught me by surprise even though I thought I’d planned along it. So while I have some Unity mechanics and Editor tools under my belt, it dawned on me that I’m still a complete noob 😛 My biggest strength really was my experience with having to do stuff with short sleep cycles. And music production too, of course.

TL;DR: It was a mess, and I enjoyed it.

(more…)

Jam entry: LOCK AND RELOAD

Posted by (twitter: @avaskoog)
Tuesday, December 13th, 2016 1:41 pm

Click here to explore the room! (ノ◕ヮ◕)ノ*:・゚✧

View post on imgur.com

http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=6155

An entry made in 72 hours by Ava and Marte. You find yourself with a severe case of amnesia in a locked room and need to figure out what’s going on. The story isn’t quite what we intended it to be, nor as long, due to time constraints, but hopefully you’ll get something out of it anyway! It’s a concept, after all! And it has wacky shaders and creepy audio, so who can resist? ♥︎

Click this post to read more than the excerpt, for some post mortem information and pictures of the process! ☆

(more…)

Shadows

Posted by
Tuesday, December 13th, 2016 10:32 am

Shadows is an action platformer with mouse based controls.

You’re playing as a shadow mage and your objective is to kill everyone else in the room. You can switch between human and shadow form, jump on walls, fly around the map, and cast deadly spells that kill in one shot.

View post on imgur.com

Check out the game here.

Survive the Barbaric Vikings

Tuesday, December 13th, 2016 2:38 am

Our second Ludumdare but this time we had less time but still had fun!

Things we learned

  • Creating weapons that the AI and player use exactly the same way. Don’t have to change anything specific for the AI or player.
  • Animations in Unity. Our doors were animated in Unity because they have their own colliders that move
  • Complex animations with layers etc.

We couldn’t get in everything we wanted but its still enjoyable with its infinite wave generator!

HOW FAR CAN YOU GET!

screenshot1 screenshot2 screenshot3 screenshot4

Click here to play our game

 

[cache: storing page]