#unity tutorial

[gamecodelibrary]

One of the easiest ways to add combat into your top down games!

This video shows both melee and ranged combat implementation in a quick, clean and easy way!

Check it out :-)

[alek-the-not-so-great]

A Projectile Motion story

Question: How do you speed up/slow down a physical object traversing an already defined trajectory without changing the trajectory?

Short answer: You adequately change the gravity of the object as well.

For the unnecessarily long, nerdy answer continue reading.

/nerd talk start

Not the most scientific of definitions but the classical projectile motion concept is when a physical object is traveling in a parabolic motion due to gravity. The trajectory of the object depends on the initial velocity (speed), angle (aim) and gravity (gravity). (Also height but irrelevant to my case).

So the projectile system in our game is pretty simple: take those three parameters, draw a trajectory, and fire a projectile with those same parameters. It will most certainly follow the trajectory (unless, you like, hit it with a baseball midair or something)

But I caught myself wanting to speed up the projectile because it was moving too slow. Well, it was moving just as much as it should be given its velocity and gravity, but it still felt sluggish. The instinctive thing to do is increase the initial velocity, but then you change the trajectory since the projectile will inevitably travel further.

So I looked up the formula for projectile motion trajectory. As you can see gravity and velocity have an inverse relationship. In other words, whenever I increase/decrease the initial velocity for my projectile all I have to do is proportionately increase/decrease its gravity.

This way the equation balances out and the final value of the trajectory is the same. And voila, I can change the projectile speed but keep the theoretical trajectory the projectile WOULD have traversed if I hadn't changed the speed. (I swear I didn't just speed up the video)

And here I've slowed down the projectile for some possible Matrix shenanigans

So now we can have the same intuitive trajectory but also more flexibility with the projectile speed. Pretty neat, right? No? A little maybe?

/nerd talk end

[dfilitto]

Aprenda a construir e publicar seu primeiro jogo de adivinhaçao na Unity

O post Aprenda a construir e publicar seu primeiro jogo de adivinhaçao na Unity ensina como voce pode construir e publicar o seu primeiro jogo de adivinhaçao utilizando a Unity Aprenda a construir e publicar seu primeiro jogo de adivinhaçao na Unity Quem nos ensina a criar esse super game e o nosso querido fundador Danilo Filitto do canal DFILITTO Super dicas Se inscreva em nosso canal e…

[ectoimp]

Low Polys your Mystery

[evilmafuyu666]

talk shit about garten of banban all you want but this fucked up bird has had more of an impact on me than the entire poppy playtime franchise

[blaithnne]

If I may, how do you typically approach choosing colors in your art? It always has just a lovely feel to it, so I was a bit curious; don't feel pressured to answer ofc :]

I’ve been using a lot of gradient maps lately, they work by switching the greys in your piece with a corresponding colour according to its value. Basically, I colour in black and white, grab a gradient map, and then I adjust the colours by hand until I’m happy with it. This isn’t the only kind of colouring I do, but it works great if you’re in a rush or you’re struggling to find a good starting point for your colours. I’ve been operating under a time crunch for these Sketchbook Week drawings and the Plenism promo stuff I made, so for all except one I used gradient maps. I’m actually in a bit of a funk with my colours right now soooo I’ll come back and do a proper colouring tutorial for my style once I’m happier with how my non gradient mapped colours are looking !

[tshortik]

doodling some fake screenshots and thinking some thoughts. ideas. concepts, if you will. based on a fictional game setting i made years ago for my bachelor that i don't want to give up on just yet.

[its-voxid]

Part 6 of my lowpoly avatar tutorial series is now up on my patreon!! In this episode I cover importing a fbx file into unity and setting it up for streaming. https://www.patreon.com/voxid

[ctommy-chileno]

My experience in impulse buying game development software has given me great knowledge

[weaponizedmoth]

My OC, Uni-T.

[ghostbunnygames]

Playtest Early Playtest Often 🎮

I created a short build of my game for friends and family to check out and see what they think about the game.

This wasn't easy to do emotionally!

I couldn't help but think of all the problems my game still has, or the rough edges that I am sure would annoy people. It felt to raw to really show people... But I did it anyway.

Here is why

I found out that a number of players were confused by the numbers placed over the towns. This number indicates how many passengers on your train want to go to a certain location. It was obvious to me, the person who designed and coded it. But not to others. If I continued on and waited to test my game, this information could have been lost and lead to further player confusion. But early playtesting nipped it in the bud.

