Main Site

Forum Index

Concept-Driven Lore Quick Look

http://www.youtube.com/watch?v=UvrZOYz60-M


Please use the larger player to view the video in its intended detail (480p). So, here's a demonstration of how Tethical can help you integrate a backstory (and other art) into something that's a more interactive experience for an end-user. On the backend, the engine reads in a formatted list of sections and entries. Those things have concepts associated with them, and the engine takes care of putting all of that together, meaning you don't have to manually indicate where some phrase should be highlighted. You would just use the phrase in the story, and the engine knows to highlight it (or prepare to highlight it). This feature will be used to help curate the demo (explaining some of the history around this project).

As I explained over in the proposal thread, this is a utility that lets you mix and match a lot of the information related to sprites. Everyone will get a chance to play around with it during the relaunch of the Tethical kickstarter, but I wanted to show off some of the features that made it into the program. In this post, I discuss using it as a no-nonsense way to replace colors.

--

The Base Image (for reference)

This is the standard FFT chocobo sprite (minus the parts I didn't bother to include in the format document, like the portrait).





End Points & Intersections Mode

A color replacement method where the program calculates and exposes where color ramps end and where those color ramps intersect. This mode gives the most control (without forcing you to micromanage all the colors).







End Points Mode

A color replacement mode where just the end points of color ramps are exposed by the program. This essentially lets the user set dark and light values, and the program figures out the middle values.





Intersections Mode

A color replacement mode where only the intersections of color ramps are exposed. This mode lets the user set a minimal number of colors in order to recolor the sprite. It's not suitable for every image, and it relies heavily on perception-corrected hue shifts.




A black chocobo accomplished with 3 reference colors.




--

Understanding the Underlying Color Technology

When the program loads an image, first it removes all the parts that aren't requested by the user. Then it iterates over the image's pixels, storing unique colors. In other words, if the user is only concerned with the arms of a sprite, the program is only going to consider the colors that the arms use (as opposed to, say, the portrait). That's important, because the program can mix and match other sprites (in effect, remixing them). This color-specific example doesn't do that, but hopefully you get the idea.

From Unique Colors to Color Relationships

Step one is to get all the unique colors in a given part of the image, but just having all the colors in the sub-image isn't enough to simplify anything. Imagine if the program presented you with all 16 unique colors of a sprite. You'd have to set all of them, just as though you were doing it in a graphics editing program. I mean, imagine if the sprite had 160 unique colors or 1600 unique colors. So, to simplify that, the program goes about figuring out how the unique colors are related. Once it's got the colors laid out into color ramps, then we have a lot of interesting information at our disposal. Obviously, it's an easy thought to set out to replace the two colors at the edge of any given color ramp. That's the end points color replacement method.

End Points and the Codominant Pair Color Relationship

If we consider two colors in a pair, how are they related? In the codominant pair, it treats both ends of the color ramp as significant. In other words, we walk directly from the starting color to the ending color over a perceptual color space, and the program lets you set those two colors separately. Because both of the colors are significant, there's no extra information needed to make color choices.

Intersections and the Major-Minor Pair Color Relationship

Where intersections are concerned, if one intersection goes to another intersection, the relationship is a codominant relationship (where the colors at each intersection are significant). If the intersection goes towards an end point, the relationship is a major-minor relationship, where the change in hue and lightness are used in tandem to morph the significant color at each step (creating a new color at each point until you have a replacement for all the insignificant colors contained in the ramp). Effectively, you get a perceptually correct hue shift (based on the original colors).

Filling in the Gaps with Minor-Minor Pair Color Relationships

When two insignificant colors wind up next to each other in a color replacement method, they are put into a minor minor pair. It's exactly like the codominant pair relationship, but it happens after all the other more important pairs are set (and its values are set implicitly by other things in the color map).

Putting it all Together

So, behind the scenes, the program does a lot of complicated color analysis. However, that's exactly where you want the work to be done. Because it does all that analysis, you can set a couple of colors (check out the charcoal chocobo) and get a pretty good result in the intersections mode (with effectively no knowledge of color). You can also get a very controlled result with the "End Points & Intersections" mode. It requires a bit more knowledge of colors, but you can use the suggested color lightness (in association with the color select dialog) to gauge what might be an acceptable color (re: you can pick a color at random and set the lightness to the right range).

http://www.youtube.com/watch?v=AkJJKmmcG6k


Play it on the web (~110MB): embedded demo.

Download a desktop edition: versions.

--

Why, yes, this is made with Tethical's engine. Some of the things Passage happens to share in common with sRPGs in general are: (1) maps (the field), (2) units (the cards), (3) menus (hidden beneath cards), (4) concept of equipping, (5) concept of tactical movement, (6) player phase/enemy phase battle flow, (7) per-unit skills, (8) hp bar, and (9) damage counters.

Anyway, this is the first playable demo I've released, so there will be issues. Kindly report them here, and bear in mind that I've only got a Windows machine to test this stuff on. Though the underlying engine is supposed to properly target Windows, Linux, and Mac, the Mac installer section made a zip file of all things, so I'm concerned.

Thanks in advance for checking this out.

So, one of the things that came up in the survey (and I don't know who to credit with the idea because it's anonymous) is the lack of a character generator (re: RPGMaker has a character generator). Now, I'm not partial to the name "Character Generator", and the strictness of the RPGMaker one that comes with the free version I played with is super-restrictive. I'm also not one for making solutions to one-off problems (i.e. making one type of character over and over).

Anyway, my thought was this: what if I write something that describes the sprite formats I already have? In other words, what if I write a program that can tag certain frames (the pieces of the sprite) as arms, legs, heads, etc? And what if it could load a lot of different sprites in that same format and tag those sprites (as male, female, etc)? Then, it could use the sprites as an input, let you pick the parts you want, and output what's known in this community as a "frakensprite". Furthermore, I already have enough code related to colors from the sprite animation program that I could allow those things to be recolored pretty reliably (with very little knowledge of color theory).

This program might become part of the second award tier, followed by the sprite animation tool, followed by the control panel.

So, quick recap. Kickstarter is going on, and I've been taking the month as downtime to do some of the things that are more game-related than engine-related. This is just the next thing in that process that I wanted to accomplish over that 30-day period.

For a long time now, I've wanted to pursue removing the "kill everything" goal from its prevalence (or its in-vogue use) in story events in these types of games. Now, I have no problem with that goal as it relates strictly to battle; getting out alive may necessitate it; clearing out savage monsters may require it; protecting a target may make it a tempting option (for expediency). My problem comes in when games apply it to non-battle scenarios (i.e. situations without appropriate context).

Now, how can the current system realistically be adjusted to avoid over-dependence on kill-everything tactics? For one, provide the player the opportunity to actually plan their own encounters; this process can go easily between the encounter transition and the formation screen. This process can even inform the formation screen's behavior. Secondly, provide a different set of goals. Lastly, plan for failure.

So, what would such a system be called? Anything related to battle seems to presuppose kill-everything tactics. Calling it any variation of "plan" seemed tedious. I settled on "Rendezvous" (in part because of the word's use in the franchise). Here's the mock-up of what the rendezvous system would look like:


A Flattened Top-Down View of the Map




A Flattened Side-View of the Map



How does difficulty factor into that? If you have a really good tactic, such as someone online finding a sure-fire win for a given scenario, that would effectively defeat the system. As an example of that, imagine if you're given access to a winning tactic to place your ranged units on the high ground at the start of a battle versus a host of short-range melee units. There's probably no real challenge in that.

What can be done about that? For one, limit the player to simple tactics if they choose a simple difficulty. Tactics are broken down by potential company counts; this simulates complexity of maneuvers. Simple tactics require a maximum of one company. This relates directly to practically all battles in FFT. Yes, there may be some distance between the units of a company, but they're all still in the same sphere of influence to begin with, with nothing really differentiating their position. This also doesn't prevent the alternative goals from being pursued.

What happens if you increase the difficulty? You have access to more complex tactics; higher difficulties result in more complicated (and potentially more useful) tactical approaches. This happens at the cost of having to deal with much stronger enemies. AI units can be made to appear to plan to handle whatever general observable company size you have. In other words, if you roamed around with 50+ characters at a time for the past 10 battles and took 3 companies into battle each time, you can expect your enemy will have heard of this and heavily fortified their positions if they knew you were antagonistic to them. Because you aren't required to kill everything to win, this is still a balanced situation. However, you might fail several times (at a cost to unit morale and currency, since you'd probably have to pay non-fanatical units to listen to your orders).

So, what are some of the side effects of this system? Most notably, the planning for failure hopefully keeps unwanted casualties on your side to a bare minimum (something probably important for perfectionists) without forcing you to do so if you don't want to (pick an emergency exit tactic that doesn't care about your unit's lives). Secondly, it can support a system where your choices actually reflect your alignment. In other words, if your character is good, it doesn't have to be good in name or just be "on the side of right" or the unassailable protagonist. If your character is evil, it's also not just in name. Decapitate your enemy's leaders, take prisoners, trick your enemy's soldiers into thinking you're surrendering -- then attack them; you're a bad character, and you ought to be given the opportunity to be that (and suffer the consequences of good units disbanding, having to resort to black markets because no legitimate business will sell you weapons after you get a reputation, etc).

Anyway, that's the plan. The basic tactic would be called "Brute Force" with a company size of 1; higher difficulties would get access to a "Brute Force with Reinforcements" tactic (potentially no company size limit depending how far up the difficulty curve you go). The per-company unit counts expand in that area (if you have 3 companies, you'll pick 3 sizes). Exit strategies offer the ability to trap monsters, take prisoners, plunder captured units, search the map for treasure (limited by skilled units available in unit list), and many other things (like specific limitations for airship and boat combat). Emergency exit strategies are for retreating. Commencing advances to the formation screen state. The map I used for this mock-up is the "Inside of Riovanes Castle" map you can find here: http://ffhacktics.com/maps.php?id=7

