Ludeus Maximus

This is a scaling down of my real-time-turn-based idea. Tactical RPGs like Final Fantasy haven’t had many changes to their combat system in the last ten years. Generally it goes like this: select where to move, select what ability to use. Although it remains to be seen how RPG fans will accept a twitchier combat system, I think I have an answer.

An attack consists of a series of button presses, much like a fighting game combo (though obviously less complicated to pull off), each of which adds damage and/or effects to the stack. The final result of the attack, then, is whatever the player makes of it. This lets players tailor their attacks perfectly to the situation, creates impressive Street Fighter-style visuals, and requires a bit of finesse that could inject some much-needed excitement into a stale genre. Enemies fighting back or blocking would add even more twitchy spice to the soup. How each state or attack mixes with others would be the essence of the design of course, but you could have some pretty interesting times with context-sensitive abilities or limited mappings (you can only have four “active” abilities, each assigned to a face button) or even sets of abilities swapped in by hitting R or L.

Example: A to trip, B to stab, X to uppercut, Y to knock down. The player does X-Y-A-B. Knock down only works once in the air but does good damage, and once knocked to the ground the trip ups stab damage.

Example 2(more exciting): A is an ice bolt, B a hammer, X a blinding light, and Y a grasping vine. Y-X-A-B. The enemy is held in place so they can’t turn away to avoid the blinding light, then frozen and smashed into tiny pieces. Now I want to make a game all about smashing your enemies into various entertaining shapes and collecting their corpses, which give you ability bonuses based on their arrangement. Or perhaps you use them as puzzle pieces.

This one is not very feasible.

Basically you create a weapon editor, map editor, creature behavior editor. These things are fully featured, with intuitive UI and simple to use, while also allowing access to the underlying code. You populate it with a bunch of sample 3D models for a variety of settings and boom. Include instant action, multiplayer, and single player and let the entire game sort itself out. Of course you’d also want to make an example scenario with all of your team that would sell the tools package and show off your skills, but the whole point would be the editor (see Neverwinter Nights, a truly awful game made good by user content only). I don’t think it would be that hard, if the editors were, rather than game development tools, user-oriented creation machines, to see a huge community cropping up. The entire ModDB community would be transformed overnight from a failed junkyard of mods into a frenzy of Generic Shooter scenarios that all, at the minimum, were playable. Besides, people would buy this game on name alone. And you’d get the prize of first fourth-wall-breaking game title (I think).

I try not to hate on industry designers too much, but sometimes the decisions they make are so obviously boneheaded that I want to smack them. Team Fortress 2’s new arena mode is the most fun update to the game yet made, but contains a ridiculously bad team system. The maximum team size is 8v8, and anyone who joins over the limit is forced to wait in a cue (obviously servers should just be made 16 player servers, which isn’t totally Valve’s fault) for the round to end. On rounds end you join whichever team lost, and every member of the winning team stays on. Not only does this make for a lot of complete domination by one team, but people can’t switch to balance it out. People from the winning team who die are put in the queue, so they can be put on the losing team, but this just means that you never get the satisfaction of a complete win unless you never die and also frustrates players who are leading their team in points but die one round. Which brings me to another matter. The arena mode gives a mvp list for each team at the end of the round, but still boots losers randomly. Shouldn’t the best players of the losing team be kept on? Or better yet, how about just letting people join teams like every other counter-strike clone mode and sort it out for themselves. Sure, team stacking sucks, but you could have a balance check system if you really wanted to (again you run into the problem of switching the best players to the other team, which makes all their previous efforts be for naught). And you could keep the old arena system around and rename it randomswap while you’re at it. Every single player who has to wait in spectator for a round is being directly pissed off by the developers. Every server I’ve been on has had angry players in it who hate the system. Whoever came up with the team structure for arena mode should be fired and forced to work designing movie tie-in shovelware for the rest of his career.

Edit: Oh and while you’re fixing things, add the mvp display for both teams to non-arena mode games…

And all those claims of Valve’s iterative design methodology and massive playtesting must be bullshit given how bad their last few updates have been. Or their designers just can’t balance things properly. Or both.