Now I know I need to make this information more clear and change how it is displayed. Then in the next update not only will the game be more fun, and less buggy. It will also be more intuitive and understandable, thanks to my playtesters.

[gamecodelibrary]

Another quick 2min video!

This one will show you how to get started with a top down game and add top down movement to your player!

Check it out if you're interested in game dev :-)

[wilderlingdev]

honestly my biggest hurdle when it comes to gamedev nowadays is sticking to a single engine. i know bits and pieces of godot, unity, renpy, twine and even godsforsaken unreal, but do i know enough to make good stuff in any of them? no

[dfilitto]

Aprenda a como criar texturas e materiais na Unity

Aprenda a como criar texturas e materiais na Unity

O post Aprenda a como criar texturas e materiais na Unity ensina como voce pode começar a criar suas texturas e materiais na Unity Aprenda a como criar texturas e materiais na Unity Quem nos ensina esse super tutorial e o nosso querido fundador Danilo Filitto do canal DFILITTO Super dicas Se inscreva em nosso canal e compartilhe as matérias que gostar com os seus colegas. Participe dos…

[devsgames]

Billboarded 2.5D Sprites In Unity (With Shadows!)

I'm a big fan of billboarded sprites because not only does my brain operate better when thinking in 2D, but I think billboarded sprites in general look really cool.

In this tutorial I'm going to walk through my process for setting up billboarded sprites in Unity to cast shadows as well as receive lighting from the world around them, and in future tutorials I'm going to outline how I rigged them and animate them to move! It's really simple once you know how to do it and I think adds a lot of visual interest to any simple 2D sprite.

Let's dive in!

How to make 2D Billboarded Sprites (With Shadows!)

There's a few important elements I like my billboarded sprites to have in order to help them feel more grounded in the world:

They need to face the player at all times ("billboarding")

They need to cast shadows on the world

They need to receive light from the world on themselves

Lets go through my set up for each of these:

1) They need to face the player at all times

To do this I attach a simple script on the sprite that looks at the main camera. Here's a pastebin of the C# script! This is the simplest part of the process as basically all it does is find the object named "Player" and then make the sprite face that direction at all times.

There's a line of logic preventing them from rotating on the Y dimension so they don't face you directly when standing above them, but of course this can be modified depending on your needs.

Easy peasy and (in my experience) works for most cases!

2) They need to cast shadows on the world

Shadowcasting for Unity's 2D sprites is possible built-in, but turned off and hidden by default (presumably since it's not officially supported and I assume not desired for most uses of 2D sprites). To access it you need to enable 'debug' mode on the gameobject itself and find the hidden "Cast Shadows" parameter.

I use "Two-sided" so the sprite shadow is cast from behind them as well as in front, but your setting will depend on your needs and context.

Once this has been enabled your sprite should be casting a shadow on the world - neat! We're like, 80% of the way there.

Now for the final element:

3) They need to receive light on themselves appropriately

Here's an example of a character facing away from a light source as well as facing it to show what I mean. Notice how when facing the light source the sprite looks a lot brighter, and she's darker when facing away from it thanks to the lack of lighting. This is the effect we're going for as it helps the sprite stand out more than something with more static presence!

