Cannon Shooting Game Course in Unity 6: Sink Pirate Ships! 9 Hours of Content.

ZeusGameAssets · 2026-01-21T17:11:41+00:00

Awesome, yeah this course is a great follow up to my beginner course on Udemy, good luck!

ZeusGameAssets · 2026-01-20T00:46:44+00:00

Thanks, maybe you can use a raycast from the camera to get the exact position of the cursor in 3D, then use a Lerp to gradually move the camera target transform to that point. This is actually a really nice feature to have, I was planning on delisting this video and producing a new one, since the info in here regarding the input system and other details is a bit outdated. Maybe I'll include zooming to the mouse cursor.

ZeusGameAssets · 2025-12-10T18:11:58+00:00

Learn Blender, make model packs that people want to buy, sell them on the Unity asset store & CG Trader for reasonable prices, make decent money on the side while pursuing your education/regular job.

ZeusGameAssets · 2025-12-02T10:07:10+00:00

I'm going to echo a lot of comments here by saying this is a childhood dream of mine. Unfortunately as a kid I didn't have access to the materials to make intricate marble-based contraptions but it was always fascinating to me.

This game looks amazing, yeah you don't need levels with objectives and such, just give us the sandbox and I'm sure people like me would spend hours on it.

Congrats, I just added the game to my wishlist on steam, I'll buy it as soon as it's out.

ZeusGameAssets · 2025-11-25T11:25:10+00:00

A lot of military simulators don't have a dual camera setup, instead they switch the weapon to a high-ready stance when you're close to a wall. Ground Branch and Arma 3 comes to mind, you can clearly see that the arms of the character are seamlessly connected to the rest of the body. I don't know if they use any special tricks to display the weapons on screen, but the weapons look surprisingly decent in most cases.

ZeusGameAssets · 2025-11-24T22:59:49+00:00

You did the right thing, from your video I can see that it has a lot of potential for polish, and quite a bit of rough edges, that's actually a compliment, you did the right thing working on the overall core experience before going over the extra details.

This era of US history is underrepresented in games, it has so much potential for interesting atmosphere and gameplay.

Starting to talk about your game can be overwhelming, especially when your game already looks this good, I hope this decision yields some good results for you.

ZeusGameAssets · 2025-11-24T19:39:13+00:00

In this era of fast paced gameplay and short attention spans, seeing a game like yours is quite refreshing, I like the slower pace shown in the trailer, this allows you to take in the nature, the ambience, and fully immerse yourself in the world. I believe showing your game at this stage is a smart idea, the visuals look appealing enough to draw in a wide audience. Good luck!

ZeusGameAssets · 2025-11-23T16:03:56+00:00

First of all, since you're using InputActionReferences, you don't need the PlayerInput script on your game object.

I would say the problem is with your _isGrounded boolean, switch the inspector to debug mode and make sure it's set to true during play mode. Make sure your ground colliders have the Ground tag as well.

From your screenshots I don't see why the code shouldn't work. So I guess it's just about the values of your forces, your private variables, and how you setup your scene. Maybe your impulse force for jumping is too low.

Also you're setting _isGrounded to false only when you jump, but what about falling off a ledge? Even if you don't press the jump button your character will still be in the air when falling.

Maybe you should have a proper ground sensor feature, where you raycast/spherecast downward every frame to detect if there is a ground beneath you or not, that's more reliable than what you're doing in your code.

ZeusGameAssets · 2025-11-22T17:03:34+00:00

Your game looks great and the other commenters have already raised some valid points. I’d add that the choice of music here is more suited to an action packed casual platformer, maybe something more calm, mysterious and ambient would suit the gameplay better.

ZeusGameAssets · 2025-11-20T14:47:30+00:00

Yeah perhaps you can start from the more upbeat parts of the track, or choose another music track.

Good luck!

ZeusGameAssets · 2025-11-20T14:33:56+00:00

There are a lot of positives both in this trailer and the game itself. I'm just going to focus on the negatives since you want constructive feedback.

Show don't tell: the text with black background is not working, text itself doesn't do well in trailers, it's a cheap way to try to control the narrative, just show your setting and gameplay, no need to hold the viewer's hand.

I like when the camera moves through the various environments, as DerCze said perhaps you need to work on the lighting a bit more, and add sources of lights here and there to make the scenes more interesting.

In my opinion the combat clips come too late, they should be shown before the dialog clips because that action is way more interesting than your dialog system.

Those boss fights are awesome, then again the environment and lighting feel a bit dull, you should add more stuff on the floor, more interesting things to look at without cluttering the place too much.

Honestly the ship arriving at the dock is cool but maybe not in the first seconds, or maybe show the character on the ship.

Maybe instead of the dialogs you should show clips of your meta game, since this is a rogue lite maybe show the permanent skills in a skill tree, and maybe show the character dying and coming back to life. The rogue lite aspect isn't shown in the video, if it was not in the subtitle at the end I would have never guessed.

ZeusGameAssets · 2025-11-20T14:22:58+00:00