http://www.gamasutra.com/view/feature/3765/the_designers_notebook_the_tao_.php

You can see in the comments section of this article the deep feelings on designers’ parts about Theory Vs. Practice. If you take a look at the feature section of Gamasutra or read up on back issues of Game Developer you’ll see that there’s a lot of theory and very little practice. Most people try to give examples when writing articles, but very few people have written articles like “Balancing Starcraft” or “Level Design in Open World Games” or “How We Designed Grand Theft Auto”. Noone talks about what they do at work every day or how they actually came to make their design decisions, which I feel is very unfortunate given that there are tons of people like me (and experienced designers for that matter) hanging on to their every word. I’m guilty of this too, of course, given that I haven’t released anything yet. But I try to give practical examples or point out design flaws in real-world games. Some of the best articles are practical how-tos, some of which are useful even for non-programmers: http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php

The most frustrating thing in the world for any player is getting stuck. How do you prevent this without being too obvious in quest descriptions or environment art?

The reason players get stuck is either lack of clear communication on the part of the designer or “bad” intuition/thinking on the part of the player. Or both. In many cases the designer fails to communicate what actions the player can do, where the player can do them, or how the player has to do them. My frustrations with Resident Evil and Okami recently have been a result of such bad player thinking and design.

In Okami I misinterpreted the villagers comments about withered trees to mean the giant spirit trees rather than the trees in the village. Partly, this is a result of ambiguity and partly not talking to a certain NPC. But both problems could’ve been fixed by a little bit of helpful writing in a single line of NPC dialogue. And this frustration resulted in about two hours of wasted time. That and the hint dialogue on the sign leading to the next area seemed to suggest an entirely different solution to the problem.

In Resident Evil I tried shooting Ashley (who was clamped to the wall) but didn’t notice that you could shoot the clamps specifically (I think it took more than one shot to break) and didn’t make the logical leap from being able to shoot locks off doors to being able to shoot the clamps, which, given that there are many things in the environment you can’t shoot and break, makes sense. Another leap I didn’t make was kicking the chains off doors to open them. In this case the chains should partially break on the first kick so that the barrier doesn’t seem impassable.

All of these problems, in my mind, can be taken care of by trying to think from the players’ perspectives as well as good playtesting. If and when they do occur, the cheapest solution is often to fix dialog  or add a more obvious hint that can only be accessed after a certain amount of tries/time (puzzle designers have this figured out). Failing that, communicate the mechanics more clearly in tutorial/by gradual or obvious introduction. These sorts of things cause players to quit games and feel intense anger/annoyance/dissatisfaction and so should be a high priority for elimination.

Behind all the pretty graphics and class-specific visual profiles and almost-good balance that people raved about when Team Fortress 2 was released is the unsung hero, satisfying kills. Sound is a huge part of the feel of a game and it contributes a lot of the magic here. The sound of crits, gibs, and point captures are all very satisfying and meaty. The shotgun, which is shared by several classes, has a report that’s a punch to the gut. The gibs and ragdoll physics are also exaggerated just enough to be comical while also reminding you of your weapons’ powers. The kill freeze frames take some of the annoyance out of dying as well as pointing out your foe and domination/revenge assists a standard human action with graphical highlighting.  The feel of shooting rockets or stabbing backs is subtly augmented by great blood effects, which also do a good job of informing the player which shots are hitting. TF2, while not a perfect game, certainly has all the intangibles. It feels great to play.

The midpoint of interactive freedom between Pong (least free) and Garry’s Mod (most free). GTA is a sandbox game with linear missions thrown in to tell a story, whereas Hitman is a linear narrative with sandbox style missions thrown in. Sandbox on rails allows for players to come up with a plan and create unique solutions to the linear sequence of problems presented to them, and represents an optimal amount of freedom vs. narrative control. Would work great for a cinematic 2 hour game experience as well.

The only game I can think of that uses this system is Toribash (albeit in a limited way with only a timer), but it seems like it would work for a lot of titles (and be hailed as “innovative” to boot). Essentially real-time but split between turns. During each turn something is happening in real time controlled by the player/AI. Between each turn, whatever you need to happen between turns takes place.

