Fansher

Fansher

Classification: Monster, drake.

Diet: Meat (preference for pigs), slime drops.

Found: Everywhere, mostly live in forests.

Rarity: Very common.

Their appearance is bug-like, but their anatomy is closer to a reptile. What appears to be gigantic eyes are actually immobile lenses held in place by a rotary bone. Breeds with legs have higher intelligence and specialize in laying traps, while breeds with tails are more aggressive and specialize in ranged combat.

Breeds

Bugging Fanny

Attacks: Projectile Mucus (attributes change based on diet), headbutting, screeching.
Threat Level: Average- They are aggressive, but very weak.

Attack Pattern: Will try to keep a distance and shoot its weapon from afar.

Hunting Tip: Use magic to attack it from a distance, or reflect its own projectile back at it.

The most common breed of Fansher, easily discerned by their green coloration and long tail. The stringer at the end of the tail can fire a hazardous projectile mucus, which is actually the creature's feces. The physical properties of this discharge vary depending on environment, with the most common type being acidic. Bugging Fansher are highly territorial meat-eaters, and can easily become very irritating pests.

Art 3: Base Game Model Recording 2

  

Continuing my work on my base model for Evanlily Beast World. Like before, I will release the next few the videos on Wednesday and Friday, then update this page before next week's post.

Not much to say here. Since I finished the initial modeling and rigging with the last set of videos, this time around I'm just polishing everything up.

Top Venus(name pending) 1: First video & concept art.

Controls: 

Arrow Keys / WASD/ Analogue Stick/ D-Pad- Moves.
Space/ 3/ B- Jumps.
Shift/ R1- Walk.
Q/ L1- Lock on.
Right Mouse/ 0/ 1/ 4/ 5/ X/ Y- Dodge
Left Mouse/ 2/ A- Kick attack.

About the video:

I'm pretty happy with the walking animation, so I show that off for a bit at the start along with the pants on/ pants off feature. The walk was partially inspired by Bayonetta, and shows off Venus' personally pretty well.

After that I show off the clothing removal a bit more. When Venus does not have her wings she can't fly. Her clothing is actually based on her HP. She gains a double jump when her HP is 3, her wings and 2 more midair jumps when it's 4, and has 5 total midair jumps when it's full. You get more clothing as you defeat enemy succubi, seen in their idle state in the video.

If she loses too much clothing her animations change so she covers her chest. This also serves to let the player know that she's lost too much HP, and her abilities have become too limited. At this point you're no longer able to home in on things to kick around, and have to fight with your own power until you can reclaim your clothing & HP.

Which leads me to the next point, Venus' main attacking method: she kicks things into other things. In the video this is represented by a ray that shows where the enemy would fly when kicked. She has a homing feature with this attack, which gains more range as her HP rises.

The last feature is mainly for the debug mode, but it'll be available for the player to use at their discretion: time control. I added this feature partly just for being sexy, and partly to test how well I could implement it. This whole project was mainly to get me into scripting for 3D games, this was my first time scripting for 3D features.  I definitely plan to use what I learned in future projects, whether or not I decide to continue this particular game past the Game Jam's ending.

The initial idea for "Top Venus" was a game about someone who stole people's clothes. At first it was some sort of love god who ran around randomly stripping everyone. But soon I had the idea for the main character also losing her clothing, and even gaining powers based on her outfit. The idea of a succubus who stole her opponent's clothing was pretty appealing to me, though admittedly it's a bit less original than you might know. The initial design for Venus, as seen above, was very appealing to me and brought the idea together.

Art 1: HD Spriting method

Summer classes are over, so here's something I hadn't done before to celebrate.

My method for creating the HD sprites is pretty simple. My tool of choice is Manga Studio 5/ Clip Studio Paint. 

Here are 3 character sprites as an example.

The first phase is the "rough." The amount of how finished it turns out can vary a lot. 

I'll use a "messy" rough when I don't have a good idea of how the character's sprite will look, and just want to get the pose down so I can have at least a solid enough foundation to design on top of.

The "nude" rough comes out when I have a really good idea of the character and pose, but haven't fully finished their design or haven't decided on what they should be wearing. I use this one the most often, especially with finished pieces. Sometimes the nude rough won't even have hair.

The "polished" rough comes out when I know exactly what I want from the sprite. Usually there's still a messy and nude phase, but after a certain point I've cleaned the rough so much that I just ended up erasing them.

I just use a basic pen brush for this. Feel free to choose any thin brush with minimal aliasing.

