Puzzle RPG

Today is an official slacker day, plus I have a Superbowl party to go to so I'm only spending a couple of hours today to start the overall design of my February project.

The concept is similar to Puzzle Quest but instead of a match 3 game I'm going to try a game where you match the corners of boxes, where each box has up to 4 different corner types.

The reason I'm going to try a different mechanic is that the market is flooded with match 3 type games and I'm looking for something with similar properties but a bit less mindless. I understand the value of a mindless distraction but I'm hoping my solution will raise the bar a tiny notch but still qualify as a very low cognitive load while playing.

While the idea is to have a large game with multiple characters, online play, character persistence and in game purchases this months effort is focused on the actual match game. I'm simply trying to get blocks to populate a field of play, and an algorithm to match the corners and tally the "score" which will consist of how many of each type of symbols did you match.

Later, symbols will be spent to trigger abilities that effect either the board, a specific block, the player, or the player's enemy.

Each symbol will correlate with a role and each characters will have a distribution of what role he or she plays.

The roles and symbols are:


Role  -  Symbol

Tank          - Shield
Controller  - Star
Nuker        - Sword
Healer       -  Cross


Classes

There are different classes and they basically denote how much health per level the character will have and what type of roles they fill.

Some example classes:

Guardian - high natural health, always has 2 tank abilities and 1 control ability.

Mage - low natural health, always has two nuke abilities and 1 control ability.

Assassin - medium natural health, always has three nuke abilities

An example character would be:

Name: Zenos
Class: Guardian
Health: 100 per level

Abilities:

Parry(shield ability)
Use Cost: 5 shield
Effect: The guardian deflects incoming damage aimed at any party member, damage deflected is 10% of the guardian's current health.

Unbeatable(shield ability)
Use Cost: 10 shield
Effect: increases the guardian's maximum health by 10%, stacks up to 3 times.

Taunt:(star ability)
Use Cost: 5 star
Effect: the next enemy attack targets the tank no matter who is targeted.

Shield Wall(passive ability)
Use Cost: none
Effect: Reduces the damage dealt to party members by 15% as long as the guardian lives

Unstoppable(passive ability)
Use Cost: 0
Effect: the Guardian is immune to stuns


As a character levels he gains access to more ability slots.
The above character would start with one slot(probably parry).
Abilities drop from completing events or a player can purchase a number of ability rolls.
Max level is determined by the number of abilities a character has. So you need to farm abilities to level your character up.


Ok, back to reality:

The playing field is an N x N array of cubes. Each cube has 4 corners with a symbol on each corner. You score symbols by matching them with an adjacent corner of another cube. If each corner of the cube is matched at least once then the cube explodes and awards double symbols.

If one corner has 4 matching cubes then all 4 cubes from that corner explode, awarding double points for each symbol.

The corner matching and moving and populating part is what I'm going to tackle for February. I'll have to build it to a "save point" per the concept outlined by the 1 Game A Month Challenge, and perhaps spend additional months on it if I'm enjoying the game.

S.O.B.A. 1.0

Sweet success! With roughly 0 days to go I've wrapped up the 1.0 version of S.O.B.A. It used to stand for:

Single-Player
Offline
Battle
Arena

but I should change the name to Son Of a Bitch Arena.

Definitely an ambitious goal set, but in this case, goal set, goal met. It's a big step up from my last month project. The code is a bit cleaner, the scope of the game is quite a bit larger, the production value is a bit better, even though it could stand a month of just polish and be better for it.

Enough chat, here is a 10 minute playthrough.

I'm going to enjoy a couple of well earned days of slacking and then it's on to the February challenge. For February I'm going to do a puzzle-quest style game, hopefully with some RPG elements. I'm not going to push myself as hard as I did on this one. I want to be more disciplined with the scope and try and get a more polished game out.

5 Days Remaining - 6 Days of work left

The ambition of this project given the deadline is wearing me thin. I spent another 12 hours yesterday and still have a long way to go.

This is going to come down to the wire.

I'm getting close to being feature complete. The remaining features I have read like this:

Sound and Music
Finish Game State Manager
Add a Third AI State, some type of defense to mitigate the kamikaze-style AI I have now.
Implement the ability to replay a match.

The bug list, however, is growing:

Bots respawn when they shoouldn't or respawn multiple times.
Player respawns when he shouldn't or respawn multiple times.
Bots don't always face their target and sometimes get stuck looking at a dead target.
Bot's and Creeps sometimes get stuck running but never attack their target.