Now many games have pause features which allow queuing of moves/actions that make this a player-controlled option and many simply control the timing of the game so that things don’t happen during turns, but I feel there is still a way to make this interesting. Considering the tactical RPG (exemplified by Final Fantasy: Tactics) or the squad-based shooter tactics genre (XCOM or Jagged Alliance 2). Both of these could retain the same turn system but allow the player to do the shooting, stabbing, or beating up in real time. You could even impose square/movement distance limits and attack area of effect as UI elements on the ground.

A real time turn based beat-em-up sounds great. The only danger with this system is clearly leveraging the turn based nature in order to make the game better, not just different, from a real time game. Real time turn based allows for planning during enemy turns, abilities which are timed by turn or real time, and some interesting time management by the player (just remembered that Worms has a relevant turn timer and is real-time during turns, so its the best example even if it uses the turns rather traditionally) to squeeze those last actions into the final seconds of a turn. Now you’d have to do a lot of design work to make sure it was fun, but achieving the right mix of tactics and action might be easier with a RTTB system. Now wheres my patent?

While I wouldn’t call it officially complete since it hasn’t been cleaned up yet, here is my design document for a multiplayer Source engine mod (though the idea is engine/mod-independent):

Katana
A Source Engine Modification

Introduction:

A multiplayer action game set in feudal Japan, Katana pits teams of players against each other in brutal melee combat. Controlling authentic samurai weapons with intuitive mouse movements, the player slashes, thrusts, and parries his way to victory. His honor and his life depend on his martial prowess. The Revenge game mode pairs the familiar round-based structure of Counter-strike (CS) with a simple equipment selection screen, and strives to recreate the deep skill-based combat that has made CS the most popular online multiplayer shooter of all time. Duel challenges players to defeat a single opponent in close combat, which often ends in seconds. Finally, the Melee mode plunges each combatant into a frenzy of violence with no clear sides, where strength of arms alone determines victory.

Fig 1: Face Off/Title Screen

Game Modes

Revenge:

In this game mode the ronin are avenging the death of their lord (due to defeat in battle, political maneuvering, or treachery) by attacking the clan of samurai responsible. Their objective is either to kill all enemy samurai or the clan lord. The lord is a non-combatant NPC, having been incapacitated by previous injuries or sickness, but has the standard amount of health, and is usually positioned in a well protected area. The samurai have to defend this location and their lord from the ronin, who start outside the area and must force their way in.

Matches are organized into rounds of 2-5:00 each (although this should be set to whatever you want with a server-side variable), and players are divided into two opposing teams (Samurai and Ronin in this case). Auto team balance and auto team select will be necessary features, and the team selection screen can be brought up at any time by pressing comma. Once the player picks a team they are shown the weapon selection screen, which may be brought up at any time (during a round or after death) by pressing period.

Fig 2: Team Select

Fig 3: Weapon Select

Melee:

In a whirlwind of violence, samurai and ronin alike are thrown together into hectic melee combat. Every man tests his honor against all challengers on these bloody battlegrounds. Both continuous respawn and timed modes should be available, with configurable time and kill limits. In melee mode the player picks a skin rather than a team, but selects his weapons normally.

Duel:

Players face off one on one in a small level. The survivor continues dueling unless he chooses to pass his turn, giving his spot to the person next in line. Spectators can watch while they are waiting for their turn. The projected number of players for an interesting duel is around five. Time limits should be set to around 1 minute default, but as usual they can be set to 0 (infinite). In duel mode the player picks a skin rather than a team, but selects his weapons normally.

Fig 4: The Ronin

Figure 5: The Samurai

Fig 6: The Lord

Weapons

The five weapons are the wakizashi, katana, no-dachi, naginata, and yari. The weapons the player is carrying are automatically listed in inventory slots 1-3 in descending order by reach. Weapons are dropped once a player dies, and may be picked up at any time by aiming at them and pressing F. Pressing G will drop the weapon the player currently has out. The player may select either right (default) or left handedness in the options menu, which determines both which side the weapons are worn on and their starting positions*.

Weapon Damage:

There are two potential approaches to damage modeling. One is to check for a hit and simply apply a flat weapon damage stat (modified by hit locations) to the player hit. The other is to calculate weapon momentum, total area of player hit, distance between players (ie what part of the weapon hits them), both players’ momentum and hit locations to reach a total. Game balance is the ultimate arbiter in this case, but for now we will assume the former because it is much less complex to program and think about. The reason I have included the second option at all is that a complex weapon handling system might be worthless without a damage model that makes full use of it. The second damage system might end up approximating the first, or it might make the game a truer test of skill. Keep in mind that features of the second may be added to the first to produce a middle ground between complexity and playability.

Wakizashi: 50 slash, 35 stab
Katana: 75 slash, 50 stab
No-dachi: 100 slash, 65 stab
Yari: 50 slash, 100 stab
Naginata: 75 slash, 100 stab

Fig 7: Weapons

Combat

When the round begins players’ wakizashi and katana are sheathed at their side and their no-dachi, naginata, or yari sheathed and/or slung across their back. Selecting a weapon slot by the corresponding number key and left-clicking (with the standard quick switching option which can be toggled under keyboard/advanced *perhaps quick switch should be on by default?) draws the weapon. When using either a katana or wakizashi, if the player clicks (left click slash, right to stab) right after they draw they perform iaijutsu, drawing their sword and attacking in one fluid motion. Slashing iaijutsu sweeps across the front of the player horizontally, while stabbing results in a forward lunging thrust.

Fig 8: Iaijutsu Attacks

Left clicking activates attack mode, which persists as long as the mouse button is held down (perhaps there will be a toggle option for this). During attack mode moving the mouse swings the weapon in the direction of the mouse movement, dealing damage to any players the weapon’s edge comes in contact with. Once attack mode is activated, right clicking readies a thrusting attack, which is executed when right click is released. Once a thrust is complete the weapon returns to its standard position, and when the left mouse button is released the player exits attack mode (which also returns the player’s weapon to its standard position, barring cases where the left mouse button is released mid-thrust).

Fig 9: Attack Mode

Fig 10: Thrust

Right clicking when in standard mode activates parry mode. In parry mode, which continues as long as the right mouse button is held down, moving the mouse positions the player’s weapon to intercept incoming attacks (either deflecting or stopping them completely). Depending on the relative distance from the center of the screen and direction, the blade moves into different positions. If an attack doesn’t hit either the deflection or parry area covered by the player’s blade, the attack hits normally. Parry mode also slows the player’s movement significantly. Once right click is released, the weapon moves back into its standard position and the player resumes standard mode.

Fig 11: Parry mode

Potential Expansion:

Some possible additional features are armor, an extended set of melee weapons, ranged weapons, hand-to-hand combat, and horses and mounted combat.

Conclusion

Melee combat using the Source engine has not been fully exploited by Pirates, Vikings, & Knights II or Age of Chivalry. A more realistic and fatal combat system, along with the use of the popular setting of feudal Japan, will bring new players to a genre not often explored on the PC. The coding and art resources required are also significantly simpler than many other Source modifications which have already been successfully released. The design is also easy to scale if any features need to be cut or expanded. Concerns about player base notwithstanding (as seen by problems with Dystopia and other well-made Source modifications), this project would be excellent for a portfolio and as an exercise in innovation.

Hara-kiri/Seppuku – the player dies, but the death doesn’t count on the scoreboard/against their K-D ratio. Or against score, which is called honor (what about ronin)? *Useful if only to end really long rounds (would people use it?) probably not worth coding until after the first release.

Technical/Planning Stuff:

Beta Targets: 4-5 maps, 5 models (one for each weapon) with slightly different texturing/coloring for each side, 1-2 player models with 2 different textured clothes for each side, completed UI elements/game menu reskins, kanji sprays? (easy), an installer, website.

Art Needed: A screen (window with breakable paper part?) that can be attached to others, bonsai trees, zen rock/sand garden? textures, several pots/vases, Japanese sandals, sword/weapon racks, scrolls, teapot, ikebana?, armor/arranged?, origami??, sake flask, lantern,

Too short. Thats really all I have to say. The first 2/3 of the game are a tutorial. The last 1/3 is a blast that leaves you wanting much much more.