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.

Beast World: Base Model Creation Recordings

Part 1: Modeling

Part 2: Textures

Part 3: Armature

Part 4: Rigging

Part 5: With Commentary

Part 6: Face Rig

Part 7: Final Rigging

Part 8: Idle Animation

Part 9, Final: Running Animation

Part +1: Jumping Animation

Part +2: Wall & Water Animations

Blog 8: Final Blog

Writing so many blogs for the past few months have made me realize, this whole thing needs a remodeling. I already have Tumblr and Twitter to update, adding this page to my schedule is kind of counter-intuitive. So instead of updating every Monday, I'll be updating whenever I feel like it. This "blog" will instead be converted to an information HUB for my games, which means I'll be changing a few things this week. In particular I'll be updating the Beast World page with new info, probably on Thursday.

Blog 7: Gotta work on art

 

 I released 2 gameplay videos last week. This week and next I'm going to focus on improving the graphics, and that means I will not be as active online for some time. I can just barely record myself playing this game, so my computer is not fast enough for me to record myself drawing. I may also not be able to record gameplay footage anymore once the graphics have been improved, I can't even record at full quality right now. I'll probably have to ask someone to do that for me.

Blog 6: Stalling

  

  I don't have much to show this week, I should have prepared something ahead of time to use as stalling material. For this week though I'm continuing to update the Base Model videos, and I guess I'll put them over this page again.

  At this point the game is very close to being at a state where I want to show it off, but it still needs a bit of polish. Classes were tough last week so I didn't have much time to work on it, but I'm optimistic for this week. I want to finish the climbing and ledge grabbing mechanics, and at least start on either Dallas' or Dahlia's model.

  I'm also now thinking about writing down the game's story and "publishing" it on here too. I know at least one person who'd be interested in knowing Evanlily's story, so I guess I'll start writing it up between classes.

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.

Blog 5: Tank Top Venus

I'm gonna start making these blog posts a little bit shorter from now on.

My submission to the Lewd Jam, Tank Top Venus, was released a few days ago. Play it here (NSFW warning) if you like. The game is unfinished and very glitchy, as usual, but I'm impressed with my first attempt at a 3D game. I'm positive the next one is gonna be 100x better.
Here's a speedrun of the game. It takes less than 3 minutes to complete.

Here are some sketches of the main character, I had uploaded these to my Tumblr account while I was working on the game. The clothes and body were finalized before the hair. From the start I had the idea to remove the enemy's clothing as the "lewd" theme, but before the main character was a succubus he was going to be some sort of love god. I chose to go with a female main character instead, entirely because I had the idea of having the main character's clothing also come off as a means of telling the player how much HP they had left.

The hardest part of making the game was programming something that didn't even end up in the final build. That is the ability to kick one enemy into another. The code is still in the game, and you can still do that, it's just that enemies won't be hurt from it. Essentially, the kicking move in the game first activates a large sphere collider to find an enemy, it's location based on your position and input. After it finds the first enemy, the camera creates a capsule cast in front of itself to find all enemies in view. After which, a ray chooses the enemies closest to the camera's reticle, and finally the kicked enemy is sent off towards it.

I need to plan out my ideas better. I wasted too much time on something I decided to not even use in the end. I didn't even know what kind of gameplay it would have until a few days after the Jam officially started. (I began working before the Jam start, which wasn't against the rules this time). The game's final boss was programmed within the last 3 days of the Jam. Even worse every single level, menu, and level asset was created on the very last day of the Jam.
It was a fun time, but more important is how much better my next project is going to be. To get the info on my new games when they're released, follow me on either Twitter or Itch.io.

Art 3: Base Game Model Recording

For this week's update I recorded myself creating a 3D model that I plan to use in a future project.
At this point in time I was still working on Tank Top Venus, now available to play here.

Regarding the video. I got a bit experimental in a few segments, so it's by no means a speed modeling video. The model being created is meant to be used as a base for other human characters in the game, so its main purpose is flexibility. I chose a female form for the fact that it is easier to transition it into a male form rather than vice versa. Removing features is easier than adding them on.

The model was made using Blender. The main tools I used were: Extrude (E), Fill (F), merge (W/ alt+M), and wide select (C). The initial cube already has a mirror modifier applied to it, as that is the default scene I have set up for myself. For a more detailed explanation of Blender's main tools, I made this video a long time ago explaining them.

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.