The "outline" phase can go by very fast or very slow depending on how developed the rough phase is.  If the rough is "messy", the outline might as well be a second roughing. Regardless, the outline is always faster than the rough as even a very incorrect rough gives a good foundation. On the other end, if the rough turns into a "full outline" I can just skip this phase and copy the rough over.

For the initial idle sprite I do the roughing and outline using Manga Studio 5. But when I'm animating I use TvPaint instead, and then export the outline to MS5 for coloring and rendering. I'll go over my animating and TvPaint techniques some other time.

The "color" phase has multiple steps to it. First I select the area that's going to be colored. I do this by placing a selection block around the outline, and deselecting everything outside the character. After that I color everything inside the selection with the character's most prominent color. 

Each character gets a block. This is used to compare the colors without an outline getting in the way.

Then I just color the character with the fill bucket.

The following step of the "color" phase is one of the most important. I create color blocks representing the character in a minimalist form. I've mentioned this before (thank you, Mark), the best way to test if your colors are effective is to compare them in a simplified format. 

In the picture above: the right block is the character's original colors, and the left block with a circle over it is the re-colored version. You want to keep each color from clashing with anything it's touching. You also don't want two colors to fight for attention regardless of how far they are from each other. Lily(right) has red as the most saturated and dominant color. Originally the blues would clash with the red because they were just as bright, so I desaturated them in the second version.

The final phase is the "render," where the lights and shadows are applied.

When I'm working on a full piece, I have a dozen or so different layers full of colors and fx. However when I'm making a sprite I want to keep things simple as I have to move the sprites around a lot, so in total there are only 3 layers used for each sprite (rough layers are not counted): the outline, the color, and the shade layers.

You generally want the lighting to come from just above the camera, but it's not a bad idea to put it at a slight angle. The Crown sprites are designed to have the lighting come from just behind the character.

The first step of rendering is to just draw the shadows. My tool of choice is a custom brush I call "Watercolor Sketch," the settings of which are in the image above. 

The second step is drawing the highlights. I also use the Watercolor Sketch for this, but combined with the "Flat Brush" also shown above.

Overall this phase doesn't take very long. It's usually the shortest as it's the phase that requires the least design work, you're really just improving on the color phase. Keep in mind though that you do at least have to choose colors that look good. Beyond that, rendering is about technique.

Scripting 5: Script: Camera_Control

Camera_Control speaks for itself. It's the camera script.

This is an overview of the Camera_Control Script.

VOID Start()  Only used to set certain variables that can't be set earlier.

VOID Update()  Does everything.

• First InputCheck is called and player data is read.
• playerspeed = player's.hspeed*3+player's.endlessrun.
• hspeed records horizontal speed.
• endlessrun is automatic movement, used in some bossfights.
• playerfall = player's.rigidbody2D.velocity.y;
• holding right adds +1 to the variable "aboutFaceLag." If it's value becomes 100, the camera will now stand to the right side of the player. The opposite is done when holding left.
• This allows you to see ahead of the character, and adds a delay to camera movement when the player is changing directions.
• If playerfall<15(player is not jumping), the camera stands in the default location.
• If playerfall>15(player is jumping), the camera tries to stay still.
• If playerfall<-10(player is falling), the camera attempts to keep you in sight.
• If playerfall<-24(player is in a long fall), the camera tries to get below you.
• Wall climbing
• Reads the player's fspeed, and adjusts to look over or under the player depending which way they're going.
• If you tap left or right, threatTest is called. If an enemy is found within the aimed vicinity, the camera moves slightly to get them into view.
• goingLow is one of many variables used to control the y offset of the camera from the player. If you hold down, goingLow decreases to move the camera lower.
• At this point, custom movements are taken into account. If the camera is moving automatically, most of the above is ignored, and the camera instead moves based on a value.
• The player is not allowed to exit the camera's field of view while it's moving automatically.
• If the camera is moving horizontally, it will attempt to keep a strict y position.
• Rotations are set through a Quaternion.Lerp by 0.01f;
• The field of view and z offset are both set through Mathf.Lerp by 0.02f;
• Earthquaking moves the camera around rapidly for a set amount of time. 
• The camera tests for walls and water.
• If there's a wall overhead, the camera will avoid rising.
• If there's water underneath, the camera will try to stay above it.
• Colorizer: Reads the main light's script and changes the background color accordingly.

At this point the final camera movements are being calculated.