75% through the deadline, 75-ish % done

One week to go and I'm roughly on schedule. I spent the night putting some cheap art in(cheap as in price, no offense to the artist)

None of it is exactly what I want but it always amazes me how big a difference even decent placeholder art makes.

From a code standpoint I corrected the healthbars that follow the actors around. Now they're green if the actor is on your team and red otherwise. A very simple feedback mechanism but it was a soup without it. You couldn't quite tell what to click on.

I also got the player death and respawn part in.

Must DO

Next up is the Bot respawn and then a lot of GUI work.

I need a health and mana bar on the HUD for the player.
I need an opening screen.
I need a victory or defeat screen.
I need sound effects and music.

I can call it a game after that.

Nice to Haves

The nice to haves list is crazy but there are a few I may be able to get.

The major one is a couple of skills to cast so the mana bar is for more than show.

I'd love some type of experience concept so I can start the player out weaker and then give him more punch and health as he levels.

I'd like to give the player and bots some effects that follow them around, they're hard to pick out from the creeps right now.

I'd like to incorporate an attack attack on the player so you don't have to pick out individual creeps each time. This is a creature comfort on DOTA2 and I miss it when playing my game.

I plan on buying an effect library and juicing up the special effects because they're really rough.

Lots more to be honest.

I've been really tempted to spend a second month on this game and the format for the 1 game a month challenge allows it but this will only be my second game I've finished in Unity...

In order to give myself permission to do that I feel like I need to do a different game in February, and then if I still feel like coming back to this one in March I can do it with a clear conscious and a good sense of purpose.

Having to trick and negotiate with yourself to be prolific is a beating but is a beating worth taking for the end result.

Enemy AI

I've wrestled with how I'm going to implement the AI for the bot players for several days. I've studied Behavior Trees, Goal Oriented Action Planners, Simple Hierarchical Finite State Machines, and Hierarchical Task Networks.

I've varied from one to the next, always circling around Behavior Trees as my most likely implementation. Then something interesting happened. I remembered what my actual goal was. I have to finish an ambitious game design inside of 30 days and I'm more than halfway through my deadline.

I pulled out the razor and cut my ambition in half and the scope of my game AI into thirds. This game doesn't have to be a world beater, it has to be finished in 13 days. Having made my decision,(I'm going with old fashioned Finite State Machines, they don't scale for crap and the implementation is almost guaranteed to be sloppy, but I understand them and can code them up quickly.) I'm breathing a sigh of relief.

I thought about all of the half finished projects on my hard drive and all of the excitement of exploring new concepts and new technologies. The truth is I can explore those parts of programming at will. Goal-less, ill-formed dalliances into whatever catches my eye will always be available to me.

Right now I need to practice finishing. And finishing means not rolling the dice on a technology I'd have to learn from scratch. I've already integrated a new GUI library into this project and it set me back several days. I've overcome that with a lot of hard work and focus but I'm not sure the project can stand another adventure.

With that settled I started rolling the Bot AI this evening. My other work on the creep and tower AI served me well and I knocked out over half of the basic implementation in just a few hours. I'm going to make a bold prediction and state that the Bots in this game are not going to be exceptionally smart.

The first pass, which I'm only halfway through will allow the bots to hunt whatever is nearest them and go back to base to heal when they get below some health threshold. Additionally I'm going to give them access to the node network I built for the creeps and they'll use that to switch lanes if I get that far.

Otherwise they'll just be super tough creeps with some extra will to live and an extra trick up their sleeve. A bit boring, but ultimately achievable.

I still have to implement so many things. Major systems untouched include the entire game state manager, an introduction GUI to start the game, a respawn ability for the players and the bots, sound effects, music, and a victory/defeat screen for the end of the game.

That doesn't even include skinning the game if I get time, animation, a lot of feedback systems that are important to understand the nuances of the game, and the player controller is still the hacky version I rolled initially just to test the game.

Good times. 13 days remaining and I'll need all 13 to hit the mark but I'm enjoying the hell out of this experience. I think back to my last serious game attempt before I started the 1 Game a Month Challenge and the time I spent on it. It was a rather simple space shooter with randomly spawning enemies and a simple level manager. Depending on whether I roll another month with this game after hitting the challenge I may go back and re-make that game. What took me 80 days last time to make a game that's maybe 80% complete would probably take me 20 or 25 days now. It would be a good test of how far I've developed in the last 45 days.


More later...

Prequel to the halfway point

