Wednesday, July 13, 2016

The problem of scope creep

Derek Smart explains what every game industry veteran knows: scope creep kills:
Once Chris did what he has done before by overreaching, increasing the project scope – then not listening to the very people he hired to build the game for him – he subsequently killed the project. Thing is, him – and every single dev (past and present) who has ever written a single line of code, designed any component etc – knew over a year ago that they simply couldn’t build the game Chris now envisioned once he got this crowd-funding windfall. And on the record, several of them told him specifically that. He didn’t listen.

You see, here’s the thing with videogame development. It can get away from you very quickly. Once a design scope changes, the budget tends to go out the window. And when key people start bailing, there are bigger problems to contend with because bringing new people up to speed takes a lot of time. Design and programming are not like art, modeling and audio, whereby any replacement can hit the ground running. And the longer it takes, the more it’s going to cost. And if you don’t have the funding to keep at it, the project is basically dead. Our industry is plagued with nightmare stories of things like this happening; to the extent that many a studio and publisher has folded as a result of a single project going sideways, even after the delayed project ships.
This is why I teach that the primary role of the producer is to SAY NO. If the producer is capable of reining in the designer and his inevitable bright ideas, and fending off the even brighter ideas of the suits and marketing people, scope creep can be prevented.

The thing is, even designers who know better usually can't help themselves. That's why the better and more visionary the designer is, the stronger the producer usually needs to be.

Tuesday, July 12, 2016

A programming vignette

This doesn't rise to the level of a "war story", but it does illustrate the importance of testing, checking your assumptions, and not taking anything for granted.

The cave environment in Krag Vargenstone is implemented using a tiling system, where individual graphics are duplicated over and over to draw the floor, the walls, and most of the scenery the player will encounter.  (We are using the excellent SpriteTile framework to make our job easier, which I highly recommend if you are planning to make a similar game.)  Most of the level is drawn in a level editor, but the player, the enemies, and the objects are placed as Unity GameObjects.  Sometimes a tile will be used as a placeholder to represent an object's location, but then replaced with a standard floor tile before the level loads.

I was investigating a graphical glitch where blank lines would occasionally appear in the gaps between tiles.  Having made a number of changes, I hit Play to test things, only for Unity to go completely unresponsive.  Not a single control would work, and I had to force-quit Unity from Windows.

A search of my code revealed no endless loops that could have caused the problem.  I narrowed down the changes I had made during that session -- often having to go through the force-quit and restart routine -- and eventually found that changing the size of the tiles in the level editor would reliably reproduce the hang.  This didn't smell right, but I had pursued that particular thread as far as it would go, so I fired off an email to the SpriteTile guy and turned in for the night.

One of the inconvenient realities of programming is that just because you can trace a bug down to a certain part of code does not mean that you've found the source of the problem.

The following day, I was able to look at the problem with fresh eyes.  Not surprisingly, the SpriteTile guy was unable to reproduce the error.  This called for a more intensive diagnostic strategy: if isolating a specific code change -- or point in the code history -- is unfruitful, the next step is to isolate a specific code statement -- or point in the code flow.  In practice, this involves ripping out or disabling all the features, and then adding them back in one by one.  Rather messy.

This strategy traced the cause to an unlikely place: not the tiling or display code, which I had first suspected, but the object placement code.  And that's where I saw it: an endless loop that I had overlooked in my search the previous day.  It belonged to a hackish section of code that was only present to test a particular new feature.  It was something that I had planned to rewrite and replace with a more permanent solution at some point.

The root cause of the problem was that this temporary code was set up to search for a suitable tile on which to place a treasure chest.  One of the suitability requirements was that the tile had to be off-screen.  It just so happened that changing the size of the tiles shrank the test area just enough so that every candidate tile was within the screen viewport.  The tile picker degenerated into running an endless shell game with no possibility of guessing a valid tile.

Another of the inconvenient realities of programming is that sometimes in the course of tracking down and fixing one bug, you discover another bug that has to be found and fixed first.  After all this, I'm back to the point where I still need to fix the blank line glitch.

Wednesday, July 6, 2016

Notes on the next project

Glen Rahman's design notes concerning Divine Right, which will be DevGame Project #6.

Divine Right was originally published in 1979 and went out of print after two editions, in 1982.The game had been very popular, but its designers, my brother Kenneth and myself, expected that DR would simply pass out of sight and out of mind like so many other games before it.

To our surprise and gratification, it kept appearing at conventions as a tournament game long after it had become unavailable and every now and then we were contacted by persons asking if it was ever going to be reissued. Then, more recently, the word "classic" began being applied to Divine Right and the designers dared to hope that we had perhaps managed to create something enduring.

