Thursday, July 11, 2013

Dev Notes: Menu Flow

The concept of "Flow" is a state people can enter when they are completely immersed in their work, fully engaged at such a level that they do not notice the passage of time. This is how you can look up from a good book and realize it's after midnight, or why kids always seem so surprised to see their parents come in after their two hours of game time is up. "But I only played for an hour!" they might say. (and when they do, a game designer gets their wings!)

Jenova Chen (Creative Director at thatgamecompany, makers of Journey) has a great primer on Flow, if you want to do some more reading on the subject.

When it comes to games, a team seeking to put their players into "flow" must do everything they can to not interrupt play. This includes loading screens, long cutscenes, dropped frames, and other glitches that basically scream "THIS IS NOT A REAL EXPERIENCE."

In the first stage of its development, every screen in Chess Heroes was its own level. This made it extremely easy to prototype quickly, and altering the "flow" (lower-case f!) through the menus and into the game and back out again was easy, too. But! Now that the game is getting into a more final state, I have to reduce the number of level loads so that "Flow" is maintained. This means smooth transitions between menu states, and clever ways to hide the frozen state of a game loading the next level. As you might expect, this is taking a bit of time, but with the look and "flow" finalized, it's worth it to finally nail down the "feel" of the game. This starts with the menus, flows into gameplay, then pulls back out again. So far, it's been a treat, and I'm ecstatic to be working on a fully realized polish pass, instead of hastily rushing through with a "good enough ok ship it" mentality.


And yes, when they say the last 10% of the work takes 90% of the time, they weren't joking. It really burns through the working hours, but at the end of the day, it's absolutely worth it.

Wednesday, July 10, 2013

Unity: Creating dynamic lines

I learned how to program using Java, specifically a development interface called Processing, which I heartily recommend to anyone thinking about trying it. The work I did was in 2D, and as I grappled with vector math and time slices, I found it very handy to draw a line from an object I was moving to the point it was moving to. This illuminated what the object was thinking, something traditionally difficult to do during runtime, and it was as easy as saying "draw a line from this point to this point."

When I started using Unity, I didn't have this option. It was impossible to say "draw a line from this point to this point," at least in such simple terms, and as I grappled with vector math (again, but in three dimensions!) I felt out of touch and frustrated when I was forced to interpret what was going on, rather than knowing at a glance.

Lucky for us, I found a solution, and I've been using it ever since. Although my grasp of vectors is much tighter these days, it's always a treat to write artificial intelligence that, say, takes a mob through the floor and into the void beneath, rather than to a point of interest. In those cases, where the object is making its own decisions, it's good to know what it's "looking at." And that's when the Magic Lines come into play.

Okay, it's actually called Line Renderer, but where's the fun in that?

A Line Renderer component can be used for motion trails, telephone wires, hanging vines, and a whole lot of other fun visual tricks, but here we're just going to draw a line in space, from one point to another. Here's the code:
LineRenderer magicLine;

void DrawLineToPosition (Vector3 targetPosition)
{
 // If we haven't created the LineRenderer yet, do so
 if (!magicLine)
 {
  magicLine = gameObject.AddComponent;
  // Give it only two points: one for "here", one for "there
  magicLine.SetVertexCount(2); 
  // The "line" is actually a polygon, and here we can make it taper a bit at the end
  // In effect, it points at the target position
  magicLine.SetWidth(1, 0.1);
 }
    magicLine.SetPosition(0, transform.position);
    magicLine.SetPosition(1, targetPosition);
}

Tuesday, July 9, 2013

Dev Notes: The Look

FOUR WEEKS PRIOR

The woman in the unemployment office lowered my resume and looked at me over her librarian glasses.

"So, you know computers. You should be able to find a job."

"Sorry, no, I'm a designer. Not a programmer."

"A designer?" She swiveled in her chair. Fingers flew across the keyboard, tapping a rhythm punctuated by a solid whack of the Enter key. "There are a few graphic design positions already in the database. What about that?"

I tried to be polite as I let out a mute sigh. "I'm not a good graphic designer. I know that from experience. And I do game design. It's a different discipline."

Turning slowly to face me, she handed back my resume and looked at me as if I was an exotic plant left in a parking lot. Clearly, I would require Special Attention And Care.

YESTERDAY

I woke up feeling refreshed, which is never a good sign. It's usually a sign that the good Lord is ready to test me. And when the dog started howling like foreign invaders had dropped from stealth planes onto our lawn and were fixing bayonets, I knew I was right.

So after spending the weekend cleaning out our garage, cleaning out our fridge, shredding a mountain of old documents, and remembering to get the trash bins to the curb the night before, a car had the decency to punt them fifty feet down the road and empty the contents onto the road.

That wasn't why the dog was howling. It's because our neighbor had come over to let us know what happened. Oh, well. The dog and I will have differences about what's worth a howl now and again. Comes with the territory.


I threw that image in there because I was getting Wordy and I dread losing your attention! Long story short: we cleaned up the mess with the neighbor's help, it was easier than expected, and the sun was shining in Oregon that day.

Still, I had a fully functional demo that looked like crap. This is the week I Try To Make It Look Good, so I wiped the slate clean and gave it a go.

Lo and behold, a few hours and several false starts later, I had The Look I Was Looking For! I'm as stunned as anybody, by the way, especially my former Art Directors. All of them used special tongs to handle my Art Suggestions.

