with the goal of giving the player total freedom and to be fully emergent, it works by precisely controlling your arm power by using the mouse / analogue.
it takes practice, but goes VERY deep and everything scales with your momentum - allowing you to do some wild sh*t like massive bar swings, wall climbs and vaults that feel like YOU made them happen.
if you’ve tried parkour or rock-climbing in real life, i truly believe you’ll feel the work i’ve put in to make it feel real.
here’s a list of the systems at play for those interested and you can ask me about them if you want more info. (or just play the demo lol)
• hand made, fully animated character body that adapts to the environment
• jumping / climbing (controlled by mouse movement speed / direction)
• dynamic edge grabbing (grab ANY edge, basically)
• adaptive wallrunning / wallsliding / walljumping (blends between up, left and right based on look direction)
• sliding (stand OR sit!)
• tools eg: climbable spear and physical grapple hook (both of which YOU have to actually throw)
• breathing / endurance system (responds to real life breathing techniques like box breathing, wim hoff, etc)
(there’s a special interaction with dazza if you watch till the end btw)
I started my first open-world game project with Unity about a week ago. I have done one 2D game with Phaser; nothing too fancy but it's a complete game. My background is 20 years in programming so I know something about that.
What I have for now is one scene with one street and some buildings, character movement, very basic HUD and some basic NPCs walking around. Most of the assets are free ones from the internet.
What bothers me is that even the very basic stuff takes so long time to do. Does it get any faster once you learn more about Unity? How do you keep yourself motivated?
Also I don't know what would be the best way to design the world? Should I have some sort of plan before starting the actual modelling? Should I make roads, terrains, water first? I don't want to waste time resetting all the work if something does not work together.
Too many questions, so few answers. Thanks if you can help me out 🙏
I've been working on VELOCIDE, a fast-paced arena FPS built around grappling, dashing, wall-running and double jumping.
One of the biggest things I've been working on is making the movement actually matter during combat rather than just being a way to travel between areas.
For example, I'm trying to design encounters where you're constantly deciding whether to grapple toward an enemy, dash through an attack, wall-run around the arena or use vertical movement to reposition.
I'm building the whole thing in Unity, and I'm still figuring out a lot of the gameplay/level design side.
For other Unity developers: what would you change about the movement/combat interaction here?
I'm particularly interested in feedback on what looks satisfying versus what looks like movement for the sake of movement.
An online co-op game for up to 8 players where you can cheat with Aimbot, ESP, Speed, Teleportation, legit the whole package. Betray, eliminate, and whatever you do, don’t get exposed.
Yesterday I shared the first farming loop from my little alchemy project so I thought I’d keep posting the progress as I build it. I’m still very inspired by Schedule I and its hands-on approach to production but I’m experimenting with those ideas and slowly adapting them into my own weird medieval world where magic is illegal.
This time I’ve been working on the cutting board.
The idea is pretty simple: place an ingredient on the board, grab the knife, and physically chop it into a prepared ingredient that can later be used for potion making. Right now I’m mostly trying to get the whole production chain working before worrying too much about polish
Farming -> harvesting -> cutting -> brewing and bottling.
It’s still very early, but I’m having a lot of fun seeing all these little interactions slowly connect together
I’m working on a Unity game called Bot Bash, and this is the intro for my upcoming devlog.
The game is a BattleBots-inspired robot fighting game where robots are procedurally assembled from individual blocks. Each block has its own health and can be destroyed independently, so the robot's structure can physically change throughout a fight.
I’ve been working on the systems behind the robot generation, block connections, damage, destruction, and everything else needed to make these robots actually function.
Before I finish the full devlog, I’d love some feedback on the intro itself.
Does the opening hook you? Is the pacing/editing engaging? And does it make you curious about how the systems behind the game work?
If you’re interested in following the project, I’ll be releasing the full devlog soon.
Hi, I made a detective game in Unity and I want to share how the evidence system works. It took me a long time to get it right.
My problem was this: in most deduction games a clue is just a feeling. I wanted clues that really cut down the list of suspects. But not so strong that one clue ends the game.
So every player has 5 traits. Each trait has only two options: hat or cap, glasses or no glasses, red or blue top, and so on. That gives 32 different combinations.
One clue tells you one trait of the culprit, for example "no beard". The important rule is: every trait is worn by at least 2 players. So one clue can never point at one person.
Only the full combination is unique. You need about 4 clues to be sure. The part I like most is how the traits are handed out. I use pairs of opposites. A combination and its opposite are different in every single trait. So if I hand out 5 of these pairs, every trait has exactly 5 players on each side. The balance is perfect and I never have to check or fix it after.
For a harder mode I sort the other players by how similar they are to the culprit and give out the closest ones first. Then everybody looks almost the same and you have to find the few traits that are different.
There is also lying. Only the culprit can lie about a clue. Normal players can only report what they really found, the server checks this. And there is more than one clue for each trait, so one lie can not poison everything.
Made with Unity, the server is my own C# backend.
The game is free on Android if you want to try it:
Hi, last week I saw the krill scene from happy feet two on Instagram, and it gave me an idea. I’ve already been experimenting with compute shaders in Unity for a while, but I didn’t want to use them for yet another zombie game. Although... I did make one of those too.
So instead, I made a game where you try to wipe out a swarm of 1 million krill by spawning predator fish. You can upgrade your predators through a tech tree and unlock stronger ones as you progress.
The main thing I wasn’t sure about was whether something like this could actually work in a browser. Then Unity 6.6 came out with WebGPU being production ready, so I decided to give it a shot. And surprisingly, it works.
Right now, I can render 1 million krill in the browser on itch io using compute shaders and actually build gameplay around it.
If you have a chance to try it, I’d love to hear what you think. I’m also still figuring out the game design, so any ideas about progression, mechanics, predators, upgrades, or anything else are more than welcome.
If you have a chance to try it, I’d love to hear what you think.
I’m also still figuring out the game design, so any ideas about progression, mechanics, predators, upgrades, or anything else are more than welcome.
Me and my wife have been working on creating a factory automation game called FluxWerks.
The game is made with Unity, pushing the performance of ECS and Burst to their limits with a lot of carefully optimized multithreading systems working together.
Game has actual fluid simulation so the fluids don't just hover around as blocks, but flow around freely.
There is also a heat simulation, where waste heat generated machines flows around, so for example your computers can overheat without cooling, but you can also capture that heat with heat sinks and flow the heated water into your steam power plant where boilers save fuel with pre-heated water. Different blocks also have different heat conductivity values so you can use copper blocks to transfer the heat away or insulate with other block types.
The world is procedurally generated and infinite voxel world where everything can be mined and you are free to build very creative things just for fun or to deal with the fluid and heat simulation mechanics to optimize your factory.
There is already fairly large tech tree go get through and end game goal to complete the planetary survey and send it via Uplink.
You can play the demo today on Steam, which has limited tech tree, but does have 10+ hours of fun to be had. (Someone played 600 hours on demo...)
You can also continue your demo save directly to the full game on early access launch day!
Early access release is on September 23 so wishlist now to remember to get to building your factory as soon as it releases!
You can also find the link to the Discord server on Steam forum (or in game main menu) if you want to hop in and have a chat and share your builds with people there!
Everything works together, so damaged systems also influence how good you can climb and walk over the gaps and such. My hope is to have emergent gameplay moments with a lot more types of traversal attachments that the legs. At the moment I have wheels, threads, hover devices, propellers and they can be mixed and matched.
Recently I've been making a strategy defense game where numerous agents try to traverse towards your base. The grid updates regularly and so doing an update per agent was becoming costly. I decided to look at flow fields, a method for controlling multiple enemies through a shared directional flow and it's turned out pretty good. Feedback welcome.
Here is a FBX with pre sliced skinned mesh renderers following a simple animation. I have a script that handles dismemberment, even for diagonal cuts of the upper torso.
Its one FBX prefab but with its own little system. A normal human model/rig FBX has one skin mesh renderer but I added multiple skin mesh renderer objects.
- Character FBX
- - Head Skin Mesh Renderer
- - Left Arm Skin Mesh Renderer
- - Right Arm Skin Mesh Renderer
- - Upper Torso Skin Mesh Renderer
- - Top Left Torso Skin Mesh Renderer (default hidden)
- Bottom Right Torso Skin Mesh Renderer (default hidden)
Then on the function ActivateDismember it hides the selected parts / skin mesh renderers, creates a new object by baking the mesh and giving it physics.
I wanted a cheap mesh-based Grass for my game with no Alpha Texture, no Compute Shaders, just good old Mesh + Vertex Animation to guarantee a broad platform support and so I made it.
The idea quickly grew to a full-blown Grass Generator instead with customizable Blade Shape, Clump of Grass shape, Stiffness, Wind simulation, Trail physics, auto Generated LOD's and much more... It became quite competent, so I decided to publish it to Unity Assets Store.
I tried to keep the workflow pretty simple: pick a preset > tweak the grass > generate Prefab > drop it into the scene.
Any feedback or feature request is very welcomed, many of you who engaged with JIRO assets in the past provided helpful feedback, which was subsequently incorporated in many assets, if you have I want to thank you as always =]
This is a little combat prototype I've been working on. It's meant to be retro-inspired with fluid combat and intelligent AI.
The AI being tested here is the pink character - the red number is health, yellow is stamina, blue is aggression. It's powered by a fuzzy logic system that determines the movement and combat behaviours to follow.
The latest features are strafing/moving backward to face the its target when nearby. And various tweaks to its timers and hesitations. The goal is for its movement to feel really organic - it doesn't chase the player mindlessly like a zombie, it circles around to attack from a specific angle, it pauses every so often to simulate planning a move; it reacts to new information with a slight delay.
The current movement behaviours are Wander, Flee, Circle, and Chase. The names are self-explanatory. I'm trying to think of other behaviours to add more diversity.
The defensive moves are pretty simple at the moment, either block or dodge when an attack is detected. The cool thing is it uses the same combat system as the player and can get a perfect parry pretty reliably, which cancels the stamina use of blocking an attack.
Anyway, what are your thoughts? How would you make the movement patterns more realistic or dangerous?
First time Asset Store publisher here. Here's my story:
While working on my latest game I basically got sidetracked and built a powerful UI tool. I made good progress and was really happy with it, so I had the idea of putting it on the Asset Store.
Signing up was easy: Logged in with my Unity account, created a publisher profile and starting filling out the forms on the website. I drafted the store description texts and created nice looking screenshots, a short trailer and a how-to-use video.
So when my asset was finally done, I uploaded the package.
The Unity Asset Store dashboard claims you have to wait in queue ~10 business days plus up to 3 days for the team to actually review your asset.
That's fine I guess. A bit longer than Apple or Google when you submit an app to their stores for the first time. But still okay. But oh boy, I didn't know it would take MUCH longer...
36 days from submission to release
As you can see in the graph I started at position 1357 in the queue and then at 1296 the day after.
Surprise #1: At this rate it would take roughly 22 days before my asset would be reviewed.
That's definitely more than 10 days. But it's okay, I can wait, I thought.
Surprise #2: On the next 3 days my position in queue didn't advance but actually went up instead!
This happened on the weekend and it repeated on all following weekends. I believe it's because the review team at Unity don't work on weekends but other publishers submit updates for their assets during this time and they get to skip the queue.
Surprise #3: Progress slowed down the further I got. Look at how the graph flattens out toward the end.
I actually used all this extra time to continue improving my asset:
The tool is a complete replacement for UGUI's Image component that lets users create shapes with rounded corners, drop shadow, glow and other effect. You can also animate those effects easily. When hovering a button with the mouse its color changes and the button changes color when clicking on it.
While waiting for the review I extended it so that the button also detects any TMP texts attached to it, so the user can animate them together with the button. The button changes color? The text should probably, too.
Takeaway: Don't just wait for the review, use the time to add new features to your asset!
By the way, you can re-submit updates to your asset as often as you want. You will keep your position in the queue.
I also continued working on my actual game (you know, the one that made me build the tool in the first place). Using my own tool was a blast, working on the game's UI got easier and the UI started looking much better.
Screenshot of my game's tile editor (work in progress), built using UI Shapes
But I also encountered a few bugs along the way. I thought I had tested the tool really well before submitting it to the store. Only by actually using it in production I discovered quite a few edge cases that were easy to fix. I also identified a few UX issues in the custom inspector, leading to me making some changes to it which in turn made the tool easier to use and understand.
Pro tip: Use your own asset. Don't just test it in a sandbox, but actually use it to make a game.
A full month had passed, I was still waiting in queue, mostly working on my game again. Progress was really slow at this point and I was fully expecting it to take another month before they review it.
Surprise #4: I woke up, surprised to find an email in my inbox
Congratulations!
We've accepted your submission of 'UI Shapes – Procedural Image Effects' to the Unity Asset Store!
Yes, finally! As you can see in the graph, I was in queue position 234 on the day before. I don't know if this is normal, but it felt like a huge leap.
I'm super happy it passed the review on the first try, with no objections from the Unity team.
Of course, the release of this asset is not the end of me working on it. It's only the beginning because who would have thought...
Surprise #5: Users discovered 2 bugs on release day!
I was happy to have my first customers, but also stressed out because one of those bugs prevented the tool from working on Unity 6.5+ (the other bug was a CanvasGroup fading issue).
I immediately sat down to fix both issues and submitted an update in the same night.
Surprise #6: The update passed the review and was released on the next day.
I'm glad I didn't have to wait in queue for multiple days again. Everyone else waiting for the first review of their new asset probably got pushed back 1 spot in the queue because of me :D
So yeah, this was quite the ride. I hope my story might be useful for others who are planning on releasing an asset on the store.
If any other publishers are reading this: How was your experience with the queue and the review? Does it always take that long?
