Jump to content
  • Advertisement

Unity Weekly Updates #46 - Stop Moving Please!

jb-dev

869 views

Hey, hello there! This is yet another new entry in this truly wonderful weekly update blog! This week was quite big. There is a couple of new stuff so let's get right to it!

Pooling

First, I want to talk about a subtle upgrade. In the game, I'm using static factories to generate different game objects such as projectiles, props and entities among other things. 

While this is quite handy (especially since you don't need to drag'n' drop any components at all), it wasn't really optimized.

Some object (especially projectiles) could frequently be instantiated and destroyed. For some objects this is fine but for others, it can really affect the FPS.

To fix this we need to use pools. These are essentially scalable stacks of the pre-instantiated game objects that are ready to use. Instead of destroying them we simply disable them and store them back into the pool, thus recycle the game object and avoiding a lot of overhead. 

image.png.c8ace91918b2b2c53dd1ab7b31ed62b7.png

While on the surface this might seems odd it's actually really useful with short-lived and numerous objects. Pretty simple to integrate into my factories too! It works like a charm!

I've partially based my Pool system off this one if you're interested.

Spark Effect

Next, there's a new particle effect in the game. This one is quite AESTHETIC, so be warned.

Basically, it's a Memphis design effect that is supposed to represent some kind of collision.

image.png.a8e2c456af656fe7b2e6175b45bb6d5f.png

The particles are also coloured accordingly to the colour palette too!

Right now these are used on any physical hit. However, I'm still trying to think about a better use case for them...

Here's a video showing them off:

New Enemy

Finally, I'm proud to say that there's now another new enemy in the game: the archer.

image.png.21f22cd08bc3cf9a48d1a6566f89db77.png

This enemy uses a bow to attack. It will try to keep its distance and instead try to attack at range. It will also try to trick the enemy to avoid being targeted by them too.

They also got a different behaviour that other, in which they will try to circle around their target and keep moving no matter what.

When they're near their target and has a clear sight of them, they will draw an arrow, pull their bow and launch it. It's a good idea to strike when they're pulling their bow as it's when they're the most vulnerable.

Like their sabre-wielding piers, they will also patrol around their room and be on the lookout for any enemies. They will also flee when weak and can be one-shot too!

Here's an encounter with an archer:

Minor Updates

  • Big refactor of the GUI.
    • Replace duplicated code with inheritance.
    • Optimized some GUI events.
    • Fixed some oversight in some GUIs.
  • Added a cached state controller that can cache useful data that rarely changes.
  • Added individual limbs target to player characters
    • Right now there isn't any damage multiplier on the player's limbs nor are the enemies try to target some. 
      • This might be an idea for later though.
  • Made the active arrow much more flexible
    • Replace the unintuitive layer mask int to a LayerMask instance.
      • It makes it so much better to edit these
    • Made the arrow play the appropriate collision sound when colliding with objects.
  • Big code conventions refactor.
  • Added proper animation masks to my animated models
  • Made most behaviour tree controllers much more flexible
    • Basically the same thing as the active arrow, which is replacing layer mask int to LayerMask instances.
    • Fixed bugs with the hamburgers
  • Fixed some oversights in physic collisions between layers.

Next Week

I'm still not done with the archer enemy. It still needs a bit of balancing and bug fixing. I also need to perhaps complexify my behaviour tree a tad bit. 

I'm slowly getting there at each iteration. It's quite interesting and all but working with behaviour tree requires a lot of conception and debugging too!

After I'm done with the archer, I'll probably add a gunner too. Afterwards, I'm gonna focus on the bosses. Of all entities these are probably the dumbest and also the buggiest, so that's up next.

And then there's the usual suspect (relics, capacities, items, rooms, etc.).

I sure hope that with the right type of enemies the game can get better exposure... 

Only time will tell...




0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By kensarto
      I'm looking for pointers before I get started developing one from scratch, I do not have, or plan to spend money on other peoples scripts or products to import into my project which means I can neither see how they do it, nor use their systems directly. As such, this will be entirely hand written to match what I need.

      The specifications are as follows:
      Unique Actors that prompt different conversations, whether that be an NPC conversation, or the interaction with a work station and selecting options. Branching conversation paths (and therefore a method of storing variables to short and long term store flags for different states) Localised scripts.  I do not want to have 3 or 4 different scripts on every object just for this, it would be optimal in my opinion to have a single dialog manager script, but i will be happy if i have to include an "actor" script on the different NPCs along with that. UI (arguably the easiest of the requirements that will sort itself out when I've got everything else working over time) Is there anything obvious I'm missing about functional requirements, non-functional requirements? What is the best place to get started?
    • By Titanomachy Studios
      Project Name: Condors Vs. Ocelots
      Team Size: 15ish
      Genre: Strategy RPG
      Engine: Unity
      Roles Available:
      3D Artists - generalist or hardsurface w/textures
      2D Artists - Characters, World, and UI
      C# developer/engineer(s)
      Social Media/Marketing/Community Manager
      If you feel as if you can offer the team something more that isn’t listed, we are always open to making an exception, just send your resume/portfolio to us!
      Project Length: Currently planning on release Q1 2020.
      Compensation: Rev-share
      Project Status: Vertical slice is done and iteration development has begun.
      Send emails to careers@titanomachystudios.com
       
      Must speak English and have access to a Mic.
       
      Our store page can be found here, https://play.google.com/store/apps/developer?id=Titanomachy+Studios
      Our website here,
      http://titanomachystudios.com/#/
       
      Project Story: Condors and Ocelots have been at war for generations. Battles have left some settlements in ruins. Others teem with refugees. Even away from the fighting, towns and villages suffer from having their fighting-age citizens lured away or conscripted by one faction or the other. Players control their armies and try to wipe out their opponents! Use terrain, abilities and pure cowardice if need be to achieve victory for your faction!
    • By RoKabium Games
      The Riverine design looking like a snake didn’t work very well with the animation so we re-designed this creature to look more like a colourful caterpillar type of animal.
    • By intenscia
      mod.io is an cross platform mod service created by the team behind ModDB.com and IndieDB.com. It can be integrated in-game using the  REST API, C/C++ SDK or engine plugins (if available) Unity is ready and Unreal Engine is in development.
      Features include:
      Platform agnostic (support 1 click mod installs on Steam, Epic Games Store, Discord, GOG, itch.io and even consoles in the future) Clientless (mod.io has no other dependencies and works behind the scenes in your game) Embeddable web app UI, so you can integrate your mod community anywhere Powerful search, filtering and tagging of mods Moderation and reporting systems built-in Steps to getting mod.io integrated:
      Add your game to our test environment or production Read our API documentation for an overview of how mod.io works Choose an Engine Plugin, API or SDK to integrate mod.io into your game and mod making tools Ready to launch? Add your game to our production environment then let's discuss promoting your release Need help? Our team is available on Discord to assist and our getting started guide has more information for you  
       
      Benefits of using mod.io:
      mod.io offers the same core functionality as Steamworks Workshop (1 click mod installs in-game), plus mod hosting, moderation and all of the critical pieces needed. Where we differ is our approach to modding and the flexibility a REST API offers. For example: 
      Our API is not dependent on a client or SDK, allowing you to run mod.io in many places such as your homepage and launchers Designing a good mod browsing UI is hard, our plugins ship with a UI built in to save you a lot of effort and help your mods stand out We don’t apply rules globally, so if you want to enable patronage, sales or other experimental features, reach out to discuss Our platform is built by the super experienced ModDB.com team and is continually improving for your benefit Your community can consume the mod.io API to build modding fan sites or discord bots if they want Large studios and publishers:
      A private white label option is available to license, if you want a fully featured mod-platform that you can control and host in-house. Contact us to discuss.
      Find out more:
      Visit mod.io | About us | Add your game | Chat on Discord
      These screenshots are from our Unity plugin:




    • By SuperVGA
      A little backstory:
      I'm tessellating some simple terrain. I have some patches which are modulo translated up to their own size, so the patches are repeated while giving an effect of being an endless supply of patches to either side. I'd like to only translate them up to one unit instead, so that the far reaches of all my patches don't change by the full patch size, but only by one unit.
      However, the winding order of the triangles differ, and 4 texels in the heightmap render different depending on the winding order, so I'd like to enforce the winding order for all the generated triangles.
      Is there any way to dictate the triangle winding order for all the generated geometry? I'd like for them to be similar, not flipped around the center of the patch...
      Thanks in advance,
      /SuperVGA

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!