• First the camera's movement is smoothened. 
• playerposSmoother = Vector3.Lerp(location, target, 0.98f);
• startx and starty = playerposSmoother;
• startz = playerposSmoother + zoffset(the default distance the camera should keep);
• The final variable "Target" is now calculated.
• target.x = startx + playerspeed/3(player's running speed) + xoffset(default distance to keep);
• If y can move freely then target.y = starty + yoffset;
• If the camera is too close to the bottom of the level, target.y won't fall below 10;
• If the z position of the camera can move freely, target.z = startz;

Between the first and last calculations, the overrides are set.

• The camera uses a raycast to stay away from walls in order to prevent clipping or xraying.
• A circlecast checks for focusers. 
• If any is found, focusCheck = true; and FindFocus() is called.
• If none is found then focusCheck = false, and the rotation and field of view are reset;

And now the final movements are set.

• moving.x = Mathf.Lerp(current x position,target.x,cameraspd*50*Time.deltatime);
• moving.y = Mathf.Lerp(current y position, target.y, cameraspd*mathf.Abs(currentpos.y-target.y)(changes speed based on distance) * 2.5f * Time.deltaTime);
• moving.z changes similarly to movingx, just slightly slower (30 instead of 50);
• transform.position = moving;
• If the distance is too great or the player dies, the camera snaps to the target via SetCamFast();

 IEnumerator Camflix(float shiftSpeed)  Turns the camera on and off, used after the player dies and during the level's start while things are still loading.

VOID SetCamFast() Quickly resets the camera. 

VOID setFields(int settingT) Changes the field of view between presets. 

VOID ThreatTest() Checks for surrounding enemies. If there is an enemy within a certain location, the camera will move towards it when changing directions. 

VOID FindFocus()  Focuses tell the camera where to go while the player is within its field. Focusers can affect field of view, rotation, and location. 

VOID InputCheck(int whatCheck = 0)  This is a basic input checking function that reads the arrow keys, WASD, joypad, and joystick all at once.

Blog 1: Summer Game Design Ideas Part 1

Summer classes have slowed down progress a bit, so most of the updates for the next few weeks will be scripts. I'm working on the game's graphics in the meantime.

Two events happened last week. The first is SGDQ, and the second is that I got my hands on an android. Both events have been inspiring some new game design ideas, though most of them are not very pertinent to Crown. I'll start with SGDQ, and talk about the Android games in my post 2 weeks from now. I've had SGDQ running in the background while I work on my school and project stuff, here are some of my thoughts.

My favorite run this year was Momodora 4: the commentary was great, the skill displayed was really impressive, the game itself is very high quality, and I got the most from it overall.  I'd love to make a metroidvania game at some point in my life, but I'll need to make sure I have the necessary resources when I try it.
Something more immediate though is a gameplay mechanic the runner described as "last hit forgivance. This means that losing all of your HP won't immediately kill you, but instead grants you one more hit. It hasn't been programmed in yet, but I plan to use it for Crown. I'm a bit wary about adding too many features that make the game easy, but I don't think I've crossed the line yet and games should support the player before the difficulty.
The Dark Souls-esque rolling ability also made me rethink one of Lily's powers in the game. But I'll explain more about that later on.

My favorite type of runs are the races and my favorite genre is platformers, so my most rewatched runs were the DKC Tropical Freeze and Super Mario Maker races. Both games showed off pretty good auto scrolling levels, something that will likely be very abundant in Crown as even the first major bossfight in the game is a running boss. The important thing is to keep the gameplay active and fast, something DKC and the Mario Maker speedrun level designers accomplish well.

Ape Escape is one of my all time favorite games, so I'm happy to see it speedran at a gdq event. The floating ability with Spike's slingback shooter reminds me of Razputin from Psychonaut's floating ability, almost tempts me to add dumb little tricks like that in my own games. That's probably not a great idea, but it reminds me how I love messing with cheat codes in games. Though I've already programmed a debug menu in Crown that I plan to make an unlockable feature for the player, so I think I at least have the fun factor that comes with cheating down.

Honorable Mentions: I just don't have much to say about these.

Ty the Tasmanian Tiger: Fun commentary.
New Super Mario Bros 1 and 2: I keep forgetting these games exist.
Kirby & the Amazing Mirror: I've been wanting to see a co-op run of this game.
Ed, Edd, 'n Eddy The Mis-Edventures: Love the show, never seen gameplay of this before.

If you're interested in what I do, here are my other social media pages:

Twitter @Maakole: I tweet whenever I update something here or on my Tumblr.
Tumblr: I made it recently, and don't really plan to use it all that often. But it will showcase art work from my Evanlily game projects, or whatever else I happen to be doing.