This post is about work on the new multi-player physics based platformer that I'm working on.

I've done a little work on a placeholder GUI. It has changed the original way that I planned on doing the scoring system to allow for bigger comebacks and less chance of feeling like you're being steamrolled with no chance of redemption.

My original plan was to award points for each successful fall with the first player to get to a certain point total being the winner. This doesn't promote the type of risk/reward gameplay that I originally wanted. Instead, for the scoring system, each player will have what looks like a health bar that works in reverse (starts empty and fills up). Whenever a player has a successful fall (and possibly a successful save) they will get a point total based on some variables of the fall( i.e. distance fallen, time fallen, objects collided with). This will create something of a carnage total to the fall. The points gained from the fall will show as a text total and will fill a bar with the percentage of points relative to the total points needed to win a match. The first player to fill the bar is the winner. This means that if you have a playstyle that uses much riskier big point falls, you would have just as much chance at winning as somebody that tried to play it safe with a larger number of easier falls. This also adds a randomness factor that creates tension which is good for competitive gaming.

Placeholder values in the basic GUI

Placeholder values in the basic GUI

The picture above shows the dive state. Currently, the dive is only available if you are on a flat surface. When it was available at any time, it made the player look like they were flying and was ridiculous (more-so than I intend on it being). The player is in the air because the dive was started on the platform to the right. 

The dive state instantly increases the player's movement speed by 50% of their max speed. It locks your movement direction for 1 second before returning to the move state. I did a little tweak on the switch between states to make the transition smoother (it had a stutter that dropped the player's horizontal speed to 0 and made them have to re-accelerate). This allows for a small exploit to avoid friction in a change of direction, but I'm not too concerned about it at the moment. It definitely feels better this way. Much more fluid.

I'm on the fence about messing with the AI yet, as the AI will probably be somewhat level specific and I do not yet have a level that's complete. I also really want to get the camera issues that I was having trouble with resolved before doing too much AI programming. I need to be seeing the game in more of a state that I intend on it being as I work on it. I read some article that recommended that. A dynamic camera is the way I want to go for sure. I just need to figure out how to do it.

Other quick notes. Dess M-8 should have a review on this new app review site that is making a transition from Japanese to American markets. We'll see how that goes.
The podcast that I recorded is being pushed back due to some recording technical difficulties that the host experienced. He's going to have to re-record his side again. Bummerino.
Thursday is Indienomicon. I'm going to do a couple test runs of the presentation before then. Hopefully people like it. I should have a video of it available soon after.

I'm off to enjoy my Memorial Day off of work.

Until next time.


Time Spent Since Last Post: > 3.5 hours.