It's a bit too late to make a video and post it but I have made a good deal of progress this evening. Creeps are working for the most part as are towers. When the game plays itself with no interference from me they fight back and forth and given enough time one will destroy the others base.

Barracks spawn creeps at a steady rate and they do their thing. Still a long ling way to go but I started the day truly concerned if I'd be able to accomplish what you could technically call a game by the deadline.

I still have to create the player death and respawn functionality as well as create an enemy AI for the anti-hero bots. That said, I'm not quite halfway through the deadline and it's starting to feel like an actual game.


More later.

More progress, but it's very slow

This entire week has been hitting one unknown after the other. The GUI framework I'm using gave me some issues but the problem was my lack of experience with it.

I've implemented very basic healthbars for the tower and the player. I'm not very fond of the look but they are functional, and with the series of roadblocks I've hit recently I'll settle for functional right now.

I need to go through and clean up the code I'm using to move the bars around over the actor's heads. I'm also not happy with the camera angle still. I think I need a more "ground to horizon angle than I'm getting.

Lot's left to do and tomorrow night is already planned so no coding. That means I'm 1/3rd way through my time limit but definitely not 1/3rd of the way through the work that needs to be done.

I'm going to keep it at and hope I hit a spot where I blow through the workload and exceed my current output. Friday and Sunday are going to have to be good.

A new technique

Having solved the tower issue last night tonight I had a little over an hour to start on the same issue except this time with barracks. The tower solution didn't scale well because of all the edge cases.

Basically the size of the target determined how well my solution worked. A tower approached from any side is equidistant from the center which is where all of my aiming was going. Once I tackled a barrack the issue became obvious, from a flat side the creeps and the player attack from one distance, from a corner side they attack from another distance. The center of a rectangle varies in distance from various points on the perimeter.

To solve this I'm not aiming and moving to the nearest bound of the collider attached to the target. This has the added benefit of stopping the creeps at the proper distance from the target consistently. This may also solve the issue I was having with baking the navmesh and then raycasting to holes in the navmesh.

I'll have to test the solution more thoroughly tomorrow. But calling it a night it looks promising. I feel like I'm behind scehdule. Its one week in and I'm still working on the controllers and basic AI. These components have to be right but there's so much more to do and not so much time to do it.

Next step needs to be life, death, and combat in between. Afterwards its creep spawning, and base destroying. Big topics, lots of work in between. Time for bed.

Day 7 - Navmesh Hell

I burned most of the day working out a few subtleties in Unity's navmesh system. I'm not 100% happy with the way I put it together but its largely functional.

The navmesh system builds simple geometry and you use this geometry to navigate around your map. The problem I ran into is my towers are static, meaning they never move so Unity was cutting out holes in the navmesh for them. This is intended behaviour. Later, when I tried right clicking to attack them I would have to move my player within range of the tower to use his auto-attack. This is where the problems began.

The intended behaviour is that Unity provides a position that is the nearest edge to where you clicked. However, this turned out to vary wildly per click and made closing to weapon or spell range sporadic and sometimes just plain buggy.

The fix I used was to include a navmesh obstacle onto the tower and to re-bake the navmesh without the tower. This allows the right click to always land on the navmesh and for the player controller to accurately close distance so you are in spell or weapon range.

The downside is you can walk right through the tower as if it isn't there.(per the navmesh system it isn't), the navmesh obstacle makes your character controller avoid it, so you could technically still walk through it, or be pushed through it by another agent, however in light testing it appears to be holding up as intended.

That worked through, I've implemented a very basic combat system. Right clicking an actor that is not on your team causes you to close to auto attack range and start auto attacking. I've equipped the player with a fireball spell that autocasts every 2 seconds as long as he's in range.

Attacks do damage and the tower will quit firing when it's "dead". The player has health, but is still immortal at the moment.

I've also begun the basics of the creep AI. Right now if he's on your team he'll attack enemy towers or move to a waypoint I've set up. If I switch him to the opposing team he'll chase the player around until you leave his range of vision.

All in all it's been a decent couple of development days. The navmesh issue burnt a lot of time but appears to be mostly conquered at this point.

I've also implemented a very basic GUI using DaikonForge. The design time tools are great but I found out after purchasing it that it doesn't handle world space GUIs at all. This means I'll have to roll my own healthbars and damage numbers.

Time for the obligatory video:

this shows a creep chasing me around and then attacking a tower, it also shows the tower attacking the creep and me attacking the creep. Nothing fancy yet, still a lot of plumbing work to do.

