E. Darwin Hartshorn: //Boilerplate

Bestiary In Progress

  • Zoom implemented.
  • Zoom and pan given keyboard shortcuts because I couldn’t find my wireless mouse.
  • Box selection implemented.
  • Editor displays a list of parts you’ve cut out.

Editor

Next up:

  • Individual part editing
    • Changing names
    • Outlining color sections
    • Assigning palette indices
    • Scrolling through the part tray should probably be implemented as well.
  • Packing the resulting kibbles and bits into a fairly tight texture atlas and saving the relevant offsets.
  • Then on to the animation creator!

 

Wed, 30th:

  • Box selection now works from any corner, instead of forcing you to drag from top-left to bottom right.
  • Moved the piece tray into its own file for ease.
  • Mouse controls no longer work on the selector screen if the mouse is hovering over the piece tray.
  • You can scroll the pieces up and down in the tray with the mouse wheel.

Editor

  • Pieces in the tray now scaled to a common width.

Thur, 31st:

  • Added a new state for editing the individual layers of a piece.
  • You toggle into the state when you click the piece in the tray.
  • The state draws the piece as a whole
  • Added a simple text button drawer/thinger.
  • Got the two states to play nicely together.
  • The layer peeler now draws the layer you are currently working on.

Editor

Next up:

  • Switching layers.
  • Labeling the layer and the piece.
  • Selecting the specific source rectangle of the layer.
  • Rebuilding the palette and selecting indices.
  • Packing it all together in a single texture.
  • And the like.

1-1-16 Happy New Year!

Note: I can pass a delegate to a state that’s meant to serve as an input box.  When the state is done, it will call the lamda, thus passing the result back. Is this a terrible plan?  Probably, but I try more for speed of implementation when building my tools.  Is this a terrible plan?  Probably, but it’s the only way I’ve ever finished a game.

  • Added a text button with the name of the piece, so we can change that later.
  • Noted that my text buttons looked like those text stickers you used to use on your stuff, and intentionally ramped up the similarity because I can’t help dallying for artistic niceties.
  • Added buttons to switch from layer to layer
  • Created a palette and displayed it
  • Created a color editor.

Editor

Next step: Switch in an enum/int/int key for the pieces.  Then make the appropriate ‘name changer’. Then make the part slicer for the sublayers.


Stuff and things!  1-2&3ish

I can change the names of the pieces.  Also the modifications have been moved to an external dictionary for access beyond the slicer.  First major step on the way to making this sprite-animator ready.

Editor

Next up: having the layer selecter read from and write to this common sprite thingus, so that palette changes persist.  Then, outlining individual parts.  Then the dreaded packer.

Bestiary Progress Report

  • Worked out the final(ish) art style for the game, in part by brainstorming on this blog.

Migzor

  • Built a set of test textures for the sprite editor.
  • Moved my XNA Entity System into Monogame as Linked Files so they’re equally usable from Windows and Android.
  • Started building texture processor:
    • Got it displaying the textures.
    • Rebuilt my mouse system…
    • … and got the mouse moving the texture set around with a middle-click.

Editor

Next steps:

  • Zoom with Scroll Wheel
  • Outline rectangles with Left button
  • Naming individual parts

Broad goals:

  • Coloring system so I can assign palette indices to various layers of individual parts.
  • Taking the multiple texture atlases into a single texture via outlining blocks within a part, rectangle packing, and offset saving.
  • Once the texture processor is done, build the animation editor (a’la Silva’s in Building XNA 2.0 Games), and set up some test animations.
  • Once there are test animations, get the animations playing on my phablet.

Note to self:  Using Vector3s instead of Vec2s will allow me to both store relative depth of the parts and use matrix multiplication to ensure the component layers rotate and scale with the sprite as a whole.

Medium Must Match Message redux

So here’s my problem:  I’m a half-decent artist.  I need to make art for Bestiary.  But the art has to fit the tone of the game.

The idea, in Bestiary, is you are a Sentinel, one of those people who can bond to and control the native creatures of Theria.  Since the powers of therians are fantastic, human colonists rely on Sentinels to keep them safe, to hold the line against the violent world just beyond their doors.  But those who control the monsters are suspected of being half-monster yourself, so your necessary role is also a curse.

Continue Reading >>

Medium Must Match Message

This is a good article to read.

Auro wasn’t supposed to be “retro.” To me, the “retro game” aesthetic isn’t just pixel art, but an appeal to the specific sounds, feedback, and look and feel of a specific set of old school games. While it’s true that Auro was an homage to my favorite game art, I never intended for it to be “retro.” I just wanted to make great pixel art, yet it inexorably gets lumped in with the retro aesthetic.
But here’s the clincher. It’s not their fault.

“Retro?” Poppycock! I’ll have you know I’m quite jiggy with it!

The Artist’s Responsibility
Though I never intended for Auro to be a “retro-style” game, what I intended doesn’t matter at all, and it’s 100% my fault for failing to communicate in a language people understand.

