Category: Articles

Small update tonight to implement three new boot sockets.  These new sockets allow the player to float in the air after reaching the apex of the jump, if the jump button is still held.  The amount of float time is static (20 frames), and that time is doubled for the Float +2 socket and tripled for the Float + 3 socket.

 

As with the “looking up” and “looking down” states, the floating state does not currently have animation sprites.  Therefore, I just have the word “floating” display on the player for testing purposes.

Floating could have been implemented many ways, but I like booleans so I created an isFloating bool to signify if the player is floating.  I also have an integer tracking the amount of float time.  When the player jumps, if a Float socket is equipped then the float time integer gets set to the number of frames that the player should float based on which Float socket is equipped.  When the player’s jump acceleration reaches zero, then the isFloating value gets set to true if the float counter is greater than zero.  Otherwise, the player will start falling.  On each update, the float counter is decremented until it reaches zero.  At that time, the player will start falling as they normally would after reaching the jump apex, and the isFloating bool gets set to false.  The separate bool and integer variables may be slightly redundant, but I think it makes the code more readable.  A future optimization could be to replace the bool variable with a function that returns true if the float time is greater than zero and false otherwise.

I also slightly modified the crouching code.  If the player is walking and rolls the control stick to the down/forward position, then the player will walk and look down.  From this state, if the player rolls the control stick completely down, then the player would still be looking down and standing (not crouching).  This was to prevent the player from crouching when holding down and forward, when the player should be moving.  In ResistorKit, I only have methods that fire when up, down, left, and right are pressed or released, so the crouching code was only fired when the down and pressed action was fired.  The player is not allowed to crouch if the jumping, falling, or walking states are active.  To fix this, in the code that causes the player to stop walking, I added code to set the player to the crouching state if the player is looking down.  This behavior is slightly different from other classic platformer games that also don’t set the player to crouching when rolling from foward to down, but I feel that my new way feels more natural.  With the old way, the only way to crouch was to press directly down from a standing position which feels clunky.

Floating was a fairly simple mechanic to add in about two hours.  I’m hoping to get back to character modeling, but there is a huge learning curve for me to complete that task.

Found a great video tutorial on modeling a human head in Blender.  First of all it instructs to use a subdivision modifier to make the starting cube a spherical object, with 2 View subdivisions.  Then in edit mode, the proportional editing tool (key “o”) is used with moving vertices to give the object more of an egg shape.

 

Then, half of the head mesh is deleted and the mirror modifier is applied to ensure that the head has a symmetrical shape.  Then the Loop Cut tool is applied twice (Ctrl – R – 2) to add additional vertices and edges around the neck.

 

Finally, more vertices are moved around with proportional editing to give the neck a more realistic shape.  This is just a start, so I’ll have to add the body later in addition to making the face look more like my character design.

I didn’t do any coding tonight, so I worked some on design and conceptual art.  Instead of a development update, I thought I would share the designs that I created from my project notebook since I started working on this project.

I’ll admit that I’m not a great artist, but I think I can do good enough to use as a guide for creating the models for the game.  Below is a sketch that I drew tonight that will be the basis for the main character in the game.  I still haven’t finalized a name for this character.  First of all, I knew that I wanted the character to look humanoid, so I used that as a starting point.  The coat is long which almost looks like a cape at the bottom.  I may end up removing this due to the difficultly (and my inexperience) of rendering loose cloth.  Looking into waving flag models may give me some more insight on how to create that effect.  I always hate the sexism in video games debate, so I gave the hero a helmet which allows the player to imagine the hero as a man, woman, alien, or whatever.

The next image contains the notes I made while creating the socket system.  This isn’t inclusive of all of the abilities, but it gave me a starting point on how implement the system.  It’s really helpful to start on paper, that way I can mark out, erase, and add abilities as I get new ideas.

The level editor was and is still fairly simplistic in design.  I will need to modify this design some to handle the location of new rooms.  I’m thinking about letting the left thumbstick control movement on the room grid, and letting the D-pad move between rooms.  If the user uses the D-pad to move to a room that doesn’t exist, then it will prompt the user to create a new room.  There will also need to be some work on how to connect a door from one level to another level.  For now, I’m thinking about just having one exit for each level to keep it simple.  However, I want to make it so that there are a variety of conditions for unlocking the door.  Currently, the player just has to defeat all of the enemies to unlock the door.

Below is the original story concept.  Again, I marked out and revised portions to make the story more interesting.

The most difficult part of coding this game so far has between switching between rooms.  I could have used a standard tile editor to create the worlds, but those make the game world very limited.  My room approach allows continuous scrolling to loop around on a level.  Additionally, it also allows the possibility of moving vertically and horizontally between rooms at the same time without a break.  Most platformers only scroll horizontally or vertically, which requires a break (such as a door) to change the scroll orientation.  Also pictured is one of my notes I made when trying to figure out how to handle placement after collision with a block.

 

I haven’t started creating the game overworld yet, and that may be left out.  Below is some simple notes I made for the overworld, which would allow the player to take multiple paths to complete the game.  Each level would be a different part of the computer world, which would use real computer hardware and software concepts.  Also included are some of the original abilities that I had planned for the game.  The last image shows some of the original level design, but this may change significantly if I scrap the two separate zero and one guns.

 

 

I haven’t done much enemy AI programming yet, but I did jot down some simple enemy behaviors as shown below.

 

Below is a puzzle that I thought about including, which would require the player to shoot letter blocks based on the ASCII character code.  Other puzzles would require the player to shoot switches based on the RGB values.  I think these puzzles would be educational, but maybe to difficult or confusing for most players.

 

Lastly, this is an image of the original design that I created for the game.  Almost all of this will be left on the cutting room floor, but I may use some of the binary concepts as puzzles or a minigame.