Would you like to play a game? :]

Boh: Standing/Motionless; draft 2

feedback/questions/comments?

Layered all assets, so suggestion turnaround will be pretty quick. 

The Flow of Things

Hello, friends!  Jamie O writing again, at another late-night hour.  This is becoming a sad trend for me.  Let's take a look at what I'm working on.

This over here is one of a series of flow charts that I am working on.  It represents the states that a particular enemy in the game has, and how it transitions between these states.  This is an enemy that patrols between two points.  When the enemy encounters the player, it readies its weapon, and then fires.  Then, the enemy checks to see if the player is still in range.  If so, it repeats.  If not, it goes back to walking around.

This enemy behavior is suitable for something like the skunk.  The skunk wanders around, probably between two points (its "home").  When the player gets too close, the skunk gives him a little bit of the ol' stink juice.  But, if the player is far enough away, the skunk doesn't mind.  Encounters like this can be resolved by the player by attempting to dodge the attack, or taking a route through the map that avoids the skunk entirely.  I'm hoping that the proper placement of items and enemies by Matt with encourage a sense of risk and reward that will make these choices more compelling.

This flow chart represents a simpler enemy that moves between fixed points.  We can represent these points as a circularly linked list, so there can be as many as we want--as long as we can move smoothly between them.  This pattern is appropriate for an enemy that has no attack, but needs to move through an area, like an RA that needs to be avoided.  It's also appropriate for moving platforms, like the turtle.

The real challenge of this is not thinking of how we want the enemies and moving obstacles to act..  The challenge is in implementing these steps in a way that is easy to configure--our level designer should be able to drop down an enemy and set up their route within a few seconds.  I am not entirely confident that the level of cozy customizablity I want is attainable in this upcoming iteration, but it is something to strive for.

I am going to be spending the next few days doing design work.  My dad and brother were both into building, and I was taught to "measure twice, cut once."  Taking the time to make sure that everything makes sense is the best way for me to make sure the work is done right.

Let's get to work.

Working Towards Milestone 2

Hello everyone!  Jamie O writing again.  I don't have much visual stuff to show you yet; I've been working most recently on code that effects things you've already seen.  The big news is that all of the consumable items are in the game and working, with the exception of the Golden Forty.  With that out of the way, the brunt of my work for Milestone 2 will be working enemies.  Currently, none of them are in the game!  I want to meet with Steven and Matt about enemy behaviors and iron out how exactly we want them to operate.  There seems to be some indecision about what we can/should do with them as far as their behavior range, attack styles, and how they will effect the player.

Other than that, it's just a hard-nosed plow through until the 28th, when we'll be presenting our second milestone for the game.

obstacle assets: batch 1

Working on world assets that the character will be able to interact with.  Next step is undoubtedly enemies and other characters within the game... the difficult part.

Basic picnic table, will probably need to be resized.  May add a white border in the next version to make it easier to see within the world, but the base structure will remain the same. 

Slack line.  The idea here is that the character is able to go "behind" the trees, in order to jump onto the line.  It would be awesome if we could figure out some way to program a warping, or the actual slack in the line, but that would be some crazy physics, so for now the line will be straight, even when the character is on it.  Also, we'll need to figure out a way to size the trees to the screen, to give the illusion that they keep growing outside of the frame.

Progress

Hello, Jamie O again.  The programming is plugging along at a decent pace.  With the college semester entering Reading Days, it's not really reasonable to expect much to get done for the next few days--everyone wants to visit their families, I'm sure.  As someone (regrettably) without those attachments, I have no issue sticking around and getting some extra work done.

After we delivered Milestone 1, I was eager to take on the task of moving away fromer raycasting code to Character Controller.  The raycasting code we were using was ripped from a tutorial, and just... was not up to the quality one would want for a fluid side-scroller.  The character had issues where he would be able to walk through tiles, or land halfway inside them.  Moving to Character Controller gave me the ability to have a much firmer control over what the Boh Boy could collide with, and took some of the collision workload off my hands.  It also made it easier for me to work with gravity--which led me to fix his infinite jumping problem.

I have been talking with Alex on the art team about his desire to see a more fluid motion in the character.  This kind of undertaking means that we'd have to encode the concepts of momentum--building up from a slow start to a full running speed, and skidding a bit on the stop.  If done well, we could work on momentum being stronger over slippery surfaces (think of sliding on ice).  I had also considered some things like ducking, dashing, double-jumping, and wall-jumping.  These are all aspects of modern side-scrollers that give the player a feeling of control and fluidity.  However, there would need to be many more frames of animation to encompass true fluidity.

For the moment, though, I am sticking with the proposal document's workflow.  And this means that I am working primarily on getting consumable objects working in the game.  Right now, the code allows for the Boh Boy to carry up to five beers.  He can pick them up by touching them; they are not yet hidden.  We have the art assets for the food in the game as well, but I've not got the mechanics working for them.

As we continue to look ahead, the goals after the consumables are working include the ability to reach an ending screen, the inclusion of basic enemies (they do not need behavior yet, just the ability to stand in the game and hinder the Boh Boy's progress), further work on the controls, and some map building.

I'm taking the night off, but there will be some serious work on the game occurring tomorrow.  Expect further updates this weekend.  Ta ta for now!

food assets

Natty Boh Android Game Trailer 1

Step by Step

Hi folks, Jamie O again.  This project is starting to come together, step by step.  It's exciting to see the way things are shaping up.  We delivered our first milestone, which was a rough tech demo of what we want to do.  There is a lot for us to add to it, but with an iterative development process, it is best to get out a functioning system as fast as possible.

With Unity, it is really easy for us to deploy to various operating systems.  The great thing about this is that we are able to test our progress without having to turn our attention away from our workstations.  The unfortunate thing about this is that sometimes, just sometimes, things do not translate perfectly.

For instance, on the phone, the Boh Boy hasn't scaled as clearly as he has on the PC.  This makes him a bit blurry.  Blurry characters = bad for business.  We've got to fix this before the next delivery.

While it is great to see our hard work leading to a character on a screen, it is important for us to not get too ahead of ourselves.  Properly managing workflow, making priorities, and just plain getting our hands dirty is what builds successful projects.  And with that in mind, we take a look ahead at the next delivery.

We want to solidify a few things:  we want excellent touchscreen controls, natural-feeling jump mechanics, more sensible collision detection, and to just keep our codebase clean and easily navigable.  On top of that, the next slew of features to add includes collecting beers and having enemies on the map.  For me, that means reading up on some new APIs.  For the rest of the team, it means design work.

Keep an eye here for a trailer of our work so far.  Ciao!

boh is born

This ain't Chicken Little...

But the sky is falling! Oh, wait, that's the ground! Nooooooo....

Anyways, we getting pretty far in development here at Haddafew Development. We've got a semi-playable game, with some real drunk perspectives. Not sure if that's a bug or a feature.
Backend controls still need some work, the drunk mechanics need to sober up for the initial visit, and a few other tweaks need to be handled before we give a public release.
HOWEVER, we should still have a trailer for you guys on either Friday or Saturday, to give you a better idea of our game and why you know you like it.
Keep an eye out for new releases about the game and many other strange and spooky things.