Day 5 - Lots of tuning

The last two days i've been implementing very basic combat, and tuning the click to move concept. I've also implemented a very rough version of stats. You can attack a tower and kill it, and visa-versa.

Tomorrow I need to push a lot of the code in the player object down to the player controller object. The abstraction isn't very well defined but it appears to fit in better there.

Currently the player can attack from anywhere on the map because I have implemented a concept of attack range but I've stubbed in some basic functionality to accomplish that. I'll tackle that tomorrow after work.

I need to implement the functionality where if you click on a target that is out of range you will move into range and then begin to fire at it. That's where the leaky abstraction part comes in, it's part player class and part character controller. I'm going with the controller abstraction.

No new videos to show as it's pretty much the same as last except the tower now fires at you.


I'll post a new video tomorrow after I've gotten the movement sorted out.

Night One in the Books

I roughed out the camera control and the player "click to move" in one evening. I'm sure I'll have to touch it again but I was only aiming to finish the camera. Off to a good start.

January 1 Game a Month Challenge

January 1st 2014, a new year, a new month, a new game. This month's entry is much more ambitious than last months. The working name for this game is SOBA. Single-Player Offline Battle Arena. A fun riff off of DoTA2 and LoL style MOBAs.

The bare bones is what I'm going for so I'll use simple primitives and base materials for the game "art". I'm trying to tackle a bunch of functionality so I'm going to focus on code and placeholders, maybe even through the end of the month.

 The 1 game a month challenge now allows you to revisit previous entries and expand on them. The key concept being "save-points" that is, the game must be finished at the end of the month and be an actual game. This is to avert tackling ambitious projects that go nowhere. At the end of the month you may only have an unattractive, mediocre game, but you WILL have a game.

For a project this ambitious I'm going to have to rely on lots of coding and functionality to complete the entire feature set. I'll worry about the art pass if I have time, and if not I'll hit my goal of a complete game that lacks polish, and swing for a 2.0 version in February.

Lots to do so wish me luck. I'll post videos and web builds throughout development to show the various iterations as the game goes from an empty project file to a completed game.

Br'er Rabbit 1.5 - Final Submission

The artwork is in, the game play is complete, the control system could use some work but I've determined that this will be the final state of my first 1 game a month submission.

I need some time to recharge before the January challenge and I'm hitting the busiest week of the year in my day job.

Once I have some space I'll try and write a proper post-mortem but in case I don't here are my current thoughts.

1)I have a lot to learn but that is no real obstacle. Every little issue I ran into is just a matter of learning the API or medium level problem solving.

2) Unity is made for this type of stuff. Having written 3 relatively sophisticated 3d engines over the years it is clear how unsophisticated they actually were. You make games with the toolchain and that's where Unity shines.

3) I can make a game in a month. It's not beautiful or ground breaking but it's a game, cut from whole cloth and made in 25 days. I definitely intend on repeating this success in January.

4) Artwork is fully 1/2 of the equation. Unfortunately for us programmers it's the important half. The difference between the game when I was using placeholders and when I put the skin on it is wild. I'd love to find an artist that was interesting in making a game in a month and see what we could do combined.

5) Unity Asset Store is a great resource. All of the art in the game is a free asset excluding the wolves and the rabbit. Grand total cost for all of the art. $25.

Here's the final video:

Here's the final link to the game:


Br'er Rabbit

Time to recharge and reload, for January I'm going for a much more ambitious project.

Rabbit 1.4 - A facelift

I made a detour the last couple of days because I hit a wall in development. Every line I code I was writing was suspect and I just couldn't get it going. In an attempt to practice useful procrastination I started adding art assets to the game so what I had relegated to "nice to have" made it in before a few "must haves".

 I did get the progressive score system working and tune the game quite a bit though. It's more difficult now and the game adds extra wolves at a faster rate. So not a total loss. It is sometimes frustrating to me how important good artwork is in the actual construction of a game as that is an area I have a lot of work left to achieve a reasonable level of competency. Just not enough hours in the day, especially with the hard 1 month deadline.

I'm already looking forward to the next months challenge and have been thinking about some game ideas for January.

Here's the current state of the Rabbit 1.4

and here's a link to this build

https://dl.dropboxusercontent.com/u/10371409/rabbit1.4/rabbit1.4.html

Enjoy and I'd appreciate any feedback.

Rabbit 1.2

To trudge... the slow and determined march of a man bearing a heavy load...