AFAIK surface lighting for sprites aren't supported built-in to Unity, but there's a PixelLit Unity 2D Sprite shader I use to achieve this that empowers this behaviour (https://github.com/traggett/UnitySpriteShaders/tree/master/SpriteShaders).

All it requires is adding the PixelLit shader to your project, creating a material from it and assigning your sprite onto the material. You'll need to play with the values on the material to find what looks best for you as it will depend on your setup and needs.

Conclusion

You should now have a sprite that receives world lighting and also casts shadows onto surfaces! Even just billboarding this way makes for a great-looking style and can really add a lot to the look of a simple sprite (and saves the headache of having to work with 3D characters hehehe)

In the next devlog/tutorial thing I'll walk through Unity's sprite skinning tools and how to rig meshes for animation. Will link it to this post when that's done! :)

[milkshakebattlecat]

I dislike using rigidbodies to move my objects because physics interactions can sometimes go ham and while that can be very amusing, I prefer things to be predictable. So for moving arrows in this game I handled the movement math myself via coroutine. Let's take a look-see, shall we? :3

The goal of this coroutine is to move its symbol object in an arcing motion from its initial position, moving it upward and to either the right or left. Then it will fall downward. Rather than having each symbol object run this coroutine from an attached script, I am using a central script (my GameManager) to apply this movement to a given object, so the first thing I do is make sure the symbol still exists before proceeding with the coroutine:

If we find that our symbol has been destroyed, we exit the coroutine with "yield break". You wouldn't need this check if the script is running this movement on its own object, as coroutines are ended upon an object's destruction.

There are a bunch of variables we'll define within our coroutine to calculate our desired motion; we'll start by defining an arcDuration:

This determines how long the object will take to move in the arc shape. A shorter duration results in faster movement. Using a random amount between a min and max duration creates some variance in how fast different symbol objects will move. I have my minArcDuration set to 1 and maxArcDuration set to 2.5 for quick bouncy movements.

These variables referencing the outermost bounds of the camera's view will be used to ensure that symbols remain within the visible area of the camera at all times. I'm not using a topBound because I'm fine with symbols possibly going off the top of the screen, but I use a maxArcHeight variable that is set low enough that they never do.

For even more spawn variability, we add a little randomness to our starting point. My spawnPointVariance is set very low at 0.3; my initial symbol spawn position is low on the screen, and due to how the rest of this coroutine works, it's important that the symbols are never allowed to spawn below the bottomBound or else they will be instantly deleted (and result in a miss!)

The height here is, of course, how far up the symbol will travel, and the distance refers to how far it will move to the left or right. We calculate the peak of the arc by adding our distance and height to the x and y values of our starting position. Randomizing between negative and positive distance values for our x position adds another layer of variability which includes the possibility of moving either left or right, even though our minArcDistance and maxArcDistance are both set to positive values for clarity (mine are set to 1 and 6).

This is the part of the code that decides upon our symbol's speed by calculating the distance it has to cover from its start to its peak. By dividing our horizontalDistance by our arcDuration (distance divided by time), we calculate how fast the symbol needs to move to cover the entire distance in the given duration. Mathf.Abs is used to ensure that horizontalDistance is always positive, lest we get a negative value that causes us to move in the opposite of the intended direction.

We'll also want a speed variable for when the arcing motion ends and the symbol starts falling, that's where downwardSpeed comes in. In earlier versions of this function, I used downwardSpeed alone to transform the object's position, but I've since refined the logic to take the current horizontalSpeed into account for more consistent motion; we'll see that later. (Also you can see I've been tweaking that arbitrary range a bit... the fall speed was brutal during those mass waves ;o;)

Here we create an elapsedTime variable starting at 0. In our while loop, we will use this variable to count how much time has passed, and if it becomes greater than or equal to arcDuration, we'll change isFalling to true and begin moving down.

We create a Vector3 moveDirection which gives the vector pointing from the startPosition to the peakPosition, and then turn it into Vector3 horizontalDirection, which retains only the X-axis direction. Both values are normalized to ensure consistency. Without normalization, the magnitude (or distance) of the vector would vary depending on the distance between the start and peak positions, which could result in inconsistent speed. Normalization caps the magnitude at 1, meaning the vector represents just the direction, not the distance, allowing for consistent speed calculation later.

Here's how we start our while loop: as long as our symbol object is not null and the game says we canMove, we say yield return null, which will instruct our loop to occur every frame. If either the symbol becomes null or canMove becomes false, the while loop will end and so will the coroutine - for this reason, I only set canMove false when the game ends and the symbols will never have to resume movement, rather than in cases where I want them to pause movement and resume later, such as when a player pauses the game or during level-up periods. For the latter I use an isLevelingUp bool in my while loop that waits until that bool is false before proceeding (yield return new WaitUntil(() => !isLevelingUp)), and for the former I actually change the game Time.timeScale to 0, which is not typically recommend but fuck it we doin it live, because I don't have a mechanism for resuming this function with appropriate variables if it is stopped. It could surely be done if you just store the local variables somehow.

This is the first part of our movement logic that we put in the while loop; remember we already set isFalling false, so this part will proceed with the rising motion.

We count our elapsedTime here by adding Time.deltaTime, a variable which represents the time in seconds that has passed since the last frame, ensuring that time calculation is frame-rate independent. Do NOT use Time.time in cases like this unless you want your users with varying computer specs to all have different experiences with your game for some insane, villainous reason

