Thursday, May 3, 2012

Open Image Annotation Initiative

Long story short: A tool to let you annotate any image and embed the drawings you made to that picture, while having the original file stay intact.


To senior artists, imagine you want to give critic or feedback to another artist's work. Perhaps the anatomy of his drawing is wrong. Perhaps you'd want to draw in red lines how things should be.

Normally you would open Photoshop for this, but what if you can sketch your notes for any image while in the browser, with pen tablet support?

To artists, imagine you are keeping a collection of files for visual reference, or visual peg, as they say, and you want to use your Wacom pen to sketch notes on your reference images, while keeping the sketch and the image separate from each other?

You could save it as a Photoshop .PSD file (because you need layers), but what if you want to annotate an animated .GIF file?

You could save the annotation sketches as a separate file, perhaps a transparent .PNG if you're clever. But that's messy.

What if you don't want extra files to manage? What if you could add "layers" to any image file type? "Layers" on a .JPG, "layers" on a .GIF, "layers" on a .PNG?

(I say layers in quotation marks because this proposed tool does not really add layers in a technical sense.)

The idea is to embed an archive to an image, with the archive containing your "layers" as separate, transparent images.

This hidden archive trick is not meant to be secretive; the file will be renamed to the extension of picture.zip.jpg, for example, if the filename is picture.jpg.

To programmers, you can perhaps see that is not as efficient as true layers as in Photoshop .PSD files. Perhaps, who knows. (Note: the open-source equivalent of .PSD files, .ORA files, are actually just archives. Unfortunately, .ORA is still in a messy state right now to be usable.)

But this tool is not meant for heavy image editing like Photoshop, it is a tool for adding quick notes and annotations to any image.

If you are still not convinced, the annotations can be saved as vector graphics data, ensuring a very small bloat on the original file. Perhaps as 8-bit .PNG files, if need be.


Specifications

There are two variations on how the tool can add sketches on top of the image.
  1. The sketches are saved as either .SVG or .PNG and stored in a zip file, embedded into the original image.
  2. Same as in no. 1, but the original file is included in the zip to be embedded. And instead, a new image, a mixdown of both the original image and the sketches will be the "front-facing" file.
Using the mixdown will add more file size, but ensure that the annotations can be seen in any web browser, in any image browser, without any special program, and yet the original file can still be extracted with any standard archive manager.

If file size is not an issue, the mixdown approach is more useful. To compensate, the mixdown image can be saved in a small file-size, low-quality .JPG if the user prefers.


Transparent Images

 

If the original image has transparency, the user can choose to use a background color to replace the transparent parts (for example, to add a white background on a black drawing to ensure it can be seen, even if it was posted to a forum that had a black background). A checkered square pattern will also be possible.


Pen Tablet Support

 

As noted, the tool promises pen tablet support, such as in Wacom pens. Pressure sensitivity is important, and attaining an, at least rudimentary, recreation of pen or pencil-esque quality is important for the tool to be artist-friendly.


Vector Graphics

 

Typed notes will also be possible, as well as simple shapes like a circle, perhaps an arrow, etc. The tool will allow you to edit the vector graphics (which means the SVG data needs to be embedded, so it can be recreated when editing annotations).


Target Platform


As for what the tool will be made in, I'm currently thinking between Python (as a standalone program), or Flex or HTML5 (as a web browser plugin). Perhaps create both standalone and browser versions.

Out of all of them, I am most familiar with Python, so for now, it will be a standalone program, made in Python, using numerous libraries such as wxPython, cgkit, PythonMagick, etc. Here are the plans for that.


Viewer Program


In the plans is also a lightweight tool to view these kinds of images, and allow toggling display of the annotation sketches. Preferably it would be a plugin to your favorite image browser and web browser. Among the two, a web browser plugin is the simplest path. So that will be given priority. As a start, a Firefox add-on for this is planned.


Open Source

 

I heavily prefer that this be released in an open-source license, but I am unsure which license to use. GPL is seen as restrictive for other people, and yet all my favorite digital content creation tools use GPL (Blender, GIMP, Inkscape, MyPaint, etc.).

I would not want there to be closed-source derivatives/modifications to the Open Image Annotation Initiative, because a tenet here is it should still be usable without any special or proprietary plugins (the original file can still be extracted using any standard archive manager).

The tool will use widespread and readily available data formats: Zip, PNG, SVG, and perhaps JSON or YAML for miscellaneous information.



For interested programmers:


Git repository of work-in-progress here: https://bitbucket.org/AnomalousUnderdog/openimageannotationinitiative

Friday, February 10, 2012

Attributes

Here is what I have been thinking about this whole time:

  • Arm Strength: Powerful arm movements. Affects melee damage, and climbing
  • Arm Dexterity: Quick, flexible arm movements. Like in martial arts. Contributes to actions like parry, flurry strikes, and acrobatic movements.
  • Arm Endurance: Maximum stamina for melee attacks.
  • Leg Strength: Powerful leg movements. Affects melee damage for kicks, faster travel time (i.e. speed)
  • Leg Dexterity: Quick, flexible leg movements. Contributes to actions like evading, dashing, tumbling, acrobatic melee, and proper footing in melee attacks
  • Leg Endurance: Maximum stamina for movement.
  • Hand Dexterity: Fine motor skills. Contributes to actions like skullduggery, playing of musical instruments, or using firearms.