I have a list of planned tactics, exit strategies, and emergency exit strategies if anyone's interested in seeing those.

So, I'm doing the scene from when Dante fights off demons in the intro of the Jot5 patch. Now, if you haven't seen the original, you can watch a version of it here (~6:35): http://www.youtube.com/watch?v=OHaZFMdTZ_U

Here's the new stuff I have to play with:

• A new (custom) map.
• 6 Effects.
• A bat effect.
• A remembrance of the HUD off the actual game (goes from yellow to red).
• Names. Dante is becoming Durante. Vergil is becoming Vergilius (maybe Virigilius).
• Fonts. Map title font (maybe something grunge?), HUD font, speaking text fonts (dark brown and red).
• Map Title Background. I need to make something for this or have something made.
• Music. Some combination of these two tracks (from nosoapradio): http://darkabstraction.com/showOff/ffhackticks/DST-Pariah.mp3 and http://darkabstraction.com/showOff/ffhackticks/DST-Arches.mp3

--

So, now is your chance to chime in if you want to. Have something cool that could be added in? Mention it here! Practically everything can be changed. For instance, if you think some effect would be more appropriate in dark red, I can do that! Let everybody know in this thread.

Stab Up



One of the effects from a Jot5 event (in preparation for a demo event in the Tethical engine at Elric's request). This is simplified from the FFT version because trying to tackle the amount of particle effects in this particular effect manually will not turn out well. One left to go at this point before I can actually start on the event.

Castle Vergilius





A replacement map to go with the effects! Now that the water of the previous map is an endless fall, perhaps a flurry of bats will show up to the event?

Cat Scratch



One of the effects from a Jot5 event (in preparation for a demo event in the Tethical engine at Elric's request).

Morning Mandalia



Side-by-side with vanilla Mandalia: 002, 003, 004, 005

This map is actually geared to be an event map, so it's designed to look best from the view in the thumbnail. The event will be part of the kickstarter demo video.