Ok, enough melodrama. I'm posting this on the 19th but this video was recorded on the 17th and reflects that progress. The simple flashing of the "wolves" required me to refresh my memory on how coroutines work in Unity. After a few stumbles I finally figured it out and also added a sound for when you eat the "carrot" power up.

With 11 days remaining on my first entry for the 1 Game a Month blog, I've hit on what I believe to be the final scope of this project.

I initially hoped to have several maps, and to progress through the maps as you cleared levels. Maybe 5 or 10 plays per map and then I'd alter the maze, move the power ups around, perhaps introduce additional wolf types.

Here's my final punch list. If I have time beyond this I'll spend it on small features I can add in a single coding session or polish.

Will do:

1) One more score dynamic - A progressively higher score for each wolf you eat per power up.(1 wolf gives say 500 points, second 1000, third 2000, etc... resets when you lose your power up status)

2) One more presentation update - A pause when you are killed, then a "you got killed sound" then a reset, then a go! Death is abruptly handled currently with no time to gather yourself before the game continues.

3) Play-balance the game - It is currently too easy. My primary plan is to adjust the scoring system to reduce the number of extra lives you get per map. 

4) Polish - The sounds get the point across but a few hours working on the sounds and adding a few particle effects will go a long way as far as the feedback the system gives you. Without pretty visuals I need to insure that the feedback is tight and obvious. 

More importantly than what I will be able to implement is what I won't be able to implement. That's the sort of  lesson the 1 Game a Month  challenge teaches, you must ruthlessly attack the scope of your game.

Won't do:

1) Multiple mazes/levels - I have a great idea for a dark level where a spotlight follows the rabbit around the level and you can't see what you've "eaten" and what you haven't. Not going to happen for this entry. Maybe some other entry I'll pick it back up and go for it.

2) Proper artwork - I could buy appropriate models and pick up the game visuals by using a proper shader. Maybe, maybe I can hit this mark but I'm putting this weight down as far as a "must have". It's definitely in the "nice to have" list.

3) Intermissions - I wanted a black background cut scene similar to the intermissions in pacman between map changes. No map changes though, so no cut scenes for sure. This would have to wait for a round 2 attack on this project. I simply won't have time to implement this.

4) Android release - I've yet to tackle an Android release but even if its easy as pie I know I'll have to re-write the control scheme for a virtual D pad. As fun as this would be it won't make the cut for December.

Still on target to make my first challenge. I deployed a web player and linked it to a few friends just for the fun of it. I intended to provide links to incremental builds so you could follow along as the game progresses but I got caught up in making the deadline and slacked a bit on blogging my progress.

Here's the link to Rabbit 1.2 - https://dl.dropboxusercontent.com/u/10371409/Public.html

In all its splendor! OK, in all its programmer art, still missing a few key features, splendor!

and here's a short video of a play through.

Rabbit hits 1.0

Pretty exciting to be honest. A 1.0 revision simply means that the game is playable. You can win, you can lose. The fundamental criteria of a game is in place. This feels like quite an accomplishment given this is the busiest month of the year at my day job.

Next round of development involves adding some variety between levels and improving the feedback the game gives you.

One idea along this line are to add a variety of wolves, and to have the spawn rate increase as you go up levels. The alpha wolf will hunt your current position ruthlessly. A hunter wolf will wander randomly until he picks up your scent and will follow it until he gets you. What's pictured currently is the soldier wolf. He just wanders randomly around the map with no chasing ability at all.

 Another idea is to add a power-up spawn that randomly traverses the level at a slow pace. The power up will give you a point bonus and a variety of temporary power ups. What these are is still anyone's guess. A speed increase, invulnerability, maybe some other effect. I need to play test a few ideas and see where the fun is.

Here's the underwhelming, but inaugural 1.0 Video.

One Game a Month Entry

I've decided to work on a One Game a Month entry to put a finished project in my portfolio. The game is a riff off of PacMan, but I'm going to alter the mechanics enough that it should play quite differently.

I'll also document development on this blog. My process will be to get a functional game up and running, primarily with programmer art and royalty free sounds I make or find online, and then I'll hopefully get to spend quite a bit of time on polish.

I started December 1st and have until December 31st to complete the project. As of the eighth I'm probably 7 or 8 good days of coding away from being able to say "game"

Once I've gotten to the point where you can actually "win" and "lose" I'll start working on the mechanics and try and maximize the fun. After that, time allowing, I'll replace the programmer art with something that is higher quality and put proper animations and User interface skins in.