Friday, July 29, 2016
Map Draft complete
The first complete draft of the map of Minaria is complete. If you notice any mistakes, this would be an excellent time to mention them.
Labels:
Art,
Development,
Divine Right
Tuesday, July 19, 2016
Selling It
For Elveteka, I wrote music for an elfish fortress defiled by orcs.
Artwork by Santiago Iborra |
There is craft in the piano reduction: the counterpoint works, there is a gradual rising and falling line that delineates registral space, a balanced melody, a sense of structure coming from the time signature change in the second half, a shifting of which voice carries the melody, appropriate sonorities, and so on.
It's easy to teach pitch and rhythm, but if that's all you know, you've been robbed. Music needs to capture your imagination. Ask, would you buy this?
Of course not! It sounds just like any other piano reduction.
We need color. The basic idea is an almost regal fanfare beset by eerie harmonies. Here's an early draft of the composition that I submitted to my team.
It's not bad, but did I sell it? I would say no. It sounds too polite, too nice. I needed more light coming through the windows and a sense of dark power underneath. Let me add some sustained strings in the upper register to represent the light, and a dark synth in the bass to represent the foreboding power. While I'm at it, I'll make sure the staccato strings are crisper and more defined - more aristocratic, if you will. I'll even add in a chromatic, arabesque harp line in the second half to signify a sort of dark aristocracy. Here you go:
The feeling is there. Time for a reality check. Did I evoke a world? Did I really do it? Prince, master of intangibles, says naw.
Whose fantasy is more vivid? Whose frame is stronger? Who better evokes aristocracy?
Prince, of course. Always trust the greats.
Sunday, July 17, 2016
The importance of communication
No matter how hard we try, important details are often lost in translation from one dev team member to another. This is why it is often important to go back and confirm that what we think we told the other person is exactly what they not only heard, but understood.
Case in point: I told the lead artist, whose first task is recreating the 1979 Divine Right map, that we were going to be using the standard 4k resolution of 3840x2160. This will, to a certain extent, future-proof the game, and allow for a very nice wargaming experience for those with big, high-resolution screens. What I meant is that 3840x2160 would be the base resolution for the game art; anytime a game is being developed, everyone has to know what the base graphic standard is, whether it is MCGA (320x200, 256 colors) to 4k (3840x2160, 16.7 million colors).
However, what the artist heard is that the map should be 3840x2160. In order to fit those parameters, he had to horizontally squash the hexagons, which produced the compressed effect that can be seen to the right.
That's not his fault, as I knew that he is a DevGame attendee and therefore should have remembered that he does not yet speak the same dev language that a more experienced game developer does. We were talking about a map, a map is defined by a specific resolution, and a specific resolution was selected. It was perfectly sensible for him to create the map at the resolution specified, and he did a very nice job of it. The fault, the responsibility for the error, was all mine.
Fortunately, one of the things we also teach in DevGame is the concept that one should never be afraid of making mistakes or correcting them, but rather address them as quickly as possible. Even more important is to prepare for the eventuality that a mistake will need to be corrected, so always work in a way that allows for maximum future flexibility. The artist did that by choosing to create the basic map in vector graphics, which meant that it could be easily resized; it was literally a matter of minutes before he sent over the revised map below, the hexagons no longer compressed.
The number of hexes is still the same, the height is still equal to the vertical resolution,, but the width no longer fills the horizontal resolution, which will leave space for monarch personality cards and other UI elements. The text needs to be redone, but that is a relatively minor task; the important thing is that nothing needed to be redrawn. This is a good example of a problem caused by a communication error that is promptly fixed by smart development processes combined with continuous communications.
Frequent and open communication is the key to quickly identifying and correcting problems. Don't ever allow yourself to avoid communicating or go dark for fear that you're doing, or have done, something wrong; that is the best way to ensure that whatever issues you've got are going to get worse and become serious problems. If you're not sure something is right, if you're starting to suspect something might be wrong, don't hesitate to look into it and talk about it.
Case in point: I told the lead artist, whose first task is recreating the 1979 Divine Right map, that we were going to be using the standard 4k resolution of 3840x2160. This will, to a certain extent, future-proof the game, and allow for a very nice wargaming experience for those with big, high-resolution screens. What I meant is that 3840x2160 would be the base resolution for the game art; anytime a game is being developed, everyone has to know what the base graphic standard is, whether it is MCGA (320x200, 256 colors) to 4k (3840x2160, 16.7 million colors).
However, what the artist heard is that the map should be 3840x2160. In order to fit those parameters, he had to horizontally squash the hexagons, which produced the compressed effect that can be seen to the right.
That's not his fault, as I knew that he is a DevGame attendee and therefore should have remembered that he does not yet speak the same dev language that a more experienced game developer does. We were talking about a map, a map is defined by a specific resolution, and a specific resolution was selected. It was perfectly sensible for him to create the map at the resolution specified, and he did a very nice job of it. The fault, the responsibility for the error, was all mine.
Fortunately, one of the things we also teach in DevGame is the concept that one should never be afraid of making mistakes or correcting them, but rather address them as quickly as possible. Even more important is to prepare for the eventuality that a mistake will need to be corrected, so always work in a way that allows for maximum future flexibility. The artist did that by choosing to create the basic map in vector graphics, which meant that it could be easily resized; it was literally a matter of minutes before he sent over the revised map below, the hexagons no longer compressed.
The number of hexes is still the same, the height is still equal to the vertical resolution,, but the width no longer fills the horizontal resolution, which will leave space for monarch personality cards and other UI elements. The text needs to be redone, but that is a relatively minor task; the important thing is that nothing needed to be redrawn. This is a good example of a problem caused by a communication error that is promptly fixed by smart development processes combined with continuous communications.
Frequent and open communication is the key to quickly identifying and correcting problems. Don't ever allow yourself to avoid communicating or go dark for fear that you're doing, or have done, something wrong; that is the best way to ensure that whatever issues you've got are going to get worse and become serious problems. If you're not sure something is right, if you're starting to suspect something might be wrong, don't hesitate to look into it and talk about it.
Labels:
Art,
Development,
Divine Right
Saturday, July 16, 2016
Divine Right is green-lighted
DevGame can now confirm that DevGame Project #6 will be the Basic Rules Divine Right computer wargame, as Alpenwolf has acquired the rights to produce Divine Right-related games, including the original wargame, from the rightsholder. The plan is to complete and release the Basic Rules version first, then add Advanced Rules and 3rd Edition Rules in the future.
Single-player mode versus AI opponents and multiplayer modes with and without AI opponents will be included.
Castalia House also acquired the right to produce novels and RPG materials set in the world of Minaria and utilizing the Divine Right name.
The map is already well underway and is being prepared for 4k screens. The 78 custom map icons still need to be created and the XY ratio needs to be adjusted, but it is otherwise nearing completion.
Single-player mode versus AI opponents and multiplayer modes with and without AI opponents will be included.
Castalia House also acquired the right to produce novels and RPG materials set in the world of Minaria and utilizing the Divine Right name.
The map is already well underway and is being prepared for 4k screens. The 78 custom map icons still need to be created and the XY ratio needs to be adjusted, but it is otherwise nearing completion.
Wednesday, July 13, 2016
The problem of scope creep
Derek Smart explains what every game industry veteran knows: scope creep kills:
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.
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.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.
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.
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.
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.
Labels:
Design,
Divine Right,
Getting Started,
History
Subscribe to:
Posts (Atom)