Kenneth and I were already avid game-experimenters using mostly the Parker Brother's Risk system when we encountered a copy of Avalon Hill's Tactics II in the early 'seventies. Unfortunately, while there were things to learn from Tactics II, it had to be rated very lowly in the excitement category. But the appearance of Tactics II was our alert that some interesting things were happening in the gaming scene.

In the fall of 1974 this writer encountered a large Avalon Hill selection in a Minneapolis department store and bought Third Reich on the spot and, the next year, subscribed to SPI's Strategy & Tactics. Those were salad days, when even games as wretchedly-conceived as Oil War and Revolt in the East got thorough and repeated playing. Soon the designers were gaming regularly with friends. By 1977 we realized that we had learned enough to leave Risk behind and start designing in the state of the art.

The first serious effort carried all the way to conclusion was a fantasy game which we called Your Excellency. Divine Right players would promptly recognize Your Excellency as the prototype of DR. Some of the names, the CRT-less combat system, the diplomacy system, and the identity cards were all present. Believe it or not, as early as YE we had personality cards. I had been a frequent short story writer for the semi-pros and understood the strength that good characterization gives to a story. One night while Ken and I were play-testing Your Excellency on the kitchen table, it suddenly occurred to me to ask: Why couldn't a board game have characterization, too? The Personality card idea fell easily into place and it worked even better than expected.

From that moment on, we knew we had a good thing going. But the differences between the prototype and the eventually published game by TSR, Inc. were huge. The map looked nothing the same, being rather austere in the manner of an SPI release. There was a Elven and a Trollish kingdom true, but we had provided no magic. None. Further, we had only six special mercenaries, namely Juulute, Schardenzar, the Black Knight, Urmoff, Ogsbogg, and Hamahara. The Barbarian element was represented by nothing more than a small kingdom.

The prototype was dispatched to Metagaming of Austin, Texas. During its long evaluation period, Kenneth and I continued to sample the new bounty of the gaming world. Kenneth experimented with a different map, but we never got around to actually using it in any play test. In the interim, we discovered the Chaosium game of White Bear, Red Moon. This game was something new in our experience - a game of heroic fantasy.

A few dull spaceship battle games existed already and Excalibre had pioneered imaginative fantasy with Atlantis, while SPI had the execrable Sorcerer and there was a fantasy-tactical game called Dungeon from TSR. For some reason we had not bothered to examine the rest of the field - such as Fact & Fantasy's Helm's Deep or TSR's Battle of the Five Armies. So, within our frame of reference, we addressed the innovations of WBRM with great interest.

There was much in it we liked, though there was much which we couldn't relate to. For instance, WBRM seemed to have no clear line demarcating the world of the gods and the world of men. As a reader of mythology I could understand this - sort of. The world order in Stafford's Glorantha resembled that of The Kalevala or numerous primitive mythologies, including the American Indians,' where characters grade from hero to sorcerer to god with hardly any warning were one ended and the other began.

But Kenneth was a J.R.R. Tolkien enthusiast and my own fantasy tastes leaned toward Robert E. Howard, H.P. Lovecraft, and Clark Ashton Smith. In all these authors' writings there was a difference between gods and men; fantastic things were possible, but an understandable barrier remained between the different states of reality. Further, as far as the conventions of WBRM went, it was hard for us to identify with heroes who could, like the Irish champion Cuchulain, or the Indian hero Arjuna, take on whole armies single-handedly. To our mind, a Julius Caesar might make the deciding difference in a battle with the Gauls, but could J.C. have faced the host of Vercingetorix all by his lonesome? Never! A man is as man and an army is an army.

Nonetheless, WBRM had something we needed to learn - the manner in which magic might be fitted into the world of military affairs.

The Metagaming copy of Your Excellency finally came back rejected in 1978. Like most creative people, we decided that the editors involved just didn't appreciate quality and innovation. Nonetheless, months had already passed and we had some new ideas which we wanted to include into the game. Kenneth set energetically to work redesigning the map and before long he confronted me with an entirely new map done in a jolly-looking antique style, one which would be recognizable as the rough draft of the published classic. It had a colorful and richly satiric quality that would inspire much of the subsequent design, as well as much of the writing for the yet-to-be created Minarian mythos.

