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.

What is his nature?

“What is his nature?, What does he do?” This was the key question posed by Hannibal Lecter in Silence of the Lambs. As I play Dragon’s Prophet, or in this case, don’t play it, I am suddenly struck by this question. Who is my character, and what is his nature?

The game is satisfying, graphics are acceptable, the pay wall implementation is not exceedingly awful. The ability to tame, ride, and level dragons is the star of the show and the most compelling difference from similar offers out there. But what is my characters nature? Unfortunately his nature is to grind quest after quest in order to level... in order to grind quest after quest in order to level... ad infinitum.

The story is lackluster, but that is a red herring. Unless the story was the most compelling story ever told; (Imagine a book where you had to run a mile after every tenth page, but was so compelled that you did so) a great story would not save this game.

The issue with this game is the same issue with many MMO’s using the same formula. What is the characters nature? To grind quests until you run out, or hit the level cap, after which you grind gear until you get the best gear or run out of content. Stated simply, the answer to what is his nature is “to grind”.

Your actions aren't meaningful, not even in the limited framework of the game itself. In real life, you burn time that could be better spent doing most anything(let’s go ahead and run that mile now). As with any new game, the jaded MMO veteran will explore the mechanics, take note of any interesting approaches to the many tropes common to all MMO’s, explore the class designs and leveling mechanics, and then abruptly check out. Maybe they return in boredom, maybe they go seeking the next new thing.

“What we do in this life, echoes in eternity!” - Maximus, Gladiator

The most fertile ground for MMO development requires that a player’s actions are meaningful within the scope of the game. Easier said than done, certainly. But until that bridge is crossed, however many millions of dollars are poured into copy after copy of knock-off games or rehashed mechanics would be better spent trying to cross this threshold.

The market is hungry for something novel. The market is STARVING for something novel.

“This town needs an enema” - The Joker, Batman

The next game that mixes fear and wonder, that makes either life, or death meaningful(preferably both) stands to capture a market of 20 million subscribers with a proven track record of spending $15 per month to scratch this itch. For $300 million dollars per month, can any team of engineers and artists provide us unwashed masses a game experience where killing the invading horde of goblins actually impacts the game world in some meaningful way?

Modern MMO’s are a thousand miles wide and six feet deep. Robust and interesting game mechanics are a gift that keeps on giving. Invest once, profit forever. Hand crafted content is interesting, and can be very beautiful, and may even be important in the scheme of things, but it is ultimately disposable. Once it is consumed its marginal value is minimized, and even more dangerously, because the studio is ever surprised by the swarm of gamer locusts consuming the content at such an alarming pace, they tend to rehash and remake the same content in order to reduce burn rate.

Even in the amateur game development scene I’ve met engineers and artists that have an incredible aptitude. Good, serious guys and girls that are masters of their toolset and just outright formidable in their approach to the craft of making games.

This is a solvable problem, and we need to get on it.  

Integrating Twilio with Google App Engine

I'm currently working on integrating Twilio with my website hosted on Google App Engine and I continue to run into documentation meant for Linux users. It's a double edged sword because Linux users always run into Windows documentation when they're working on consumer based software. Because this is a server app Google assumes I have a long gray beard and a stuffed penguin on my desk.

I just ported the stickiest part of the tutorial from Posix systems to Windows and wanted to share in the hopes that I will spare someone a few gray hairs.

Here's the link to the tutorial
https://developers.google.com/appengine/articles/twilio

Under the "setting up" section the first thing you'll want to do is drop the 'sudo' portion of the commands but everything else will work fine until you get to this part:

• Link the Twilio library and its dependencies into your project:

• $ ln -s venv/lib/python2.7/site-packages/twilio .

• $ ln -s venv/lib/python2.7/site-packages/httplib2 .

• $ ln -s venv/lib/python2.7/site-packages/six.py .

Compared to the Unix ln the argument order is flipped on mklink. The ported version of the tutorial is:


mklink /D twilio venv\lib\site-packages\twilio
mklink /D httplib2 venv\lib\site-packages\httplib2
mklink    six.py venv\lib\site-packages\six.py

note on the last link, which is to a file, not a directory, you omit the /D as file linkage is the default.

A few hours burned away at this, would have been great if they'd addressed it in the documentation.