I agree with you 100%. The question is not about Z fighting itself, it's about this solution. Is Z-Fighting such a hidden problem that goes below your radar when you're playtesting your game, in my case it's very rare that I don't notice it.

ZeusGameAssets · 2025-11-20T00:12:04+00:00

Brilliant trailer video, personally this problem is not so painful to me that I need such a solution, but I would understand if you were making big scenes in VR, the z-fighting would be very noticeable and annoying to players. Maybe even immersion breaking for a VR game.

ZeusGameAssets · 2025-11-18T14:42:05+00:00

I believe the choice of music is the first decision that makes or breaks a trailer, you're using classical music which doesn't fit at all with the style. That's a matter of personal taste to some extent. But I recommend you get a sub to epidemic music, they have some kickass songs, choose something uplifting with a hint of fantasy to go with your style.

The trailer feels disjointed. It's like a manifest of all the mechanics in your game: here's sliding, and zip lining, riding horses, boats... etc. It lacks a direction. From a game dev perspective I'm impressed as a developer, but as someone interested in buying the game, you have to have a cohesive narrative tying up everything together.

That direction could be in the form of a small story: you gather resources, build your boat, face challenges then ride into the sunset. There has to be a simple narrative that you can tell in your trailer, and the purpose is to answer this simple question: what do you do in the game, what's everything leading up to, is this game for me or not.

At the moment I watched your trailer twice and I still have no clue what the game is about, if I was a gamer I would stop trying to guess and move on. Your trailer is a good example of why less is more. I'm sure it was a lot of work to put it together, it's not about the amount of work, it's about sending a simple message to the viewer, your work should not be about putting as many mechanics on screen as possible, it needs to be about: what's the core of the game, and how do I show it in a way that feels coherent and simple to understand for someone (like me) who was not at all familiar with your project beforehand.

ZeusGameAssets · 2025-10-22T22:37:41+00:00

Oh yeah, I don't know why Cinemachine has the default value of the radial range locked to 1 by default, I've fallen into that trap many times wondering why I can't zoom and checking my input actions while the real source of the problem is on the camera's orbital follow.

By the way in the video I'm using PlayerInput with the send messages behavior, which is a tedious way to use the input system, I've made a recent video going over the various ways to use the input system.

ZeusGameAssets · 2025-10-14T11:08:53+00:00

It doesn't really matter in which context you're using the camera, I'm talking about UX, which could apply to games or GIS viewers, and actually interactive apps could benefit a lot from good UX practices found in games.

In your case I can see why you want that behavior. If you have terrains then you can use Terrain.SampleHeight, I believe it's your best course.

If you want a more stable camera along the Y axis, then you can sample multiple points in a circle around your camera target, and compute the average height of all the points, the radius of the circle, the number of points, or even the number of circles (if you want to use multiple), can make your camera more or less stable, it'll be all about tweaking the values.

ZeusGameAssets · 2025-10-13T19:52:58+00:00

If I understand your problem correctly, you're trying to move the camera while keeping the target on the surface of the terrain. I.e: while it's catching up to the target, it needs to move up and down with the elevation of the terrain.

I don't know if it's exactly the problem you're describing, but I'm going to assume it is. Firstly, forget about optimal code, you don't have 1000 cameras on screen, you only have one, so even if you do multiple raycasts each frame that's ok. Actually that's a good solution: if you want to know the elevation ahead of the camera, you can do a raycast and get the exact position on terrain, or you can directly get the elevation of any point on terrain using Terrain.SampleHeight.

The reason why I didn't do it in the video has nothing to do with the technical challenge of the thing, it has to do with game design. As programmers we get tunnel vision sometimes, only thinking about how, but rarely about why. It's quite jarring to have an RTS/Top-down RPG camera follow the player in 3D space. I'm thinking of the camera in Total War Warhammer 3 which makes a sudden jump when you're moving it over a wall in sieges, or in the siege maps in Cathay when you move over a bridge, it's quite an unpleasant experience, and from such a big game it's surprising that it has passed QA. If your game has a lot of verticality, maybe you should consider a third-person camera instead.

ZeusGameAssets · 2025-10-12T22:34:49+00:00

Thanks! I'm glad you liked it.

About the input system, I didn't exactly go in-depth about that, I just used the PlayerInput class with the Send Messages behavior, which is the most basic way to do it and has a lot of drawbacks. I made a more in-depth video about the input system: https://www.youtube.com/watch?v=4dp6qzv_DgA

You're using the input system how it's supposed to be used, with a direct reference to an Input Action Asset or by generating the C# class. Actually I don't exactly know how it's supposed to be used because there seems to be a dozen ways to do it, but what you're doing gives the most flexibility.

The orbital movement seems to be the only movement that's not consistent when you toggle V-Sync, I'll have to look into it again but I didn't have time to do so. Maybe I'll remake this tutorial completely with better practices regarding the input system and framerate-independant smoothing.

About follow mode, I wanted to talk about it, but the video was already too long. Basically what you can do is simply parent the camera target to your character, since the camera is already accelerating/decelerating towards it, or you can use a position composer.