As a game developer, time is the most valuable resource a human can give you. Nobody owes us their time or attention. As such, when someone gives us their time, an implicit agreement is made and we are now in debt to that person. We owe it to them to deliver value for their time, and to deliver it efficiently.

I am an illustrator/animator. The kind of value that illustrators/animators are responsible for is distinct among other types of visual artists. We must establish meaningful intent as close to instantaneously as possible. By meaningful intent, I simply mean that the audience has to internalize the concept, motion, emotion, perspective, etc. of a pieceright away. The second the audience asks “how can he bend that way without breaking his spine,” or  “Why is he shooting where he’s not looking,” we have failed them. They don’t owe us the time to look at our work in the first place. They certainly don’t owe us the time to squint their eyes and try to make sense of our work.

Meaningful intent applies to medium as well. In choosing to make our game with pixel art, we have accidentally taken on a war on two fronts. My job was to make Auro’s art polished, inviting, and clear to the audience, not to also educate the audience that pixel art is a deliberate style.

My main point dances around Mr. Reynolds’ point.  The consumers of Auro criticized it for its ‘pixelated’ art, not understanding that it was intentional.  Reynolds correctly places the blame on his failure to communicate, but seems only to brush in passing on how he failed.  The quote, “Auro wasn’t supposed to be “retro.” To me, the “retro game” aesthetic isn’t just pixel art, but an appeal to the specific sounds, feedback, and look and feel of a specific set of old school games,” is the closest I see to an explicit recognition of the issue.

The issue is that the medium doesn’t match the message.

Continue Reading >>

Update on Project Therion

Project Therion has changed quite a bit, though the core of the design has remained the same.

The new combat system deserves its own article.  Once I’ve got it half-functional, I’ll try and put it up so you can try it out.  My current goal is to make a small phone RPG along the lines of Wizardry using the Therion combat system (but for three or so races and three or so classes instead of fifty-plus monsters), to see if the core gameplay is fun and, well, just get a game finished. It has, in fact, been more than a year since my last game.

Therion Combat Implementation

Right, I’ve got Dragonforce loaded up and playing their songs with a chainsaw that has guitar picks strapped to the teeth.  Time to work out how I make my fancy combat system.

First comes the easy part.  Moving moves to the combat strip from your move tray.

I’m going to magically decide that our playing area is 240 by 400.  Then, in the final game, we’ll scale it up so that it fits in some proportion that will allow x pixels per pixel of game screen, giving us a classic oldschool pixelarty look that plays to my strengths as an artist (or rather plays to my weaknesses: I can’t do all the art and all the coding unless I super-simplify the art somehow).

240×400 is half the size of the most common Android screen, so it should scale well to most phones.  So now I pop open Inkscape and throw together a quick layout.

Here’s how it should be laid out when the monsters are fighting, and then how it should be laid out when you’re picking a move:

Battle Screen Select

So, there we’ve got an reasonable interface at the desired scale, with twelve attacks in a tray, and a battle-interface thingy that slides down when you’re watching the fight, and slides up when you need it.

Here’s version 1 of the Combatotron 20XX, then:v1

Viola.  That’s the thing that pops up when it’s time to pick what your little monster’s going to do this go-round.  It’s nasty, and I’m going to replace it with one that’s more thematic eventually, but it gets the idea across.  All the dark gray buttons hold potential attacks, the light grey slots with numbers hold the attacks you’ve selected, and the exed out buttons are where your opponent’s attacks appear.  It also means we know the size and shape of our buttons.

Therion: Combat System

I have a combat system that works like this:

  • Each monster has a library of moves they know, and moves they are ready to use.  The moves they are ready to use is basically a tray of sixteen or so moves you can use in combat.  In between battles, you are able to put different moves in that tray from the list of the moves your monster knows.
  • Each combat turn , you get to see your tray of ready moves, and a pair of three- or four-slot bars above them.  You can either drag moves from your tray to that bar, or simply select a move with a tap and select the slot in the bar you want to put it in.  You opponent does the same thing.
  • This move selection process is double-blind:  You find out what your foe did at the same time as he learns what you did.  But it’s also multi-stage (until the bar fills up):  say you drop a move into slot 2, and he drops a move into slot 3.  Well, if you have a move that can beat his move in slot 3, you can drop it into your slot 3 (but he’s probably countering your slot 2).
  • Once all three or so slots are filled in, the moves are executed in order, with each monster performing its move simultaneously with the other.

So far so good.  But, this by itself turns into a game of Rock-Paper-Scissors.  Unless you randomly choose the same slot to start out, it will be 1) pick a move, 2) counter your foe’s move, and 3) pick a move, with the matchup of the third move determining who wins that exchange.  Let’s add a little more depth.

  • Moves have stats like “Accuracy, Defense, Power” and so on.
  • If a character uses a move that has a defense stat, and the other uses a move with an accuracy stat, then the second move hits if it exceeds the defense of the first move, and doesn’t hit at all if it does not.
  • A move can be both defensive and offensive (i.e. a riposte), but in this case the offense fails if the defense fails.