Kenneth had added most of the place names written in by the time I first saw the map, and it was only left for me to help with the details and the polishing. "The Crater of the Punishing Star" was mine, as was the "Altars of Greystaff." I also contributed the names of Zorn, Pon, Minaria, and the Invisible School of Thaumaturgy. Zorn came out of a phone book, and Pon was the name of a mountain kingdom created in a story cycle of mine, only two episodes of which ever saw light of day in amateur publication. "Minaria" had been the name of a kingdom I used in an earlier bit of fictional juvenalia. I think, unconsciously, that I was echoing "Mnar," an arcane land mentioned by Lovecraft, or maybe even Minnesota, my home state.

Kenneth and I already had a sound movement-combat-diplomacy system in the original Your Excellency. What the new version required from us was magic, chrome, and detail. The gadgety devices of the Eaters of Wisdom were worked out quickly, and we took inspiration from the corpse-loving mages of Clark Ashton Smith's short stories to create the Black Hand.

Working out the new Your Excellency was amazingly easy. The new game world seemed to leap spontaneously into life. Juulute, the Black Knight, Schardenzar, Urmoff, Hamahara, and Ogsbogg were preserved, but their abilities and powers were expanded and fleshed out. Bilge Rat and several special mercenary combat units were added also. Just before we were really to finalize the rules, we came up with the Wandering People, based, of course, on Hollywood's take on the Gypsies.

We sent the finished prototype to TSR, Inc. of Lake Geneva, Wisconsin. Within a reasonably short time, TSR's new products chief informed us that his staff liked Your Excellency and he was authorized to make us an offer of publication. Once the development staff began to work on Your Excellency in earnest, Kenneth and I received word that the title would be changed to Divine Right. We were fond of Your Excellency, but soon grew fonder still of DR.

Further, we had originally called all the monarchs kings and now were asked to come up with a wider variety of titles (aided by a kindly developer who had enclosed a long list of possibilities). We also were asked to provide some background material for the world - such as short descriptions of the kingdoms and the scenic hexes. As the seasoned fictioneer on the team, it fell to me to define Minaria. 

Although the game world was created without a real background story, the out-line of Minarian society came easily enough. As a fan of the theories of Immanuel Velikovsky, and the parallel idea of Robert E. Howard's Hyboria, I divided Minarian history into periods before and after the "great Cataclysm." Before the Cataclysm, the Minarian continent had enjoyed a kind of Pax Romanum, ruled by a proud, overbearing, but basically benign species of high elf which I called the Lloroi. The Cataclysm that followed took much of Minaria back to the Stone Age, but enough culture survived to allow a fairly rapid restoration of civilization. By about 500 A.C. (after the Cataclysm) Minaria had achieved about the same level of culture as Europe had possessed in 500 A.D. (though Europe had fallen to a nadir at that time, while Minaria had fallen much lower and had managed to climb back).

The developing the nonhuman races which fantasy fans known so well from Tolkien called for a special measure of care. Rather than treat the Goblins and Trolls as evil creatures befitting their origin in the mythology of the Underworld, I addressed them as alien races, different from men, of course, and rivals, but not metaphysically evil. The Elves and Dwarves came in for a little satire, to set them apart from the stereotypes already abroad in the gaming culture. I used hillbillies and gold miners to inspire the Dwarves, and a combination of Imperial China and the Third Reich to flesh out the Elves. The background material seemed to fit the bill as far as TSR was concerned and it was published with the game in 1979, as an appendix to the rule book.

Thursday, June 30, 2016

Combat mechanics

This is an interesting article on the combat mechanics for Tyranny by the Game Director:
When you perform an attack in Tyranny – whether it’s a basic weapon attack, casting a spell, or using an ability – your Accuracy is compared to the target’s Defense to determine how well the attack does. As with Pillars of Eternity, each attack can have one of four possible results: Miss, Graze (attacks deal less damage, status effects are applied for a shorter duration), Hit, or Crit (attacks deal greater damage, and status effects are applied for a longer duration).

Your Accuracy is determined by one or more character skills. A basic attack will use the skill associated with the weapon you’re attacking with. A spell will use the magic skill for that type of spell and the character’s Lore skill. If more than one skill is used, their values are averaged together to produce the final skill value. Accuracy bonuses from weapons or abilities are added to that base value to determine the final Accuracy for the attack. The skills used to determine Accuracy are also the skills you gain experience in for that attack.

Each attack targets one of five possible Defenses: Parry, Dodge, Endurance, Will, or Magic. Enemies and party members have different strengths and weaknesses in these defenses, making some attacks better options against one type of enemy than another.

Accuracy is compared to Defense, and the resulting difference is used to modify the combat result table. Higher Accuracy results in a greater chance to Crit or Hit, reducing the chance to Graze or Miss. A lower Accuracy has the opposite effect, making you Graze or Miss more often.
Dev diaries are a great way to learn about how designers and developers tackle the challenges that appear during the development process and how they think through the various options.