A high leg strength but low leg endurance means the person can do a short burst of fast sprinting, but he will tire away quickly.

A runner with leg endurance means he may not move fast, but in the last 200 meters of a marathon, he's still going at the same pace, while the others are too exhausted. Essentially he's a distance runner.

Separating arm strength and leg strength was because I figured there are brute-like enemies who have overbuilt upper body muscles, but slender legs. Top-heavy, as they say.

Separating arm dexterity and leg dexterity is maybe too much though. Though I understand there could be martial art styles that concentrate on kicks only. I think I won't go that far though, so I'll combine them.
  • Arm Strength
  • Arm Endurance
  • Leg Strength
  • Leg Endurance
  • Dexterity: Quick, flexible movements of limbs. Like in martial arts. Contributes to actions like parry, flurry strikes, acrobatic movements, dashing, evading, and proper footing.
  • Hand Dexterity
Having separate endurances for arms and legs meant that I'd separate stamina for arms and legs. Meaning the legs can get tired but the arms don't yet.

I figured they could be combined as well, as when someone is exhausted, he wouldn't be able to use both arms and legs anyway, so it doesn't make sense to have separate stamina for arms and legs.

The stamina they use are shared, in a way, though consumption wouldn't have been proportional for both depending on the action done (movement would consume more leg stamina and only little arm stamina, attacks consume arm stamina and a fair amount of leg stamina, because proper footing when attacking can also be tiring).

It then made little sense to separate endurances for arms and legs. So combining them:
  • Arm Strength: Melee damage for punches and swings.
  • Leg Strength: Speed. Melee damage for kicks.
  • Endurance: Maximum stamina to expend when doing actions, like moving, attacking, etc.
  • Dexterity: Quick, flexible movements. Like in martial arts. Contributes to actions like parry, flurry strikes, acrobatic movements, dashing, evading, and proper footing.
  • Hand Dexterity: Fine motor skills.
I'd then rename Dexterity to Agility, then Hand Dexterity to simply Dexterity:
  • Arm Strength: Ability to exert powerful force using the arms. Melee damage for punches and swings.
  • Leg Strength: Ability to exert powerful force using the legs. Speed. Melee damage for kicks.
  • Endurance: Ability to sustain force for an extended period of time. Maximum stamina to expend when doing actions, like moving, attacking, etc.
  • Agility: Quick, flexible movements of limbs. Contributes to actions like parry, flurry strikes, rolling, tumbling, evading, and proper footing. Also contributes to melee damage. Reduces charge-up time for melee attacks.
  • Dexterity: Fine motor skills. Nimbleness of fingers.
I could change Arm Strength to simply Strength and Leg Strength to Speed, but I have characters that are slim, lithe, but have high kick damage, essentially high Leg Strength. It would not make sense that their attributes reflect a high strength score when they are slim and lithe.

Thursday, February 9, 2012

Garwolf Gives Up


I was mulling about how Garwolf gets his forceful closure with Serin and this is the scenario that always plays in my mind. It is unusual that this pessimist bypasses the first four stages in the Kübler-Ross five stages of grief.

Garwolf trudges on, disregarding his grevious wounds. "I need to save her", he says. 
Mayev can only watch in despair. Is this what love really entails?

Arriving at the scene, he staggers and stops, lets out a soundless gasp. Once he remembers himself he darts for a place to hide. At this point it all feels rather foolish. What a stupid notion!

He stays quiet and lets them pass in peace. A sigh escapes his breath as their last footstep echoes away. His vision lingers as his thoughts wander, "I wonder what do heroes do, when the world doesn't need their brand of saving."

Eventually Mayev finds him passed out. Dead birds dot the path.



Garwolf finds himself in a lady's room, his wounds dressed.

"Do not banter. They still bleed." Mayev inspects his face, her concern more than physical needs.

His face limps like a lifeless manikin, drawn in a perpetual stare, without joy, without hate.

"Sometimes," he speaks tentatively, "Sometimes I wonder. What it feels like to give up and surrender." He direct his gaze at her. "It would be so much easier.", he whispers.

While she could not escape the flattery, she shakes her head, "You need to rest."
As she closes the door, she could not help smiling.


Mayev kisses him, but something wasn't right. It was like kissing an unresponsive doll.

"No, no, no, no!" "What are you doing? Fight back! Fight back! You always fight back!"

To be continued... Garwolf will find himself fighting one last time before hope is fully stolen.

Monday, February 6, 2012

Bosses That Roam The Level


This is a good idea. The podcast mentions this great hate for the classic boss level wherein the boss is waiting at the end of the level within a closed-space arena. While I really have no intense hate for it, I also like his suggestion: bosses that roam the level.