Scripting 6: Script: 3D_Movement

I've been working on a 3D game recently for Itch.io's Lewd Jam. So here's the Movement script I made, keep in mind that it's my first time scripting for 3D movement. As usual, this is a C# script written in Unity.

There are 25 total variables, 20 of which are public variables. Movement scripts are central, so this amount is pretty normal as a lot of other scripts have to reference this one. 

Movement

    void Start(): Only used to set a few variables

• LookDir: References the CamReffer object's transform component. CamReffer is an object that mirrors the camera's rotation, but ignores the x rotation.
• SuCont: References the player object's CharacterController component. This was my first time using this component instead of Rigidbody. I hear there's a lot of benefits to it, but there are some limits that will keep me from using it more in the future, such as being unable to rotate the object's colliders.
• animRef: References modelRef's Animator_Controller component.
• modelRef is a public variable that has to be set from the Inspector. It references the object's model, which is parented to this object. As it can have multiple names, I have yet to figure out a way to automate this.
• camRef: References the camera's parent object  "Camera_Control."
• The camera in this game is parented to the Camera_Control object, which sticks right to the player. 

    void FixedUpdate(): Only being used for collision checking.
groundCheck = Physics.Raycast(transform.position,Vector3.down,0.05f,1<<0);

    void Update(): Handles the meat of the functions.

• if(para>0)para+=-1 * Time.deltaTime * Master_Script.gameSpeedTimer; else para=0;  
• Counts down "para." I usually include countdowns in FixedUpdate for accuracy, but I need variables in this game to be manipulated by MasterScript's gameSpeedTimer variable, which is used to control time.
• Master_Script.gameSpeedTimer controls the speed of the game. Each variable multiplied by this is affected by the time control feature.
• setLookDir(); is called early on to easily reference the Camera_Control's rotation.
• movementSpeed.y = 0; so that the movementSpeed Vector3 doesn't control your vertical velocity.
• if((lookDir.rotation * movementSpeed).sqrMagnitude>maxspeed*10)movementSpeed*=0.95f;
• This is the speed limiter. If the magnitude of your horizontal movement is greater than the allowed maxspeed, it gets pulled back down by simple multiplication.

//While in the Air
if(!groundCheck)

• animRef.SetBool("OnGround", false); Tells the animator that you're in the air.
• if  (!antigrav) jumpSpeed =  Mathf.Lerp(jumpSpeed,gravityset,0.01f * Master_Script.gameSpeedTimer); 
• This part controls your falling speed. As long as the antigrav variable is turned off, you fall. Some in-game abilities stop your falling, in which case this line is ignored and you will freeze in midair.
• accelspd = acceleration/50f; accelspd is the active acceleration used for horizontal movement, while acceleration is the character's base acceleration. These two variables are separated for flexibility, such as with this line which is meant to lower your acceleration in midair.

else (groundCheck finds ground underneath you)

• if(jumpSpeed<0) animRef is told that you've landed on the ground through the "LandTrigger."
• animRef is also told that you are on the ground constantly through the "OnGround" bool.
• jumpSpeed is now set to 0 if you're still falling, this ensures the landing trigger only happens once.
• if(actionMov) toggles wether or not you're holding the shift key.
• If on, the animator is told and the acceleration and maxspeed are lowered.
• If off, the speed variables accelspd and maxspeed are set higher.
• Finally, doubleJumps are reset while you're on the ground.

//Animation variables.

• It is at this point that the animator is given the movementSpeed and jumpSpeed floats. Horizontal movement is multiplied by the gameSpeedTimer, vertical movement isn't.
• if(movementSpeed.magnitude ==  0 && jumpSpeed ==0) if you're not moving at all.
• idleChecks = Random.Range(0, 800); This variable chooses a random number.
• Now the animator is told what number idleChecks chooses. The animator knows to play a random idle animation based on which number pops up.

//Final Speed Settings.

• tYMove = Vector3.up * jumpSpeed * 10; this is the final vertical movement.
• finalSpeed = (movementSpeed * Time.deltaTime) + tyMove/20); 
• This is the final movement calculation. Horizontal and vertical movements are separated so they don't affect each other.
• SuCont.Move(finalSpeed * Master_Script.gameSpeedTimer); 
• This is the final movement, which fed to the object's Character_Controller. finalSpeed is multipled by the gameSpeedTimer so that everything can be controlled by the time controlling function.

