Third Meeting - Designing Player Movement

For our third meeting, we sat down with the goal to design and program the player movement.  We completed this task in 4.5 hours.

Player Scale

Chris started the meeting by whiteboarding the size of the character and the jump-height relative to the screen.

Player Movements

Chris then described the following movement states for the character:

• Idle
• Walk
• Jump
• Double Jump
• Attack (Ground)
• Attack (Air)

Player Attacks

When the player attacks on the ground, they are frozen in place while an animation plays out, creating a hit box in front of the player in that duration.

When the player attacks in the air, they go into a dive sequence.  At the beginning of this sequence, the player is given a slight upward impulse, then is given a downward acceleration faster than gravity.  The sequence naturally ends when the player hits the ground.  But the dive can be canceled by hitting attack, allowing for a double jump or another attack.  Attacks can be chained through activation/canceling for versatile air movement.

Player State Transitions

We needed to know exactly how the player will transition between these movements.  So we created a state diagram with the following states and their respective possible transitions to other states.

• Idle State
• (left or right keys) > Walk State
• (jump key) >  Single Jump State
• (attack key) > Ground Attack State
• (floor vanishes) > Single Jump State
• Walk State
• (left and right keys released) > Idle State
• (attack key) > Ground Attack State
• (jump key) > Single Jump State
• (walk off cliff) > Single Jump State
• Ground Attack State
• (attack completed) > Idle State
• (floor vanishes) > Single Jump State
• Single Jump State
• (standing) > Idle State
• (jump key) > Double Jump State
• (attack key) > Single Jump Dive State
• Double Jump State
• (standing) > Idle State
• (attack key) > Double Jump Dive State
• Single Jump Dive State
• (jump key) > Double Jump State
• (standing) > Idle State
• (attack key) > Single Jump State
• Double Jump Dive State
• (standing) > Idle State
• (attack key) > Double Jump State

Starting with the "JumpNRun" example

The ImpactJS engine comes with a simple "JumpNRun" example project, which is a simplified version of Biolab Disaster (closed source).  We decided to implement our state machine on top of the JumpNRun code base for testing and to dump the important parts into our own project later.

The current "player" entity in this project has no existing state machine and has the following physics:

• Fixed jump height (set velocity at jump)
• Constant ground and air acceleration
• Movement friction
• Max horizontal and vertical velocities

Modifying the Jump

In standard platformers, you can jump higher as you hold the jump key and stop jumping by releasing the jump key.  This was the first modification we made to the jump behavior.



(animated gif)

We also wanted it to be easy to change horizontal direction while in the air.

(animated gif)

Adding Double J

(to be continued)

Second Meeting - Code Setup

For our second meeting, we sat down with the goal to setup our environment, and to get a square moving on the screen.  We were successful after 3 hours of work.  Here's what we did.

Purchasing Engine Licenses

First, each of us purchased an ImpactJS license for $100 and we were emailed the download links to the engine with different example games for reference.

Familiarity with the Engine Directory

The engine download did not come with an installer.  Rather, it was a simple zip file containing the source code for a simple game test example, the engine source code, and the level editor source code.

• lib/
• game/ <-- game code (with "hello world" currently)
• impact/  <-- engine code
• weltmeister/ <-- level editor code
• media/ <-- game asset files
• tools/ <-- "bake" tool that compresses the game code for distribution
• index.html <-- runs the game
• weltmeister.html <-- runs the level editor

Creating a workflow to run the game

Both the game and the level editor are web applications, meaning they are run in the web browser rather than as native executables.  We could run the test game by just opening "index.html" in a browser, but the level editor "weltmeister.html" did not work.  This is because the directory needs to be presented by a web server with PHP enabled, since the level editor is doing dynamic server side things like polling for and saving files to our directory.

Thanks to this post in the Impact forum, we learned that we didn't have to install a full LAMP web server stack for our workflow.  So, on the Windows side, we downloaded PHP 5.4, extracted it to some folder, added that location to the PATH variable, and created a "runserver.bat" script with the following line:

php -S localhost:8000

Whenever we want to start work on the game, we just open "runserver.bat" and go to "http://localhost:8000" to run our game, and "http://localhost:8000/weltmeister.html" to run the level editor.

On Mac, I just ran "port install php54" and created a "runserver.sh" script to execute the command "php54 -S localhost:8000".

Setting up an Editor

We installed Komodo Edit, then created a project file inside our code directory.  I think if we set this up correctly, we will get auto-completion, but it is not working currently.

Learning the debug pipeline

Debugging has to be done in the browser.  The level editor gives alert boxes on malformed entities.  And the game gives error message in the Console, which has to be enabled in your browser.  We enabled the "Web Console" in Firefox in the developer tools menu.

Setting up Version Control

To backup code, keep track of our changes and to synchronize edits between us, we created a free and private mercurial repository at Bitbucket.  On the Windows side, we installed TortoiseHg to synchronize our code with the repository.

Meeting our Implementation Goal

We drew a simple character with a transparent background in GIMP.  Then we saved it to the media/ folder.  Created an entity for the character in /lib/game/entities, then created a level with "weltmeister" that placed our character in the level.  After debugging, watching tutorials, and comparing with the working examples, we accomplished a first working example.

First Meeting - Planning

Chris and I are working on a Beat Em Up game for the web browser. He proposed the idea by sending me a game design document for it a couple weeks ago.  We've had two meetings since then, and I just got back from our first code sessions, so today is a good day to start our dev blog.

So, Chris is a DigiPen graduate and game industry vet. For posterity, I'm very interested in documenting his battle-tested game development process.  So I would like to write about what we talk about and how we progress.  Here's what we talked about in our first meeting.

Motivation

We decided this was primarily a hobbyist project, and secondarily an experience builder and portfolio piece.

Distribution of Sales

We decided we would split any sales by 50/50, with a contract for art assets.

Choosing a Title

Just call it something for now (Raging Atoms). Design the mechanics of the game, use placeholder art, then allow artist to decide the story, look, and feel for which the title will be based.

Specifying Required Art Assets

When requesting art, decide how many frames, the framerate, and the frame sizes for all the assets we need, then send that spec to the artist to implement in a desired format.

A note about Placeholder Art

As a rule of thumb, placeholder art should be ugly, lest it be shipped. If a developer's motivation relies on a pretty prototype, motivation needs to be found elsewhere.

Choosing an Engine

Need an engine with 2d sprites, alpha-blending, cheap, and works in the web browser, with an added bonus of mobile support for distributing in app stores.  We decided on impact.js due to its popularity, cheap price, good docs.

Goals for first coding session

This will be setup day. Setup environment for the engine so we can start coding, and setup version control to track and synchronize our changes. We will be pair-programming to get a picture moving on the screen with the arrow keys. Some "stretch goals" are to get it working for mobile devices.

Choosing roles

Chris and I are both programmers, but there are higher level roles to be filled. Technical Lead is one who makes decisions about the general architecture of the code base, and other technical things. I wanted Chris to take the lead so I could learn from his arch design. Lead Designer is one who makes decisions on the general design of the gameplay, so I wanted him to take that as well since this design is his idea. I will be taking the Producer role which seems to do everything else by default.