Scripting 2: Script: Shooter_AI

Shooter_AI is a script used by enemies that shoot projectiles.

This is an overview of the Shooter_AI Script.

This script contains 13 public variables and 9 private variables. Every public variable is used to customize the projectile being shot.

VOID Start()  Only used to set the pooler boolean.

bulletshot: The array of projectiles being shot, customizable.
pooler: If true, then all projectiles are created from the start, if false then projectiles are created when they're shot.
if the length of the bulletShot array is larger than 1 projectile, pooler is set to true and RefChecker() is called. Otherwise pooler is set to false.

VOID Update()  Only used to control knockback

Sets the motion of the enemy. Like the HPscript, Shooter_AI has its own special movements. These movements are used only to affect the enemy's knockback after shooting a bullet.
Lerps hspeed and vspeed to 0 by 0.2f;
transform.Translate(hspeed/10,vspeed/10,0);

public VOID ProjectChoose()  This is the function called by other scripts.

if pooling:

• Checks each projectile saved in the bulletshot array.
• The fires the first inactive projectile found with StartCoroutine("ProjectileToss", bulletshot[tC];
• If the checked projectile is active, tC+=1, and the next projectile is checked.

if not pooling:

• objReffed = Instantiate(bulletshot[0]);
• The fired projectile's function are reset through the ProjRefSet function.
• Then the projectile is fired with StartCoroutine("ProjectileToss",objReffed);

IENUMERATOR ProjectileToss(GameObject tRef) Fires the projectile

• First checks the enemy HP. If HP is lower than 0, all coroutines end immediately.
• At this point, the object is disabled and enabled to ensure it gets reset.
• The projectile's position is first set to the object firing it, with a displacement created by the Vector 2 bullDistance.
• The knockback is set based on shootStrength; Vector2
• The projectile's hspeed and vspeed are set based on bulletspeed; Vector3
• The projectile's gravity is set based on bulletslow; Vector3
• The damage is set based on bulletDamage; Integer
• The element is set based on bulletElement; String

VOID RefChecker() Only used for pooling, creates all the pooled projectiles.

• Each prefab in bulletShot is instantiated;
• Each prefab in the bulletShot array is replaced with the newly created gameObject;
• ProjRefSet() is called for each projectile;
• Each projectile is now deactivated.

VOID  ProjRefSet(GameObject bulRef) set the projectile variables.

• startTime = How long the bullet will remain active before despawning.
• initialSize = Original size of the bullet.
• sizing = Active size of the bullet.
• element = Physical traits of the bullet, given through a string.
• diesOnHit = whether or not the bullet will be destroyed upon collision.
• homePoint = whether or not the bullet will home in on the player.
• After all the variables are set, the bullet is parented to the "Projectile_List" gameObject for the sake of organization. This gameObject is located within the Scene_Prefab object present in all levels in the game.

Scripting 1: Script: Enemy_Health

Enemy_Health is a script required by every enemy character. Its purpose it to control the enemy HP, taking damage, reacting to damage, spawning and despawning, and holding important variables.

This is an overview of the Enemy_Health Script.

Due to the nature of this script, there are 32 public and 6 private variables. Some variables are public for the sake of customization on a per-enemy basis, others are public so that other attached scripts are able to read them.

7 of the public variables are spawner variables, which get passed on to a spawner object created by the Enemy_Health script on startup. This spawner is responsible for respawning the enemy to which the script is attached.

VOID Start()  Creates the permanent variables.

• maxEnemyHP = enemyHP; sets both variables to be equal.
• nightlight = gameobject with "NightLight" tag; This light is used to control colorizer.
• body = attached Rigidbody2D; This is optional, most enemies do not have a Rigidbody2D.

Colorizer Variables

• alterGlow and savGlow are reset to uniqueGlow's value.
• appearance = SpriteRenderer; Saves 2D renderer information for colorizing.
• if there is no SpriteRenderer: appearance3D = Renderer; Saves 3D renderer information.

Spawner Variables

• enemySpawned: The enemy to spawn, always set to "this.gameObject";
• distanceToSpawn: Radius of CircleCast around the spawner. Defaults to 30;
• infiniteSpawner: A countdown to auto respawn the enemy, does not auto respawn if int == 0;
• respawnLimits: An int that controls exactly how the enemy will spawn.

respawnLimit meaning:
 0= Regains ability to respawn when the player is far away.
 1= Only respawns when the player dies.
 2= Will keep respawning until the enemy is killed. Useful for minibosses.
 3+= Will not spawn or create a spawner. Useful for event-based enemy spawning.

And finally, the enemy gameObject is always set to be inactive after the first frame.

VOID OnEnable()  This acts as a reseter.

• enemyHP = maxEnemyHP; Resets HP to maximum.
• Colorizer(); Resets color.
• focusPoint is set to active. Useful for minibosses that need the camera to stay still.
• canBeControlled = false; Resets debugging functionality. 
• deactivates spawnObjects- spawnObjects are meant to spawn after the enemy dies.
• reactivates killObjects- killObjects are meant to despawn after the enemy dies.

VOID OnDisable

focusPoint is set to inactive. Optional, focusers tell the camera where to go.

VOID Update ()

• movRef variables are set. movRef references the enemy's Movement, if attached.
• if there is no movRef, the hSpeed and fSpeed variables are set instead. These variables Lerp towards 0, and are used to tranform.translate the object. These variables control knockback.
• finally, countdown variables (hurt, para, etc.) are updated by -0.1f; 

After the initial variables are set, the colorizer function is called.

To override the initial colorizer is the Pain Throb feature. When an enemy's HP falls below 25% they will begin to glow and throb red. After these variables are set, the colorizer is called a second time.

Finally, the dying variables are set. This section reads the HP, and if it's below 0 the enemy begins dying. 

At this point spawnObjects are spawned, and killObjects are despawned.

VOID Colorizer() Changes sprite and model color based on the light and atmosphere.

The Enemy_Health Script contains its own version of the Colorizer script, this is to create the throbbing effect. Enemies can also have a unique glow.

VOID OnTriggerEnter2D(Collider2D other)

If the variable "touchdamage" is greater than 0, the enemy will damage the player on contact. This variable is turned off for almost every enemy in the game.

Enemy Design 1: Fansher

Fanshers

The first enemy found in Evanlily Crown. 

Classification: Monster, hybrid (drake + insect).

Appearance: Round body, small abdomen, large lenses, long segmented tail with stinger.

Diet: Meat (preference for pigs), slimes, and fruit.

Location: Forests.

Attacks: Mucus projectile (attributes change based on diet), headbutting, screeching.

Threat Level: 1- Aggressive, but very weak

  Details  

Their appearance is bug-like, but their anatomy is closer to a reptile. What appears to be gigantic eyes are in truth immobile lenses held in place by a rotating exposed bone. The stringer at the end of the tail can fire fecal discharge as a hazardous projectile mucus.

Fansher are territorial meat-eaters, and will jump at the opportunity to hunt anything that enters their space. In-game their default behavior has them flying in groups within a set range. Once prey enters their domain, they attack by spitting fecal mucus from their stingers. The properties of this mucus range from being acidic, to gelatinous, to scorching hot, biting cold, and etc. 

They will usually never leave their territory unless desperate for a meal. Large Fansher are much more likely to use different tactics against prey, some may even try to tackle their target.

Character Design 1: Lily

Before Crowns visual elements could be designed, the main character's look had to be completed.

Lily's design was changed more than 4 times while I worked on this game.
The design used for Crown is simply a younger version of the final adult design.

Using blocks can help compare colors for a design. Thank you, Mark.

Evanlily Crown uses HD sprites rather than Pixel art, as a personal preference.

A few things I learned to keep in mind while using HD sprites:

• Thick lines look nicer when the camera zooms out.

• Color contrast is important. Use blocks to help compare colors

• Be sure to finish the outline within the animation program, or they will wobble.

• Not every pixel needs to be perfect, that's what pixel art is for.

• Keep designs simple, because details can still be lost.

• Rendering needs to be handled with extra care during the animation process.

Characters and designs displayed on this page are the copyright property of: Marcos TM.

Lily's first sprite was based on a teenage version of the character. This design proved to be less appealing than the original (Center), and was abandoned. At this point I also began to notice difficulties in using HD sprites.

The second design is an unfinished sprite of Lily's original appearance. It was at this point that I began to consider dumping the HD sprites in favor of pixel art, as the large sprites took up too much of the screen.

​

The third design is the final version that will be used for the game. Rather than going with smaller pixel art sprites, I chose instead to make the character herself smaller. The younger character's proportions took up less of the screen and were easier to animate, solving a few issues.

The programs used to create these sprites were:

Pixen for the pixel art (Not used for final game)

TvPaint10 for the animations (Not featured here)

and Manga Studio 5/ Clip Studio Paint for the art and final rendering of animations.

Post #1: Chellybeam Boss Visual Design

The Chellybeam was originally designed as an angelic-looking miniboss, that was eventually worked into a full boss fight. 

The boss' attack patterns will be discussed further in the future, this post will instead tackle the visual design choices.

The original version of this boss included a 2D sprite for a body, and 3D wings. This proved unnatractive.

​

The second version of the boss kept the 2D body, but flattened the wings further. The animations at this point were also fixed up as was advised. This version still failed, as the wings and body clashed with each other, and the body did not act enough on the wing's movement.

​

The third version of the boss is full 3D. The animations were once again fixed up, and the overall appearance of the Chellybeam was improved by the new 3D body. This is expected to be close to the final version of the boss, and I'm expecting that all future bosses will follow the same pattern of being fully 3D. Future tests will determine if this 3D boss clashes too much with the 2D characters, and if so the current backup plan is to edit the boss' shader to better fit the world around it.

Characters and designs displayed on this page are the copyright property of: Marcos TM.