//Final Rotations.

• If you're moving, lookRotation = Quaternion.LookRotation(movementSpeed, lookDir.up); creates a new rotation which looks towards whichever direction you're running in.
• Then, as long as the character isn't stunned for any reason, the model is rotated with:
• Quaternion.Lerp(model's rotation, lookRotation, 0.2f * the gameSpeedTimer);

    Public Void mover(int Direct = 0) function adds speed depending on what button is held.

• setLookDir(); is called first to ensure the rotation is as accurate as possible.
• Switch (Direct). Depending on the Direct variable's value, movement is added.
• If Direct = anywhere between 1 and 4, movementSpeed += lookDir.(right or forward) * (-)accelspd; adds speed to whatever direction is pressed.

    public IEnumerator jumper( int powerdivider = 100, float timeHalt = 0)

• The animator is told immediately that the "JumpTrigger" should become active.
• jumpSpeed = 0; to stop vertical momentum.
• antigrav = true; to halt vertical descent.
• yield return new WaitForSeconds(timeHalt * Master_Script.gameSpeedTimer); freezes the coroutine for however long it should, most of the time is ignored as timeHalt is set to 0 by default. This was originally added in for wing flapping, but is right now being considered for removal.
• antigrav = false; can now fall.
• jumpSpeed = ((jumpower * 10f)/powerdivider)/10f * ((Master_Script.gameSpeedTimer/15)+1);
• Sets the jumping movement. It's a little convoluted, but anything out of the ordinary was put there to regulate for either the time controlling variable or varied jump heights.
• sideWaysRot = Vector3.zero; resets the rotation variable.

Void setLookDir()

• lookDir.rotation = camRef.transform.rotation; tells lookDir to copy the camera.
• lookDir.Rotate(-lookDir.eulerAngles.x + sidewaysRot.x, 0, sidewaysRot.z);
• Reverses the x rotation, so that the camera's up and down angle don't affect motion.
• Leaves the y rotation alone, this is what we wanted the most.
• Adds the rotation variable sideWaysRot to LookDir's x and z rotations.

    public IEnumerator rotateToCam(int angleOffX = 0, int angleOffZ = 1, float timeset = 0.1f) This function rotates the model based on the camera's rotation.

• setLookDir();
• Vector3 tAngle = Vector3.zero;
• tAngle += lookDir.right * angleOffX;
• tAngle += lookDir.forward * angleOffZ;
• These 3 functions create a new Euler Angle by using the camera's rotation as a base.
• if(tAngle.magnitude != 0) lookRotation = Quaternion.LookRotation(tAngle.normalized , lookDir.up);
• if the desired Euler Angle exists, it is converted to the Quaternion LookRotation.
• int t = 0;
• while(t<10)
• modelRef.transform.rotation = Quaternion.Lerp(modelRef.transform.rotation,lookRotation,0.1f * Master_Script.gameSpeedTimer); 
• t++; 
• yield return new WaitForSeconds(timeset);
• All this basically just turns the model 10 times towards the desired angle.

And that's the 3D_Movement script. You'll notice mover() and jumper() aren't called. That's because the actual button presses are handled by a different script, so that the Movement script can be used for enemies as well as the player character. The second script will now be explained below, as originally I used these functions alongside the Movement script.

Player_Control

void Start()

• playRef = this.gameObject;
• movRef = playRef.GetComponent<Movement>();
• References to the player object and Movement script are made.

void Update()
if(!Master_Script.ispaused && para==0) everything under Update only works if the game isn't paused and the character isn't stunned.

• If the character isn't already moving at maxspeed or you're in the air, and you're not stunned, the mover variables are called through movRef.mover(1-4);

//Slowing Down

• For both horizontal and vertical movement, if there are not buttons being pressed the movementspeed of either direction is Lerped down to 0.
• movRef.actionMov is set to wether or not you're holding down the shift key.

//Jumping

• If you're in the air and holding down the jump key, and you have available doubleJumps and are past a certain falling speed:
• movRef.StartCoroutine(movRef.jumper(120)); you flap your wings.
• movRef.doubleJumps+=-1;
• If you are on the ground && tap the jump key, you jump.
• movRef.StartCoroutine(movRef.jumper()); 

And that's the Player_Conrol script. I've been having a good time working on this new project in the past week and 1/2, and I should have something to show for it very soon. 

Blog 4: Ludum Dare

I finally have a chance to relax now that the internet's biggest game jam has ended. It was tiring work, and the end result is still very unfinished, but I know each of us feels prideful in our work. I'm going to be writing a little bit about my experiences here. This project was my first "finished" game project, my first Ludum Dare game, and my first time leading a group project. It was also my first time getting headaches, chest aches, and stomach aches all at the same time.

If you're on Windows you can download the game here, or play the web version here. If you don't see 3 vines on the downloadable version, try a different resolution. Something 16:9.

The planning was not very good, and in the end it turned into a real rush job. After the initial time limit, it turns out that Ludum Dare gives you an extra hour to submit your entries. We weren't able to take advantage of the extra time however, so we just barely managed to finish and turn it in. We'll probably be fixing the game up at a future time, but for now we'll just leave it as is.

It was a 4 person team of me, Kino, Skewer, and Omoroi. Since it was my decision to take part in the Ludum Dare, I was manager. I basically acted as leader and filled in whatever roll was missing. Kino was the lead programmer, he put together the platformer logic that let me edit the scripts later on to fit the vision. Pineappleskewer was the lead artist, she drew the idle enemy sprites as well as the background and splash art. And Omoroi was the advisor who helped in planning and scheduling. It was thanks to everyone's hard work that we were able to finish the game at all. After we were finished, everyone was excited to get to work on a new game jam project. Our first jam didn't go very smoothly at all, but the experience will be invaluable to us in the future.

As time went on I grew more and more impatient, and I know the rest of the team noticed. In my defense, I had spent over 12 hours animating sprites at this point (I find pixel art frustrating to make),  and took a very quick tutorial on using Git in order to help with the scripting. Not to mention the entire time we were a day behind schedule. Those three days were so stressful that some of us had practically spent the entire next day just sleeping. Forgive me if I vent a little even while I'm writing this.

This Ludum Dare's theme was "Ancient Technology." The first idea was to use caveman tech, where inspiration was taken from these videos, but that didn't stick. We started tossing around concepts, and eventually the idea just came to me: "You're a cowboy with a revolver that somehow goes back in time. You shoot a guy, and now everyone worships you, but things start going wrong. You only have 5 bullets, and you need to help your worshippers win a war." Later on I began putting more emphasis on jumping on enemies, but Skewer suggested a whip which led to what we have now. The end result ended up more like a puzzle game crossed between Indiana Jones and Castlevania. Though the revolver idea didn't get implemented the name still references his gun, it's also a reference to Chrono Trigger.

What I learned:

We didn't plan very well at all. Some group members had other things going on during those 3 days that we couldn't plan ahead for. There was also too much put into the graphical work. My time was basically split 50/50 as I spent the entire first day animating the cowboy, half of the second day creating objects and animating enemies, and half the second and all of the third day was spent scripting and exporting. We could have fixed up all the glitches if I focused more on the programming, or maybe even have implemented more than one level. That's the point of a first outing though, I'll know more on the second attempt. Overall I'm happy with Time Trigger as a concept, and hope to continue work on it when I have more free time.

This last image works pretty much as a guide to the level. It was created to act as our final piece of concept art, where the idea was simply to recreate what was in the image. We succeeded in that, as this image can be used as a guide for completing the game.

Art 2: Pixel Art Method

My Pixel Spriting method is very similar to my HD Spriting method, but with more steps.
As a disclaimer, I have to mention that I am not a professional pixel artists, and personally find HD Spriting easier. If you want to see tutorials made by more experienced pixel artists, try The Pixel Joint or 2DWillNeverDie.
Pixel Art is both a different medium and technique from Traditional Art, so try both and find which one you prefer.

The steps in Pixel Spriting and HD Spriting are very similar: first is the Rough. In some cases the initial rough is so messy that I'm still not sure what to do with it, so I create a second one over that. For me this occurs much more often when working in Pixel Art.
As you can see, the initial rough is "messy" while the second is "nude." It's more important to make progress at this stage over any other, as you are trying to build your foundation here.
In Lily's case I used a larger drawing as my rough. I don't recommend doing this, as the larger drawing will be difficult to see when scaled down. I was creating very large sprites so it was an effective method in my case, but this will not work for most pixel sprites.

The next step is outlining. I find this much more tedious to do in Pixel Art, as you don't have as much freedom and each pixel needs to be carefully placed. When you're animating you want to work mainly with the outline, but you'll inevitably have to animate using colors too in order to achieve tiny details.
Important to note: while I don't color my outlines in HD Spriting, I do in pixel art. HD sprites get zoomed out often, so their outlines need to be very visible from a distance. Pixel sprites however usually remain at a constant size, so their outline is better off fading into the form.

The final step is rendering. Every pixel is important, and having a single one out of place can change the entire composition. As such coloring, shading, and lighting are all combined into a single phase. Most of the time I render the head before the body just to make sure the skin and hair look good next to each other. The rendering phase in easier to animate for pixel art than traditional animation, so you can go into much more detail here. In some cases you may even need to render as you animate to ensure you get the smaller details.

When animating, I found it much easier to have a worksheet of pieces you can reuse. With the character above as an example: his torso, legs, shoes, tail, and arms were all animated traditionally. His head, hands, and bracelets however were made from recycled pieces so as to quicken the rate of animation. It was especially important for the bracelets, as drawing them was a huge pain in the ass. This is a common trick in pixel spriting, examples of which can even be found in masterpieces like Metal Slug's art, so don't be afraid to take some shortcuts.

Most pixel sprites are around this size, the two sprites on the left were based around the Jump Ultimate Stars style. The sprite on the right is from the Ludum Dare game I am currently working on as of this post being published. The above method works fine for these smaller sprites, but animating the outline becomes more difficult, and you'll find yourself animating the rendering more often (animating the colors instead of the outline). Also, it is more important to use highly contrasting colors with these smaller sprites.
Quick note: As a rule of thumb, running animations for any sort of sprite should be around 6 frames long on average. Use 8 frames only when you really have to, and use 4 frames when you're feeling lazy.

One last quick thing worth talking about is tilesets. In the above example I placed 5 squares in an "n" shape, and drew the tiles over that. This is effective for practically whatever tileset you're trying to make, but keep in mind you'll likely have to work beyond it for any type of sloped flooring. You can also include a second "inside" tile for added detail, or just to settle your OCD over that empty square between the tiles. You can also add a third row above for grass or background tiles.

I'll be very busy for the next few weeks. I'm taking part in the Ludum Dare for the first time, after that I'm joining in the Lewd Jam, and after that my Fall classes start up. Look forward to seeing information on my new projects in future updates, as well as Evanlily Crown.

Blog 3: Mighty No. 9 Review Part 2

Continuing from last week, my review of Mighty No 9.
Part 1 can be found here

Mighty No. 5 Battalion

Level Design

Kind of a bitch. This level wants to frustrate you. Have an enemy that you can't shoot right away standing right in your path. Oh, you found a secret path? Have an unavoidable mine shit on you right at the end of it. There's also one part where you have to jump on a box to shoot a barrel, and the timing's pretty precise. I don't have a big problem with it, there's not a lot of punishment for messing this part up, but it does still end up being an annoying puzzle.

Boss Fight

Sucks. You have to guess at what the boss is doing, as it'll at random perform one of 4 actions: jump, shoot bullets, shoot missiles, or shoot bullets in the air. The best way to fight it is to stay behind it. Also halfway through he shoots a missile out that you just jump over. This essentially limits where you can stand to only half of the arena, as he can detonate this missile at will. Shit boss overall.

Power

Second best power in the game, and the best boss-killer. I used this power exclusively when fighting the final boss. The damage output is great, and being able to detonate it at will is a great bonus.

What I learned

Should be obvious: but don't punish the player for doing a good job, and don't throw in unavoidable obstacles and enemies if they don't have a quick way to avoid or dispose of them. Also, it's important that the bosses have some sort of tell. I kinda just hate RNG in general.

Mighty No. 6 Aviator

Level Design

It's not bad at all, but I think the wind's a bit too strong. This level introduces a really cool idea: the updraft. If you dash in an updraft or use Aviator's power, you go upwards. It doesn't get used much here, but it gets used in the last level.

Boss Fight

It's fine too. Though it's a bit long if you don't have Dynatron's or Battalion's powers. It was a good idea to use the updraft as a way to make it a little easier.

Power

I didn't get to use it much outside of the final level. I assume it's good since it makes you fall slower and gives you a higher jump. It gets used a lot in the final levels of the game.

What I learned

Don't make your wind too strong, unless it's going upwards.

Mighty No. 7 Brandish

Level Design

It's shit. The concept is great, but the execution is terrible. The signs that come at you are annoying, hard to see in the rain, and can catch you off-guard tossing you into the road.. The worst part is the enemies that block the air above you when you don't have any attacks that can reach them. You have to jump and take some damage to take them out, and even then they take multiple shots to kill. I used Seismic's power to rush my way past everything, and it worked out fine. Just make sure to stop using the power when you want to hold unto a ledge.

Boss Fight

It's shit too. Use Seismic's ability to beat him quickly, because it is a frustrating boss otherwise. The cross-slash attack's fine, but every other time he seems to just fight using randomized patterns, with little to no tells.

Power

It's useful in the final level when you're dealing with the xel orb things, as it has a tall hitbox. It also seems to do a bit more damage than your pellets, but the risk is really high as it forces you to get really close to you enemies. Normally I'd take that risk, but not when the enemy stays alive until you dash into it or slash it 3 more times. I think it would have been a better idea to have the sword insta-absorb enemies for you, I'd take that over it being able to deflect bullets.

What I learned

Make your close-range attack worth it, and don't block your player with something they have to struggle to kill (again).

Mighty No. 8 Countershade

Level Design

Varied. Some like it, some hate it. I hate the fact that dying makes you start from the beginning, made even worse when one of the room uses instant-kill electricity. Use Seismic's ability to go through the rooms quickly, but watch out for the UFOs that re-arrage your control scheme for a full 5 seconds.

Boss Fight

Also varied. It can be very long and boring, just like the level, if you don't have the right power. Use anything destructive, like Dynatron or Battalion's powers.

Power

Useless. It's strong against Aviator and the first form of the Robot Factory boss, but otherwise it's just a weak move.

What I learned

Like with Cryo, don't overuse a good gimmick. Learn to tell when the player will get sick of it.

Call's Prison Level

Level Design

Pretty boring, but it is a stealth level. There's also some precision gliding, which can be annoying.

Boss Fight

Cruddy, but nothing major. Duck under the robot's face whenever it begins to shoot at you.

Power

Call's gameplay sucks. Beck gets 3 bullets on screen at a time, Call gets 1. Beck can dash at enemies to kill them quickly, Call has to keep shooting at them with her slow-ass weapon.

What I learned

Stealth levels suck. Alt character gameplay shouldn't feel like a gimp.

Robot Factory

Level Design

Pretty good, it gives good reason to everyone who believes this is the only good level in the game. You have to use multiple powers to complete puzzles, and the atmosphere is great as a few of the Mighty no's fight alongside you. My only complaint is that it doesn't use more than 3 of the powers for puzzle solving, and leans on Aviator's and Battalion's powers a lot.

Boss Fight

I hate it. The first robot seems to be weak to Countershade's power, so snipe at it. The second phase though is a real bitch, as rockets drop down on you while you're on a moving conveyer belt with little time to react. Use Seismic's power to get through that, and the rest should be easy-going.

What I learned

Don't drop missiles on a moving floor. Just more about stacking obstacles on a player, it makes the game's design seem like it was put together by a kindergartener. "My level has one thousand goombas!"

CND 1201 Trinity

Level Design

Not too bad overall. You can get past most of it easily by riding the Seismic power, and the xel orbs aren't too hard to get through with Brandish' power. There are some parts where it's really hard to get through without taking damage, getting through the level is mostly just trial and error. Or maybe it was only trial and error for me because this was the only part of the game I didn't look ahead for.

Boss Fight

I have mixed feelings about the game's final boss. It took me a lot of tries to finally beat this thing my first time. Just use Battalion's power to beat it, you don't need any other power. Niether of these fights is particularly difficult after you know what you're doing, but it will take time to learn.
Phase 1: Rage-inducing, until you get the hang of it. Just spam her face with Battalion's missiles whenever she's vulnerable. The second I saw her shooting pieces of herself out I was worried it would be as long and boring as a Yellow Devil fight, but it's not nearly that bad.
Phase 2: Pretty on-par with the first phase. When she's walking towards you like a Pokey, shoot 3 missiles and then dash through or jump over. When she's spitting out spores take out her base first, then stand on a ledge and spam her with missiles diagonally. When she's shooting her spiraling energy at you just figure it out, there's a moment that you can jump through it. Lastly, remember not to stand in the center as she may appear suddenly from under you.

What I learned

First I'd say not to include a level before the final boss as you have to run through it every time you want to fight it, but that's subjective. Second, the xel orb enemies can be a bit of a bitch for the fact that they immediately respawn when you're a short distance away. That's not bad when you use Brandish's power, but otherwise it can be as you try to dash through an opening only to have it spawn right on top of you. Overall it's not the worst final boss and level.


I beat it on normal mode and tried it on hyper, but I refuse to play through it twice. I'll probably feel a desire to play it again at some point in the future, but I'll try to talk myself out of it. That's my review/ introspective of Mighty No. 9. I give it a 5/10, better than Star Fox Zero. It's not a huge victory, but it's better than nothing.

Blog 3: Mighty No. 9 Review Part 1

I beat Mighty No. 9 recently, and playing it gave me a lot of ideas for my future games. So here's a half-review and half-introspective of the game.
I did not go into the game blind, and I don't recommend anyone try to do that. It's a frustrating game, and knowing what unavoidable traps are about to be thrown in front of you can help in being able to enjoy it. Do not go through the game for your first time with less than 9 lives, go into the options and set your starting lives to 9. Also I played the Wii U version. I heard about the rumors that it could brick your console, but those were just rumors. Presumably though the Wii U version did crash often, which seems to have been patched out.

Disclaimer: This may sound like an angry rant, but I actually enjoyed a few parts of this game. That said, I chose to review this because it is at best a mediocre game, and at worst a frustratingly bad game. Though this review may seem nitpicky, the point is to learn from it My experience wasn't entirely negative though and I think anyone can benefit from playing through this game at least once, as a learning experience. Keep in mind that I also didn't back Mighty No. 9 on Kickstarter, and don't own any of the DLC or backer content. Also worth noting is that I'm not even a Megaman fan, and have not beaten any Megaman games besides Megaman 2, Megaman & Bass, and Mighty No. 9.
Now I'm going to go through each boss, level, and power up of the game one by one.

Intro Level

Level Design

Fine. It's an alright intro level. The only complaint I have is that it doesn't teach you everything, like how to do diagonal shooting. The skill is pretty useful and should have been mentioned. It's not the most effective intro stage overall, but it's easy enough to get the player used to the game.

Boss Fight

It's good too. It's easy just like the level, and introduces the game well.

Power

Beck's moveset is far below the average Megaman set. Not being able to charge your shots kinda sucks, and having to dash at enemies to kill them sucks a lot. Especially since your shots don't go through enemies without getting a red powerup, so you have to shoot-dash-shoot-dash when you're fighting multiple enemies at once. What's more, a few of the skill are only shown to you through the in-game manual.

What I learned

One big cutscene at the start of the game is preferable to multiple short cutscenes at the start of the first level.

Mighty No. 1 Pyrogen

Level Design

Pretty bad. The first half of the level is just fine, but it turns to utter shit when you get to the falling canisters. This is where you really don't want to go in blind. It's bad enough that the canisters force you to slow down, but for some reason the designers chose to include falling balls of fire that could stun you right into an instant death canister or a pitfall. At least it was a useful lesson to me: do not throw too much at your player at once. If they're already being forced to deal with one instant-death obstacle, don't throw in hundreds of something else that's even more difficult to avoid. I tried to dash through this section using Seismic's power but the lag makes it impossible, at least on the Wii U version. To get through it easily, use Seismic's power for the first half and Aviator's for the second.

Boss Fight

It's below average. Pyrogen's the type of boss that you're supposed to bait, which a lot of blind LPers never seemed to figure out. But it's a tough boss even knowing that, mainly for the fact that the tell isn't very good. You're supposed to predict him based on what he says, but an animation tell would be more effective than the audio tell. As it is now it becomes entirely unpredictable for the few seconds that the character dialogue is up, a fact that will seem very unfair to anyone playing the game on a harder difficulty.

Power

Situational. It's pretty much only good for taking down Cryosphere faster, and killing the tiny robots.

What I learned

Don't throw too much at your player at once. Try to make it kind of obvious that your boss is meant to be baited, apparently not a lot of players figure it out easily. I think the best way to do this is by giving the boss two baiting moves. One that can be avoided if you fail to bait it out, and one that can't. Also make sure the boss' tells can't be obstructed by dumb things, like dialogue.

Mighty No. 2 Cryosphere

Level Design

The level is not particularly bad. You can skip over some parts just by dashing, and it has the same problem every level has of there being too many instant-death obstacles all over the place. Otherwise, it's an averagely designed level. Not being able to grab ledges and slipping is a bit annoying, but that's expected of an ice level. The one thing I do hate though is the pong boss fight. It's a clever idea, but it should have only been used once.

Boss Fight

Cryo is extremely frustrating if you fight her without Pyrogen's power. Otherwise though it's not a big deal, just charge up when she's unreachable and explode when she creates her tow of ice. It paralyzes her and you can shoot her dead.

Power

100% useless. There's no reason to use it over the regular pellets, especially when you can shoot diagonally. If you don't know how to do that look at the game manual, as the game doesn't tell you how to do it directly. By default on the Wii U, it's ZR+Y.

What I learned

Don't overuse gimmicks, getting frozen is annoying, and slippery ice levels are annoying. Also, bosses that heal are annoying. If you don't absorb Cryo while she's on the ground, she'll heal up while out of your reach.

Mighty No. 3 Dynatron

Level Design

Cruddy. I didn't have any problem with the level, but I knew what was coming ahead of time. The tiny robots are annoying if you don't have a power that can take them out quickly, Pyrogen's should work just fine here. The purple buzzsaws also gave a lot of people trouble, but if you know they're coming you can get through it pretty quickly. Just run through and crouch-dash with good timing. Overall this becomes the easiest level once you get a hold of it.

Boss Fight

I hate it. Apparently I had more trouble with it than anyone else who I watched play the game. If you get Brandish's power first though it becomes a cakewalk.

Power

Situational. I tried using it on a few bosses, but it just gets outclassed by Battalion's power.

What I learned

Don't overuse your gimmicks. I always think to myself that gimmicks should be used to their full extent, but some gimmicks are just meant to only be seen once, usually bossfight gimmicks. Even more important than that though, don't include instant-death on obstacles with precision timing. Especially if your game has long load times.

Mighty No. 4 Seismic

Level Design

I hate it, everyone hates it, too much instant death everywhere. The worst part is the silverfish robots that hide inside boxes. They get in your way while the drill is chasing you, and unless you know where they appear they'll always get the jump on you. There is a lot of talking too, which is a terrible idea when you're trying to descend in a level. Yeah, go ahead and cover up where the spikes are with your dialogue box. Also, this level is one of the laggiest in the game. The frame drops are so bad that you could end up teleported right into the electric spikes.

Boss Fight

It's good, I liked this boss. The drill attack was annoying at first, but you can get the hang of it after a few attempts.

Power

Wheel Kirby is the best power in the game. If this game gets speedran, this will be the power they go after first. You get semi-invincibility, and you can pretty much just plow through a lot of stages. Get this power early on. At first it's annoying that you always bounce off walls and enemies you run into, but it's easy to get used to that thanks to your dash.

What I learned

Keep your auto-scrolling level's speed reasonable. Don't just throw everything in front of the player if you're going to rush them. Especially don't use puzzle elements, precision platforming, and surprise silverfish enemies when your player is already freaking out about the giant electric drill chasing them. Lastly dialogue boxes should never impede the gameplay, that's just common sense.


That's the first half of the game. In case anyone is actually taking this advice, here's my suggested order for fighting the bosses: 4 Seismic, 5 Battalion, 6 Aviator, 7 Brandish, 1 Pyrogen, 2 Cryosphere, 3 Dynatron, 8 Countershade.

Part 2 of this review can be found here.
Lastly, here's a video Game Soup made last week about Mighty No. 9. Their criticisms are pretty similar to mine so I felt like linking it, enjoy. https://www.youtube.com/watch?v=Ohb8RdPsm3U

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.