So, let’s come up with a set of moves using the combinations we can get by distributing 3 points between these stats:

  1. Block:  Defense 3.
  2. Power Strike: Power 2, Accuracy 1.
  3. Precise Strike:  Power 1, Accuracy 2.
  4. Riposte:  Power 1, Accuracy 1, Defense 1.

See?  Rock-Paper-Scissors.  All else being equal, a Power Strike will be more effective than a Precise Strike (doing twice as much damage), a Precise Strike will prevent a Riposte, and a Riposte will prevent a Power Strike.  And a Block beats all, leading to an obvious dominant strategy:  Just keep throwing up Blocks until your opponent tries something that’s not a Block, and oppose it with the move that beats it.  Which would lead to people spending entire fights with their monsters just sitting there, with their guard up.

Let’s add some more rules to mix things up.  First up, the balance of power:

  • Each move gets a base of three points to distribute between the move’s stats.
  • A move’s stats are not the final stats of the move, but are multiplied by underlying stats on the monster (e.g. a monster with a high defense will be able to beat a monster with a low accuracy when using Riposte against Precise Strike!).
  • Moreover, a move has three levels of mastery:  it is known (it’s a 3-point move), the monster is an expert (4-point move), or the monster is a master (5-point move).  So with enough practice, the balance may change.
  • Moreover, moreover, a move may garner an extra point of effect if it has monster-feature-based limitations (e.g. “You can only use this move if you have claws”).
  • And each monster comes with a signature move that has two extra points of effect (which does not stack with limitations point, as it is effectively a totally limited move).

So far, so good.  But while this takes things into stat matchups and brings the moveset away from Rock-Paper-Scissors, and towards Rock-Paper-Scissors-Lizard-Spock, the dominant strategy outlined above:  block all day and hope your opponent chooses an attack you can counter, still remains unbeatable outside of sheer stat-based pwnage (e.g. I’m going to max out my monster’s Accuracy and Drop a Precise Strike on him every time he blocks).

Let’s add some more, more things.

  • You can spend a point in a move to, well, move:  forward or back.  Monsters can back away and close, resulting in three ranges (close, mid, far).  This can be envisioned as a potentially infinite strip of tiles:  Monsters can be on adjacent tiles, or they can move apart, but they will never have more than two tiles between them.
  • Monsters can move past each other.  In effect, if you move into the other guy’s square, you are automatically teleported to the square behind him.
  • At the beginning of each turn, everyone automatically turns to face each other.  However, turning around inside a turn is a point of advancing when you are facing away from your foe.
  • Moves affect the square directly in front of them by default.
  • A point may be spent to extend the move’s range by one square.
  • Points may be put into any of the stats behind the character (that is, a move tracks the stats separately for the space on either side of the character, but most moves only bother to use the space in front.

Let’s brainstorm a few basic, 3-point moves for this system:

  • Charge: Forward 3.
  • Retreat: Back 3.
  • Advance: Forward 1, Accuracy 1, Power 1.
  • Withdraw:  Back 1, Defense 2.
  • Energy Burst:  Range 1, Accuracy 1, Power 1.
  • Guard:  Defense 2, Rear Defense 1.
  • Passing Blow: Forward 1, Rear Accuracy 1, Rear Power 1.

Now, if someone constantly uses Block, you can simply step behind him and smack him in his undefended back.  You can also dodge attacks by just not being where they hit.  Let us say, so that Advance is meaningful, that attacks land at the end of processing the move (this fits with Riposte failing if the defense fails), which means Retreat will get you right the heck out of range.

Okay, I think we’ve broken the stalemate condition.  Block is useful now, but not broken.  And once we mix in limitations (e.g. Fireball gets more range than Energy Burst, but requires that you have Fire Elemental Powers built in), we start to get a decent mix with just these stats.

But just these stats are still a little boring.  I don’t want a Final Fantasy or Pokémon style elemental weakness system, since this is a virtual pet and you can’t switch your monster out for one who’s not weak against your foe, but I want special effects that mean something.  For instance, a move that sets the field on fire, which damages anyone who is not reasonably immune to fire.

Let’s add if-then limitation points.  If (condition), you get an extra point that is spent thus.  For instance, perhaps you have:

Fireball:  (Requires “FIRE”) Accuracy 1, Range 2, Power 1, IF(Foe(“FLAMMABLE”)) Power +1.

So this move does twice as much damage if your enemy is flammable.  This allows some type-weakness style stuff that is way more flexible than a simple type table (which is not to say I don’t love type tables).  It also means there’s a good chance that if your opponent is filling his move tray with a range of moves that will be extra effective against a range of monsters, he will have one that’s really good against you, but if you survive the initial hit, you’ll probably be able to come up with a counter if you’re clever.

Maybe we’d better balance the condition stuff by saying there has to be a -1 condition (e.g. IF(Foe(“FIREPROOF”)) Power -1).

Who knows.  We’re getting complicated enough that the nuances will only come out in testing.  But now we have an idea of what we’re going to do.  The next step is to work out how we’re going to do it.