A lot of games already do this:
  • God of War: where sometimes the boss is the level
  • Enslaved: where this mechanical gigantic dog chases you, though the events are largely scripted: defeating the boss is done in multiple parts, normal gameplay is interspersed with encounters of the boss, where it finishes with either you or the boss retreating, until you encounter it again, and in the final part the boss is meant to die
  • Dead Space and Resident Evil: where an invincible boss chases you around the level and the only way to kill it is to lure and trap it in a special way
  • Clock Tower: where a serial killer hides in various places in the mansion. unfortunately, the game has you needing to investigating those various places as part of the game

Its true that sometimes the arena-type boss level gets shoehorned forcefully into the narrative (why is the boss patiently waiting for you at the end of the level?). And sometimes when you see those health stations just before a big door, its a relief for the player, but it doesn't make sense in the narrative.

Do you guys know of any other games that do this?

Friday, February 3, 2012

Tactics Ensemble: Movement

This is an experiment on the movement mechanic of the combat for Victis.


The violet area is the limits of where the tiny white guy in the middle can move to.

While the game is turn-based, the map does not make use of grids. Basically I just used my idea from Death Zone Zero, which in turn, got its idea from RTS games in general. If you've played tabletop wargames, things work that way.

Movement is calculated as a stamina cost per meter, not a predefined value. He has, in this example, 100 stamina points, and movement is 2 stamina points per meter.

Other actions like attacking also consumes stamina, so the player has to be mindful of deciding when to conserve stamina for movement or actions. Basically the same with Action Points of XCOM games.

Furthermore, climbing upwards has a higher stamina cost of 10 stamina points per meter, which accounts for the irregular shape of the movement range.

The currently selected destination is shown with the X-mark on the ground there, with the distance to that shown at the top left, together with the total stamina cost to move there. You can see the stamina cost is roughly twice the distance. This is correct since again, I've set it to be 2 stamina points per meter. The disparity is from the fact that the terrain is bumpy, and since climbing upwards is more costly, the destination's stamina cost reflects this.

Tuesday, January 31, 2012

Input Recorder For Unity

Being able to record player input is invaluable for bug reports so players can submit their recorded play session and you can easily watch how the bug manifests.

After development, its also useful for the end-user to share his play experience to other people, or to allow other people to study other player's tactics.

So I saw this:


And saw how simple the input display was. So I went to try the same thing in Unity:


This only records input so far. Feeding those recorded input back to the game is another matter. Its also not possible to feed those data back into Unity's input system as far as I know. So I can't make Input.GetAxis() return the recorded input data.

Instead I would have to make my own system, like, say, RecordedInput.GetAxis(), RecordedInput.GetButton(), and so on. Feeding that data to the GUI system is also another matter.

Do We Need Annoying Small Enemies?


Continuing on that podcast, they mention this:

"Games should never include small scuttling enemies that walk across the floor or hover above your head and are really hard to hit and are annoying."

First, I have no problem with small enemies. Enemy variation is good, but I believe there is a wrong way to design small enemies. The podcast notes an enemy in Singularity with an enemy that can kill you with one hit. I"m afraid I haven't played that game.

But I do believe enemy attacks should always have a tell-tale sign. The more grievous the attack, the more evident the hint should be. This is regardless with the size issue, because enemy size is not the issue here.

About attacks that kill you in one hit, as long as the player can anticipate it and have a chance to prevent it, then I think its fine. Dark Souls have some characters that can kill you in one hit, but such attacks are slow in charging up.

In contrast, one mission in Valkyria Chronicles end up with a regular enemy anti-tank unit killing my full-health tank hero unit in one hit. No matter how I looked at it, I think that was really pointless.

So I believe there is a right way, and there is a wrong way of doing one-hit kills.

Each enemy has its own "gimmick", a behavior that circumvents the player's usual method of attack, forcing him to rethink his strategies. They really would have an easy but unusual way to kill them, and the failure is the game not hinting or encouraging the player how to find that out.

So I do hope Singularity's small enemy was designed that it has a weakness.

Hints should be implicit and part of the story. For example, the minotaur boss in God of War starts with a short cutscene of soldiers trying to fight the minotaur and failing horribly. That is enough hint for the player to get that this guy is not to be messed around with.

The podcast mentions the small parasitic enemies in Dead Space. I really had no problem with those enemies because I discovered early on that the assault rifle is an effective weapon to dispatch them. The assault rifle shoots low damaging bullets, but the magazine size is high. One shot is enough to kill one parasite (or more if they are clumped together).

So the game becomes a matter of having "the right tool for the right job". It was odd though, that his experience with this enemy was vastly different from mine. Perhaps he never bothered using the assault rifle.

The podcast then mentions about the big fat necromorph that spawns the little enemies, in that it was unfair, doesn't add any value to the game, and that there was no tactic to fighting them.

I would say instead the surprise there is it punishes greedy players who keep on getting loot. And really, once you've found out about the nasty trick, you would obviously make it a point to avoid falling for it again. You need to make sure to shoot its stocky limbs and not its belly. And do not stomp on its corpse.

Again, this is the idea of each enemy having its own variation.

Did they perhaps feel cheated that they found a type of enemy that they couldn't get loot from?