Jump to content
  • Advertisement
  • entries
    16
  • comments
    4
  • views
    675

Spawning System Overhaul and overcoming the obstacle of enemy pattern making

FatPugStudio

878 views

The Grid

Wow, it’s been a while, but things are moving forward slowly but surely!

I’ve been busy with lots of coding and programming enemies and i encountered some difficulties in proper positioning. On the image below you can find how the spawn points looked (5 spheres on each side) and how they look now (the red X signs)

Spawning GridObviously, 12 times more spawning points offer much more flexibility

Obviously, it offers much more in terms of positioning. More than a year ago, when i first started working on a spawn system i wasn’t apt enough to make it the way i wanted to (grid system) so i had to be satisfied with only a few spawn points and additional repositioning upon instantiating. Needless to say, it adds much more work to simple spawning and positioning of those enemies.

By using this handy tool from the asset store (https://www.assetstore.unity3d.com/en/#!/content/20502) i created a grid made out of objects completely automatic. A fine tool indeed. After that, i simply added those to the hash table and now i can simply reference the object whose position i want the enemy to use as spawn point and voila. Besides using it to spawn enemies already in a pattern, i can use them to actually create random patterns on runtime by referencing a different object from the hash table upon predefined parameters to avoid completely random clutter. Not only that, a finer grid enables me to avoid spawning the enemies too close to each other or overlap. Since i’m using Core Game Kit for spawning, i’m waiting for the developers to implement the feature based on sphere raycasting, i.e. if there’s an object of certain tag or layer (enemy) in a defined range, the system won’t spawn any more to avoid the overlapping. It will work great with the system i made and described few devlogs earlies which is based on enemy pool values and enemy quantities.

Also, Easy Save 3 Beta will soon get a full release (i hope VERY SOON) which will enable IMPORTING variables from a .csv file. It will be of an immense help for tweaking the gameplay.

Enemy Pattern Making (Squadrons)

I must admit, though i am passionate about making a game, some things are quite tedious. I’m having problems with making enemy squadrons, and the way i make them is so boring and uninspiring it really halts my progress.

Before i was well into Unity engine limitations on nested prefabs (only one child per object, i.e. child cannot have it’s own child as a prefab, only when instantiated on runtime due to way serialization works) i thought it was going to be a breeze, i just drag and drop enemies in a formation, put them under a parent prefab and voila! Except it doesn’t work like that. All of my enemy prefabs typically have two children, Gunpoint and Thruster. Gunpoint hold the shooting logic and muzzle flash animation, while Thruster has the, well, thruster animation. It is on a separate object to avoid being colored with the rest of the enemy ship when it changes color on hit by a player weapon.

So i guess i’ll keep my work and make an empty squadron prefab which will spawn and then spawn the enemies in a desired pattern coded into it. That’s all nice and dandy until you actually start working that way. No more cosy drag and drop, just selecting what to spawn, input coordinates and hit play too see what you’ve done. If something’s not positioned correctly (it usually isn’t), reposition the enemy, copy the coordinates, stop, and paste them. Repeat 10 times for 10 enemy objects in a squadron, and i should have hundreds of them! Horrible!

Prefab and Runtime comparisonPrefab with multiple children with position setting on runtime

So i decided to change my ways. I need to make a reverse approach. Instead of creating an enemy prefab with all the children attached, i’ll attach the Gunpoint and Thruster on instantiation, which is only a two step process compared to setting the position of multiple enemies inside the squadron. This way, i have a clean enemy prefabs without children which i can joyfully drag and drop into positions i want and simply save them under a prefab which will be used for spawning.

Prefab and Runtime Setting 2Prefab with multiple children instantiating on runtime

Though it is a bit more work initially, it provides an immense saving of time later and makes it more visual, fun and intuitive to work with.

The post Spawning System Overhaul and overcoming the obstacle of enemy pattern making appeared first on Fat Pug Studio.


View the full article



4 Comments


Recommended Comments

If I Understand correctly you have the thruster as a separate GameObject so you can change the ships color without changeling the thrusts color. could you not make a prefab with the thruster as child component, still using the ships spiteRender to change colors?? it would save time on start, which probably won't really make a difference in a 2D-game but -_-

 

Cool looking game either way. —Brua-1589

Share this comment


Link to comment

Sure, that's what i did in the beginning. Unfortunately, Unity does not support more than level of nested prefabs in the editor, only on runtime (unless you are using some of the suspicious quality third party assets) so i wouldn't be able to make squadron > ship > thruster hierarchy which speeds up the process of creating enemy waves significantly.

Edited by FatPugStudio

Share this comment


Link to comment
7 hours ago, FatPugStudio said:

Sure, that's what i did in the beginning. Unfortunately, Unity does not support more than level of nested prefabs in the editor, only on runtime (unless you are using some of the suspicious quality third party assets) so i wouldn't be able to make squadron > ship > thruster hierarchy which speeds up the process of creating enemy waves significantly.

interesting, Never run into this problem before. But I feel like I'm going to with the project I'm working on. That's actually really inconvenient. I was hopping to help out but -_-

 

—Brua-1589

Share this comment


Link to comment

I'm sure you'll encounter some of the Unity quirks as that one as you delve deeper into it, unfortunately. But every engine has its problems. 

Share this comment


Link to comment

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
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!