The variable 't' is looking at the elapsedTime divided by arcDuration, a ratio that tells us how far along we are in the arc movement. If elapsedTime equals arcDuration, this ratio would be 1, meaning the arc is complete. We use Mathf.Clamp01 to clamp this value between 0 and 1, ensuring that it won't ever go higher than 1, so that we can use it to calculate our desired arcPosition and be sure it never exceeds a certain point due to frame lag or some such. If 't' is allowed to exceed 1, the arcPos calculation could possibly go beyond the intended peakPos. We are going for predictable motion, so this is no good

We define our Vector3 arcPos with Vector3.Lerp, short for "Linear Interpolation", a function for calculating smooth transition between two points overtime. Ours takes our startPos and peakPos and moves our symbol between the two values according to the value of 't' which is incrementing every frame with Time.deltaTime. As 't' progresses from 0 to 1, Vector3.Lerp interpolates linearly between startPos and peakPos, so when 't' is 0, arcPos is exactly at startPos. When 't' is 1, arcPos reaches peakPos. For values of 't' between 0 and 1, arcPos is smoothly positioned between these two points. Very useful function, I be lerping for days

Then we alter the y coordinate of our arcPos by adding a calculation meant to create smooth, curved arc shape on the y axis, giving our object its rounded, bouncy trajectory. Without this calculation, you'll see your symbols rising and falling sharply without any of that rounded motion. This uses some functions I am not as familiar with and an explanation of the math involved is beyond my potato brain, but here's a chatgpt explanation of how it works:

Mathf.Sin(t * Mathf.PI): This calculates a sinusoidal wave based on the value of t. Mathf.PI represents half of a full circle in radians (180 degrees), creating a smooth curve. At t = 0, Mathf.Sin(0 * Mathf.PI) is 0, so there’s no vertical displacement. At t = 0.5, Mathf.Sin(0.5 * Mathf.PI) is 1, reaching the maximum vertical displacement (the peak height of the arc). At t = 1, Mathf.Sin(1 * Mathf.PI) returns to 0, completing the arc with no vertical displacement. This scales the vertical displacement to ensure the arc reaches the desired height. If height is 10, then at the peak, the symbol moves 10 units up.

With those positions calculated, we can calculate the "newX" variable which represents where we want our symbol to appear along the x axis. It adds the horizontal movement to the current x coordinate, adjusted for the time passed since the last frame.

We use Mathf.Clamp to ensure our newX value doesn't exceed either the left or right bounds of the screen. This function limits the given value to be between min and max value.

Finally we tell our loop to actually reposition the symbol object by creating a new Vector3 out of newX, arcPos.y, and using our symbol's own z coordinate. That last bit is important to ensure your sprite visibility/hierarchy doesn't go out of whack! If I used arcPos.z there instead, for example, it's likely my sprites would no longer be visible to my camera. The z position the symbol spawned at is the z position I want it to retain. Your needs may vary.

This part tells us our arcDuration should end, so we set isFalling to true, which will cause the secondary logic in our while loop to trigger:

Previously, objects retained their x position and only had negative downwardSpeed applied to their y position, but I didn't like that behaviour as it looked a little wonky (symbols would reach their arc peak and then suddenly stop and drop in a straight line downward).

By creating a new Vector3 fallDirection that retains the horizontalDirection and horizontalSpeed from the arc phase, we're able to apply smooth downward motion to the symbol that continues to the left or right.

Just below that, we once again clamp the symbol's x position to the left and right screen bounds so the symbols can't travel offscreen:

The loop would continue causing the symbols to fall forever if we didn't have this check:

which triggers some project specific logic and destroys the symbol, then exits the coroutine with "yield break". Although the coroutine already exits when the symbol becomes null, which it will see is the case in the next frame as we destroyed the symbol here, adding an explicit yield break is an added layer of security to ensure predictability. Once again, not super necessary if you decide to run this code from the moving object itself, but just be sure you move your Destroy() request to the bottom of any logic in that case, as nothing after that point would be able to trigger if you destroy the object which is running the coroutine!

and that's all folks. If this helps you make something, show me!

HEY, did you really make it all the way to the end of this post?! ilu :3 Do let me know if this kind of gratuitous code breakdown interests you and I will summon motivation to make more such posts. I personally like to see how the sausage is made so I hoped someone might find it neat. If ya got any questions I am happy to try and answer, the ol' inbox is always open.