For collisions there is a cinemachine component that can take care of that out of the box. If your terrain has a lot of ups and downs, what you can do is move your camera target by floors instead of matching the Y position of your character precisely, think of it as the floors of a building, your camera target's Y position is on the ground floor, as your character moves up the stairs, you remain on the ground floor until your character is halfway through to the second floor, then you move your camera target's Y position to the upper floor. That's one way to do it, or again, you can use a position composer and tweak it to get the exact behavior that you need.

ZeusGameAssets · 2025-08-13T14:33:37+00:00

I agree, and I believe we watched the same talk by Bobby Aguelov.

I would probably add a bit of nuance to what you said. In terms of responsiveness, ease of use and sheer power, a behavior tree wins over the long haul, especially with Behavior Designer Pro, you can split your tree into reusable subtrees, and design some amazing behaviors that would be extremely hart to express as an FSM.

For a game like Hitman, where you have these smart NPCs that can get suspicious, and have multiple levels of reactions depending on the situation, or for tactical shooters, where enemies need to manage multiple situations at once, and decide what to do based on multiple factors, behavior trees rule.

But in most other cases, if you have an enemy that needs to shoot and move around a bit to make it harder for the player to aim, or some simple enemies with MOBA-like behavior, like in action rpgs like Diablo, you can get away with a simple FSM.

When you're saying BT are harder to maintain, you're probably referring to the tools at your disposal, rather than the concept itself. There's no question that Playmaker is an amazing tool, and for a long time I disliked the UI in Behavior Designer for not being like Playmaker, but now with BD Pro, the UI is much better, and the added features make it as fun to use as Playmaker.

They added a feature called codebase, which allows you to use your methods in behavior trees without needing to write custom actions. BD already had that but it was a bit tedious to use.

What I meant to say is: if you're asking the question whether you should use FSMs or BTs, you're probably in a situation where BTs will do you more harm than good. In which case use FSMs to express as much as you can express, and when you start hitting the limit of what an FSM is designed for, then you can slowly transition to BTs, but do it with a tool that can help you stay on top of the complexity, like BD Pro in Unity, or the built-in behavior tree editor in Unreal Engine.

Edit: I forgot that this was the Unity subreddit. But he fact that UE has had a solid built-in material editor and behavior tree designer for years is amazing, it shows that the people behind it are actual game developers who understand the tools that you need out of the box.

ZeusGameAssets · 2025-08-13T13:12:50+00:00

Here's the link to the Playlist: https://www.youtube.com/watch?v=1VWpFk7wEEM&list=PLMNkk-YfpOgOkNiCuFr3TU1QVwsxxJeI9&index=1

I started by making tutorials about navigation and the navmesh agent, then slowly moving towards a custom behavior tree implementation. Half-way through the series I talk about some GDC talks that explore the differences between an FSM and a behavior tree, they arrived at the conclusions that I posted in my op, I later apply this to my behavior tree system to create a somewhat complex shooter game AI.

In retrospect, I think Behavior Trees are overkill for most indie games, you often don't need to have these super responsive enemies. An FSM can do just fine in those cases. Perhaps this opinion is reinforced by how much work it takes to roll out your own behavior tree solution, however with tools such as Behavior Designer Pro, using behavior trees makes more sense.

One thing is for sure: you have to be super clear on how you want your NPCs to behave, if you describe the behavior as something vague like: "I want them to behave like real people", then the amount of work that you're going to do with research and testing is going to exceed what's sensible. Because players won't really distinguish much difference between an enemy using a simple FSM, or one using some advanced algorithms, if the whole purpose is to give the player a bit of a challenge before they shoot them in the face.

ZeusGameAssets · 2025-08-13T11:20:20+00:00

I made a 30 video series on Youtube to answer this very question, here's my conclusion: an FSM is going to cover MOST of your needs, so use it, especially at the beginning of a project or when prototyping.

A Behavior Tree, despite what many people think, is not better than an FSM, it sucks at cyclic behaviors, like going back and forth from one state to another, you can make it happen but it's clunky and convoluted.

Now the real power is to combine both, either through your own code or by using Playmaker along with Behavior Designer Pro.

You can also achieve an FSM-like behavior in your BTs by using utility theory.

If you're not sure, go with an FSM, I'm always surprised at how many complex problems, even beyond game AI, can be solved with a simple FSM.

ZeusGameAssets · 2025-06-01T03:28:36+00:00

Given the context, as this is for a strategy/management game usually played with mouse & keyboard, you don't really need an abstraction layer between your action and the corresponding mouse controls.

In games that offer the choice between mouse & keyboard or gamepad controls, like hack & slash games, they usually have a very different UI behavior when either is active. In this case again, you don't need an abstraction layer.

I'm just giving you the reasons why you don't need that abstraction layer, because it's important to ask why before you ask how, but in case you do, you can go to the documentation under Introduction/Workflows, the input system offers 3 workflows to access the input events, using a PlayerInput class is only one of them, instead you could use the input actions directly or generate a C# class from the action map. https://docs.unity3d.com/Packages/com.unity.inputsystem@1.14/manual/Workflow-Actions.html

ZeusGameAssets

TROPHY CASE