Wednesday, July 24, 2013

Dev Notes: On to art!

Today, the Chess Heroes demo reached a milestone: functionally complete! "All" that remains is the art pass, scenario fun pass, then playtesting and final bug fixes.

Some folks say "ship a broken product and fix it live." I disagree with that proposition. =)

Because the blog has been quiet (I'm working on the 7dRTS compo at night, among other things), I'll let slip a screenshot of the art in-situ. This is not final, in other words, but it gives you an idea of the style I'm going for: simple, hand-painted textures and soft colors.

Saturday, July 20, 2013

Chess 2.0 ???

Well, this is ironic.

I have a history, well known to my friends, of coming up with original ideas, starting work on it, then seeing an announcement weeks, months, sometimes only days later, where a product featuring that same idea is loudly announced.

The shortest turnaround was a day. Back at the Guildhall, I sketched out the rules for a two-player competitive card game about game development, designed not only to be fun but educational. The next day, a university in the Netherlands announced the release of... a card game designed to teach students about game development.

Now, scant weeks before the private demo of Chess Heroes is ready, Ludeme Games and David Sirlin announce Chess 2: The Sequel and get a fairly glowing reception on Kotaku, titled "Well, Thank God, Someone's Finally Making the Sequel to Chess."

I know this happens to other people. I know this is not my own personal pain cave. (and actually, I find it funny more than anything) But really? Really? Wow.

My own comments on Chess 2 are:

  • Holy moly, those chess pieces look incredible.
  • The rules are very deep, and possibly over-complicated.
At the end of the day, there's no overlap in presentation or rules. Their stated intention -- "relies much less on memorized openings and more on positional play"-- is true of Chess Heroes as well, but that seems to be where the similarities end.

And David Sirlin is an excellent designer. I trust this will do very well.

I just have to figure out how to make sure Chess Heroes is not perceived as "inspired by" Chess 2.0.

PS> Now I remember hearing about the rules from Jaime Fristrom, the developer behind Energy Hook, at the indie game conference in Seattle. But I think the video game announcement is actually new.

Thursday, July 18, 2013

Dev Notes: Approaching Feature Complete!

The past two days have been a bit slow. I've had to spend time working on the business plan for Oreganik LLC, and I've been going back and filling in any cracks I can find in the demo. This includes updating the look and functionality of the survey questions and inserting them into the flow of the game, and revamping the magic spell UI to be all purty and such.

One thing I learned at Neversoft was to make sure the build could be run, start to finish, each Friday. This provided a clean slate for the next week, and usually prevented any gnarly hacks from putting down roots. Now that Chess Heroes is chock-full of stuff, I'm going to incorporate that into the schedule.

It's extremely excited to be this close to Feature Complete. I thought I'd be here weeks ago, but being part of a family and several communities takes all sorts of odd bites out of the day. It's totally worth it, of course, yet I find myself longing for a cabin on an island where I could... er... sit inside and work all day.

Wednesday, July 17, 2013

Unity: Detecting a Cursor over an Object

Many indie games feature a single avatar moving through a world. (If I've already lost you, Mario is an avatar, because you control his murderous waltz through an enemy-occupied Mushroom Kingdom.)

Having a single avatar makes things easy for both implementation and comprehension: it's easy to make because you just test to see what's close to the player, and it's easy to understand because the player knows who he/she is on screen. "I am that plumber," they think, and they push a button, and since it's easy to check if a button is pressed, the game responds instantly, and all is well.

But! Some games don't have a single avatar, and that's when you need to use the mouse (or your finger) to select an object, or point to a position on the terrain. These games are almost always strategic or tactical in nature, like StarCraft or SimCity, and here we're going to see how to do that in Unity.

In this example, it waits for a mouse click, then sends a ray from the cursor (via the camera) into the game world. If it strikes this object (and it has to have a collider for this to work), you can then run special commands.

 void Update ()
 {
  // This will only fire the first frame after the button was pressed
  if (Input.GetButtonDown("Fire1"))
  {
   // Fire a ray from the camera into the world
   Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition);
   RaycastHit hit;
   // Test it out to 1000 units. If it hits something, continue.
   if (Physics.Raycast (ray, out hit, 1000f))
   {
    // If it hit THIS object, do something.
    if (hit.collider.gameObject.Equals(this.gameObject))
    {
     Debug.Log("You tapped a " + gameObject.name);
    }
   }
  }
 }

If you're curious, here's how you'd do it on an Android or iOS device. Since there's no debug log that's visible, we'll just destroy the game object when it's tapped.

void Update () 
 {
  RaycastHit hit;
  foreach (Touch touch in Input.touches)
  {
   Ray ray = Camera.main.ScreenPointToRay(touch.position);
   if (Physics.Raycast (ray, out hit, 1000f))
   {
    if (hit.collider.gameObject.Equals(this.gameObject))
    {
     if (touch.phase == TouchPhase.Began)
     {
      Destroy (gameObject);
     }
    }
   }
  }
 }

This technique fine for most projects, and I used this code on every object I wanted the cursor to be "aware" of. However, once I needed a system where I always knew where the cursor was, I realized it didn't scale: a raycast would be calculated every frame, by every object. Furthermore, there's no clean way to handle multiple camera layers, such as a Menu Camera and Game Camera, and that can lead to some "fun" bugs and user frustration.

Now, I have a single cursor control object. Each frame, it sends out a ray, and brings back any GameObject it hit. There, your options split: you can Broadcast a generic command to each script on the object, or if you've standardized everything, you can get a script component and run the command directly. I'm using the Broadcast method, because *shrug*. Here is the (simplified) code I'm using for Chess Heroes.
 Camera menuCamera;
 Camera sceneCamera;
 GameObject hoverObject;
 GameObject menuObject;
 GameObject sceneObject;
 
 void Start () 
 {
  menuCamera = GameObject.Find("MenuCamera").GetComponent();
  sceneCamera = GameObject.Find("SceneCamera").GetComponent();
 }
 
 void Update ()
 {
  // First check if the cursor is over a menu object
  menuObject = GetObjectUnderCursorUsingCamera(menuCamera);
  
  // If it's not null, continue
  if (menuObject)
  {
   // If it's a different object, run MouseOver on it
   if (hoverObject != menuObject)
   {
    MouseOver(menuObject);
   }
  }
  // Otherwise, check the scene
  else
  {
   sceneObject = GetObjectUnderCursorUsingCamera(sceneCamera);
   
   // If it's not null, continue
   if (sceneObject)
   {
    // If it's a different object, run MouseOver on it
    if (hoverObject != sceneObject)
    {
     MouseOver(sceneObject);
    }
   }
   else
   {
    // Nothing of interest in the scene or menu, so run MouseAway
    MouseAway();
   }
  }

  // If the button has been tapped and there's an active object under the cursor, send it a message
  if (Input.GetButtonDown("Fire1") && hoverObject != null)
  {
   hoverObject.BroadcastMessage("OnTap", SendMessageOptions.DontRequireReceiver);
  }
 }
 
 GameObject GetObjectUnderCursorUsingCamera (Camera camera)
 {
  Ray ray = camera.ScreenPointToRay(Input.mousePosition);
  RaycastHit hit;
  if (Physics.Raycast (ray, out hit, 1000f))
  {
   return hit.collider.gameObject;
  }
  return null;
 }
 
 void MouseOver (GameObject targetObject)
 {
  if (hoverObject != null) 
  {
   hoverObject.BroadcastMessage("OnMouseAway", SendMessageOptions.DontRequireReceiver);
  }
  targetObject.BroadcastMessage("OnMouseOver", SendMessageOptions.DontRequireReceiver);
  hoverObject = targetObject;
 }
 
 void MouseAway ()
 {
  if (hoverObject != null)
  {
   hoverObject.BroadcastMessage("OnMouseAway", SendMessageOptions.DontRequireReceiver);
   hoverObject = null;
  }
 }

Tuesday, July 16, 2013

Dev Notes: Cursors!

Having hammered the menu aesthetic into a cohesive form, it was time to fall upon the actual gameplay interface, and knock that into place. Ideally, games don't need to hold your hand through every simple action: you want it to feel like you're pulling on clothes that fit exactly as they should, without a tailor fussing about, or an instruction manual to refer to.

But when I sat people down with an early prototype of Chess Heroes, and they asked "which one am I," when there was a single white King, on the left, facing off against three black Pawns, I realized that there would have to be more handholding that I originally thought.

I'll admit, I spun my wheels for a bit, desperate for a way to indicate to the player what was going on, without using ugly in-game menus or text. Finally, I decided to pull up some videos of an old-school tactics game: Heroes of Might and Magic II. When I saw the cursor icons, I realized: that was the core solution!



I'd shied away from custom cursors in Unity before, because they rendered at game speed instead of hardware speed (imagine a target reticle following your mouse, and only catching up when you slowed it down). But in Unity 4, they introduced hardware-speed custom cursors! 

Happily, I went to game-icons.net, found some likely candidates, and went to work. Here are the results so far:


This changes the cursor into a "verb," so to speak: select, move, kill, etc. The next questions players have are: what is the subject ("who is doing this verb?") and what is the object?

Without the ability to dynamically draw an outline around mesh objects (I believe that's only in Unity Pro), I fell back on an old "cel-shading" trick: increasing the scale of a mesh and reversing the normals.*

It's not perfect, but for now, it's Good Enough. You move the mouse around, and the cursor changes to a Pointing Finger when it goes over a chess piece. You click, the piece glows gold, and the finger now has an X on it. You click, it's deselected, and the finger goes back to normal. Ah! Select and deselect.



You select the piece again, then move the cursor around the screen. You highlight a space, and see a boot: walk here. You highlight an enemy piece, it glows red, and the cursor becomes a sword: capture this. It all makes sense! That's a happy place to be right now.


* Everything in a game is drawn with triangles, and every triangle is one-sided. The side it faces is represented by the normal (I don't know why it's called that!). Imagine a perfect one-way mirror: one side is transparent, while you can see your face on the other side. That side is where the normal is facing.

Friday, July 12, 2013

Indie Spotlight: Tower of Guns

Indie Spotlight


You may not have an overwhelming drive to fashion an interactive experience in which you created all of the elements by hand. But I do! And there are more and more of "us" out there: game developers who aren't seeking to change the world, but to master a quad-disciplinary medium (code, art, design, sound), entertain some people, and earn enough coin not to need a proper job.

I don't want to call it a common denominator, but what you'll often find is that "we" are drawn to algorithmically-generated design. This sidesteps a major flaw in being a one-man team: it takes a lot of time to create properly balanced and thematically varied levels (or "content"), and by the time the game is mature enough to need it, our attention has wandered away to another project!

When content is generated randomly, we find ways to constrain this randomness so that we're not facing the daunting prospect of creating a full, living landscape. And so, these games (often called "roguelikes" in homage to the first and which is a term in dispute [read more at The Penny Arcade Report: "What the hell is a roguelike?"]) take place in enclosed rooms (dungeons) or, in quite the reverse, outer space.

The next step is to determine what the player can do, and, what do you know, there's room for algorithmically-generated design there, too! Randomly placed weapons! Randomly placed monsters! You get the idea.

One odd trivia bit: historically, there have been very, very few "roguelikes" that have FPS controls (think Call of Duty or Skyrim). Some, like Nosferatu rammed up against the tech limitations of the day. Others, like Dungeon Hack, are first person, but are turn-based and have a fixed perspective. Borderlands stepped closer, with its randomly-generated weapon and loot system, but it still relied on man-made maps.

I think we're primed to see an explosion of FPS roguelikes in the coming years, especially as tech limits evaporate and game engines like Unity and Unreal become more and more flexible. One of the first out of the gate is Tower of Guns. Check it out.



Randomly generated rooms. Weapons that "evolve" based on other guns you pick up (a rocket launcher + a shotgun = a fistful of rockets!). Full-on Quake-speed FPS controls. This is going to be a good one!


Check it out on its homepage, and give it your support on Steam Greenlight!

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!