Wednesday, June 22, 2016

Getting Up and Running with Spriter

Spriter is a 2D character animation tool that was recommended during the last Devgame class.

When I was an apprentice clown, my master taught me that one of the first rules of clowning is "Stay green."  It means always work something new into your performance.  Let it grow and evolve.  Far be it from me to disregard the teachings of my master.  I got Spriter and gave it a whirl.

I've talked my code-monkeys into trying the Unity plugin it because it simplifies my work for me. To give them a leg up, I animated a treasure chest opening, added the plugin, and put the chest in Unity.

This gif is unable to do the animation justice, alas. In Spriter and Unity it's quick and fluid.

For code monkeys who wish to play with it, here's what I learned:


Sunday, June 19, 2016

Forgotten Japan

Hardcore Gaming 101 has a very cool summary of retro Japanese computer gaming:
Japan has long been viewed by the West as a console-centric country, ever since Nintendo and the NES. But there is another, mostly forgotten world of Japanese gaming history, in which thousands of games were developed for various Japanese computers over an 18 year period that stretches from the late 1970s to the mid-1990s. For all that Nintendo started, it was the open hardware of NEC and other companies that allowed small groups to form and become giants. In fact, some of Japan's most recognizable franchises, such as Metal Gear and Ys, actually began as computer games. The early Japanese computing scene was an intense flurry of creativity that launched the careers of many prominent figures in the video game industry, while also establishing some of the most famous video game companies, such as Square, Enix, Falcom, and Koei.

Japanese computer games were also exempt from any of the licensing and content restrictions that all console makers have imposed in various forms. These early games give us a rare glimpse into a world of Japanese creativity unfettered by censorship and outside pressures, which has never since been replicated. The content ranges from rampant drug use and presidential assassination (XZR), to tender explorations of love, sex, and relationships (Dokyusei), to mature and suspenseful horror (Onryo Senki), and even to one of the first rape simulators (177), predating the infamous RapeLay by 20 years. The content is not always tasteful, but the lawless atmosphere resulted in some of the most unique titles in video game history....

A forgotten era

The personal computer industry in Japan began much like everywhere else: as a response to Intel's creation of the world's first microprocessor, the 4004, in 1971. Both NEC and Toshiba successfully developed their own microprocessors in 1973, and over the next few years a number of personal computer kits and homebew packages were released by companies such as Hitachi, Fujitsu, NEC, Toshiba, and Sharp. Much like in the West, these early computers were primarily for electronics tinkerers and enthusiasts, and had to be programmed by the users themselves.

The early 80s saw the release of the first fully-fledged 8-bit computers designed with average users in mind, rather than amateur programmers (although there were still plenty of those). Three companies eventually shared the 8-bit crown: NEC, with its PC-8800 series; Fujitsu, with the popular FM-7; and Sharp, with the X1. NEC would later come to dominate the Japanese computing scene for over 10 years with another computer, the 16-bit PC-9801, but Fujitsu and Sharp were able to maintain a small but loyal following by staying competitive and eventually releasing two incredible 16-bit machines of their own: the Fujitsu FM Towns, and the Sharp X68000.

One important thing to note is that much like the early computers produced by Western companies such as Apple, Commodore, Atari, and IBM, almost all Japanese computers were incompatible with each other. This led to intense competition among the computer makers, with each vying to establish its own architecture as the dominant standard. Once NEC, Fujitsu, and Sharp took the majority of the market, the remaining computer makers banded together around the MSX, a shared computing standard developed by Microsoft Japan and ASCII. Despite being fourth place in the Japanese computer race, the MSX and its successor eventually achieved popularity in South America and Europe, while the Big Three never found success outside of Japan.

Wednesday, June 1, 2016

Shots Fired

I need to animate dwarves and orcs shooting in multiple directions.

Let's start with south. First, I draw the crossbow loaded and ready to fire.
Next I draw it post-firing:
Next I draw it raised as we load a new arrow.
Problem is, this animation is terrible!
Technically good enough for the target, site, but the purpose of this internship is to impress industry insiders, thus make contacts, thus make money, thus fund my own game dev projects.

Problem: I don't have enough time to animate all the inbetween frames.

Solution: Smears to the rescue!

First, we draw the bow firing:
Next, we draw the bow being raised from the empty position to the raised position.


Next, we draw the bow being lowered to threaten foes once more:

None of those pictures look good. They don't have to. They aren't going to be visible for more than a tiny fraction of a second. Their goal is to convince the viewer that the animation is way smoother than it actually is.

I think they succeeded, don't you?
One direction down, four more to go.