Despite that, I hope you agree it's appealing. Just... please... don't call it graphical design. It's just a production phase I'm going through!


And yes, I painted those fluffy clouds! Arigatou gozaimasu, Kazuo-sama.

Monday, July 8, 2013

The Epitome Of Passion

I had the pleasure of listening to a talk by Brian Provinciano at the inaugural Game Creators Summit in Seattle this June. Before then, I'd heard of Retro City Rampage, but didn't look too deeply into it. At the time, I thought it was just another wanna-be old-school "8-bit" indie game that cribbed its design framework from Grand Theft Auto.

In fact, it's a deeply authentic 8-bit game that uses Grand Theft Auto as a template because that is not easy to do. If this was a movie, it'd be something like Pi or Primer: ambitious projects that succeed on their merits, but also have a deeper, richer level of appreciation for what was achieved. These projects could only be finished by combining a blazing passion for the medium with the skills to accomplish their goals, and indeed to set them properly in the first place.


I had the chance to ask Brian: what drove you more? Was it the desire to finish an engineering feat, the monstrously bad-ass compiler that creates NES games which run on natively on multiple platforms? Or was it the desire to finish a well-rounded game experience? The unspoken question was this: was he just creating tools because he wanted to make a game, was he just making a game to use his tools, or was it actually evidence of an all-encompassing passion that defies easy categorization into "artist/engineer/designer?"

His answer? It started with a passion for the engineering. And when he had achieved that goal, his passion became making the game. Along the way, he learned how to make good art by referencing masters of the NES format. That was the answer I was looking for: he was excited about all of it.

I don't know what to call people who can code and design and art. They don't see Impassible Barriers when wandering new lands, they just see Problems To Solve in the pursuit of a Grand Idea, and subsist on the drug released by learning. But we speak a similar language, and know the same muse, her body built of ones and zeroes.

To build a mountain because it wasn't there. Then climb it, and build a castle at its peak. That is the essence of the passion of game creation. And Brian's work on Retro City Rampage is the epitome of that.

Thursday, July 4, 2013

July 4th Week Update

Independence day! Fireworks! Barbeque! Beer! If there's going to be a hole in the development schedule, I hope that's the shape it always takes!

With a day gone, I wouldn't hit my Friday goal, so I've used this week to take care of some other business. I helped move office furniture into FertiLab, opened a bank account for Oreganik LLC, and finished a programming contract that will bring in a nice chunk of change... er, just as soon as I test it on my iPad.

I think the "week off" from Chess Heroes will be good, as I had been hard charging for a month. That can take some wear off the treads, you know? I've also been "relaxing" by working on two hobby games. Their smaller scope and easy-to-achieve feature additions give me a much-needed boost at the end of the night.

I'll be back next week with the regularly-scheduled program:

  • Monday: Inspiration
  • Tuesday: Dev Notes
  • Wednesday: Unity Tech Tip
  • Thursday: Dev Notes
  • Friday: Indie Shout-out
Good luck out there!

Friday, June 28, 2013

Indie Spotlight: Gunpoint

Indie Spotlight


I believe the best action games are built around a simple concept: Mario jumps, Sonic goes fast, Link explores, Cogs shoot aliens from behind cover, etcetera. Gunpoint's concept is: rewire things.

If that doesn't get you bristling with excitement, then you haven't played the game or seen the video!

From these simple concepts -- from one simple verb -- a huge array of gameplay possibilities can open up  if the game has been properly crafted. And that's the trick, isn't it? To make a structure that can withstand a hurricane of half-sleepy, over-caffeinated, or drunk gamers thrashing about with a controller, and yet retain its breezy accessibility, tempting them with One More Try?

Gunpoint accomplishes that. It gives you that tingly sensation you get when learning by trying something instinctual but untested... and succeeding. Then it does it over, and over, and over again, all wrapped in a lovely shell that you can pause and admire.

Give it a look. Three years of development have resulted in a success story, and that's always a sign of something great.

Thursday, June 27, 2013

Demo Progress

Dev Notes
It's been a steady march towards a feature complete demo, with the Friday goal still in reach!

  • The pipeline for creating tutorials has been streamlined, making them very easy to pump out. 
  • I've added the first magic spells: Enrage (move a single piece twice) and Transform (change a Pawn into anything else). Each spell "breaks" the game in a special way, so I've been altering the core logic to be a little more flexible. Having bespoke code for every single spell is a big no-no!
  • I also finished and tested the "demo flow," starting from the Title Screen all the way to "Thanks for Playing." This involved a lot of writing and re-writing, to make sure the text on screen was short and to the point! 
The two "big" tasks left on the plate are tutorials for the spells and a system which gathers survey information. After that, it's bug testing, scenario design, and polish! My aim is to send a private demo to certain folks next Friday, in anticipation of a wider launch after I process their feedback.

State Machines
I've been using State Machines to handle game states since my very first Unity project -- Ninja Baseball -- yet somehow I neglected to do so with Chess Heroes. Big mistake! There's nothing worse than having to manage 1000+ lines of code in your core logic file when there are a large number of states to enter and process, and then adding to that complexity. Yuck!

If Chess Heroes moves into "Full Production" status, I'll be overhauling it to use a state machine. It allows for the graceful addition and removal of states, and keeps logic in check when altering flow. Watch this space (all two of you!) for details on implementation.