Storm Dragon Software Logo

News and Views - September to November 2016

Subscribe to RSS Feeds

Tools for Game Development

No doubt you could create a casual computer game using assembly language, but it would be easier and faster to use some tools specifically designed for game development. What you need is some way to create graphics and a game engine, and an editor for the game engine is a big help.

11.18.16 Tools, Part 3: Game Editor 8.

Putting in graphics is so easy that the grandson got bored and bailed on me, and besides, he has other commitments, like Minecraft. He says he'll come back for scripting.

Storm SurgeTM has a number of built-in mini-games, and yesterday I worked on the jigsaw and tiling puzzles in "A Tiny Mystery." If you want puzzles with all pieces initially right-side up, they are almost trivial to build (once you've got the graphics). You put the pieces into their final, assembled position in the StormEd Scene Display window, copy the coordinates for each piece into the slot for final position, and move the pieces out of position. You're done. I'm not kidding. Now, if you want to rotate pieces, you have to do more graphics and a little scripting; I'll tackle that today for the jigsaw puzzle.

11.14.16 Tools, Part 3: Game Editor 7.

I haven't posted in a while because I've just been working on the manual, and daily updates would be boring. However, this past weekend I was finally able to get together with my 9-year-old grandson to start building the small example game, "A Tiny Mystery." He didn't want to read the manual, but after a few minutes of instruction he was using the editor to create game scenes, import (pre-existing) graphics into each scene, move graphics into place, test whether they were in exactly the right place, give names to scenes and images, and so on. When we say that StormEdTM is so easy that a child can use it, that's exactly what we mean. Scripting may be more difficult; we'll see about that the next time we can get together. Stay tuned.

11.02.16 Tools, Part 3: Game Editor 6.

The StormEdTM User Manual is finished except for the example documentation for "A Tiny Mystery." I hope to start working seriously on that tomorrow with my grandson, although he has other commitments, like 4th-grade homework. (It turns out that Terri is busy.) If he and I can create a game using the manual, certainly you can create a game using the manual. Stay tuned.

10.18.16 Tools, Part 3: Game Editor 5.

The StormEdTM User Manual is just about finished and should end up no more than about 50 pages of text, plus a couple of appendixes. Did I mention that the game engine, Storm SurgeTM, will be bundled with the editor and with a tiny game? The appendixes will be the design document and scripting for the tiny game. I'm a person who learns code most easily by example; other people just read the manual cover to cover. You'll be able to learn StormEd either way.

Scripting doesn't look like it's going to be terribly difficult. Terri and I are going to test the completeness of the manual by building the tiny game without any help from Madison. Or at least, when we have to get help, we'll fix the manual.

10.14.16 Tools, Part 3: Game Editor 4.

I knew there was going to be a catch somewhere. Most of the images in the game are going to require scripting if the game is going to be at all interesting. The game developer has to "start working hard," as I suspected, when it comes to writing the scripts that tell each image what to do. For example, you might see the lamp in the scene that we talked about before. You know that you have do something with the lamp because the cursor changes when you move over it, but that's a function of the lamp image itself, which was easy to set up without writing a script. However, if you want to be able to turn the light on and light up the room so that you can see other parts of the scene, that requires a script. The script would probably highlight the lamp when you click on it, maybe bring up a close-up of the lamp switch, make the close-up disappear when you click on the switch, and then change then entire dark background image for a new, bright background image.

Are you a programmer? If so, feel free to guffaw when I say that the last programming language I used (aside from html and php) was Fortran 4, literally back in the last century. It turns out that Madison has written a programming language from scratch for our game engine and editor, and I'm starting today to write the section of the manual that deals with the commands and operators used in the scripts. So far, it doesn't look too bad at all, but so far all I've written is the section header.

10.11.16 Tools, Part 3: Game Editor 3.

Yesterday I assumed that making images in a scene do something would be more difficult than putting them in. As it turns out, that isn't necessarily so. If, for example, I put in a Map Button and attach a graphical image to it, Storm SurgeTM automatically makes it act like a map button, that is, when the player clicks on it, it brings up the map. Ditto the Journal Button, Inventory Bar, and so on. So far I've found more than 15 image types that perform their functions automatically, and only a couple that need scripting. Pretty cool, huh? Of course, if you want to add some feature like shimmering to the image, you're going to have to do some scripting, but that's optional in most cases. I still think there has to be a catch to this somewhere. When I figure out where the game developer has to start working hard, I'll let you know.

10.10.16 Tools, Part 3: Game Editor 2.

So far, so good on the StormEdTM manual. Adding scenes to the game and images to the scene is straightforward. You select either the scene type or image type from a dropdown list. When you select the scene type, you get a window (empty, of course) that displays the scene. To select an image type and add it to the scene, just browse to your game directory and double click on the image file, and it appears in the scene. It took me about 10 seconds to realize that I get a default scene name and image name before I put in any graphics, and that I can change them; I like it when these things are so obvious that I don't have to read the manual. Each image that you add seems to have 18 or 26 properties, although I've only looked at a couple of image types so far. Some of these properties, like ID number, are assigned by StormEd so that it can remember which one is which, but others, like position, you set.

Creating the scenes looks like the easiest part of game development so far; this is completely in line with the policy of Ducks in a Row, Inc., that we do not build annoying software. Creating all the graphics for "A Picture Perfect Murder" was a pain in the neck. I have to assume that once I get to the point of making the images in the scene do anything, the going will be a little rougher; I'll keep you informed. But so far, creating scenes is easy.

10.06.16 Tools, Part 3: Game Editor.

Unless you are an accomplished programmer, you probably won't be building your game using a game engine directly. Instead, you will use some sort of graphical user interface (GUI) or text-based editor. In the case of Storm SurgeTM, the interface is a GUI, although you have to do some typing; it isn't all drag-and-drop. During the development of "A Picture Perfect Murder," we didn't need a manual for our editor, StormEdTM, because Madison developed both the engine and the editor and already knew how they worked. I'm writing a manual so that you or I can build a game without his help.

Have you ever read a software manual? Most of them are too long, too confusing, and too out of date to be helpful. My personal philosophy for most software is that if I have to read the manual, the software interface is probably badly designed. When I want to know how to do put a hard return into an ExcelTM cell, I just Google it. Nevertheless, it will be a while before you can get instructions for StormEd off the web, so I'm writing a manual. Stay tuned.

10.05.16 Complex Software and Bugs

I mentioned before that programmers never feel that a piece of software is finished. One good reason is that there's always another bug to fix. Complex software is never bug-free, and a game is a fairly complex piece of software. I read in the paper Sunday that no house is ever sold in perfect condition, and when was the last time you bought a flawless car? Toyota says that a new car has about 30,000 parts, and our game engine alone, Storm SurgeTM, has about 30,000 lines of code. Then there's the graphics engine, the sound engine, and the actual scripting. For a game to be bug-free, many tens of thousands of line of code would have to be flawless.

Anyway, a new player of "A Picture Perfect Murder" found a bug, or more accurately, I found the bug while watching her play. She wouldn't have known it was a bug, and probably you wouldn't have either. In fact, unless you have a very slow computer, or you are a skilled player with very fast reflexes, the chances that you would even run into this bug are tiny. It doesn't affect the outcome of the game in any case. Nevertheless, Madison has fixed it. If you have a slow computer or fast reflexes, or if you just want the latest and best build, you might wait a day or two for it to hit our website and then re-download the game. Note: Downloading a new build will not affect your saved or current game in any way. The bug will still be there if you can find it.

Did you know that you can download any of our software as many times as you need to? Now, if we notice that you download it every day, we might send you an email asking for an explanation. But still, we know that computers crash, die of old age, or grow legs and walk away. We know that individuals have more than one computer. We know that software gets corrupted. Never feel shy about downloading another copy of our games for a legitimate reason.


10.04.16 Tools, Part 2: Game Engine 5.

Madison is planning to modify Storm SurgeTM eventually so that anyone who can program a dll could add the capability for virtually any kind of puzzle without direct access to the code. Right now, however, only a C++ programmer with access to the Storm SurgeTM source code (that is, Madison) can add new puzzle types to the engine. So why do I keep saying "you could do thus and so in your game"?  Because even now a non-programmer could use the editor, called StormEdTM, to create an adventure game with all the puzzle types and capabilities I named last week.

I'm not talking about reskinning; I'm talking about your own personal new game -- different map, different plot, totally different graphics, different animations, everything. The only limitations are that you couldn't modify the source code or, as yet, change the positions of the buttons on the main menu. The only thing that keeps me from releasing Storm Surge and StormEd is that at the moment there's no user manual.


09.30.16 Tools, Part 2: Game Engine 6.

In addition to the mini-games or puzzles I mentioned below, our game engine, Storm SurgeTM, currently supports
  • maps;
  • journals;
  • cutscenes;
  • soundtracks;
  • hints;
  • animated cursors;
  • three levels of difficulty;
  • independent control of volume for the music, sound effects, and voice naration;
  • an in-game tutorial;
  • a wide variety of screen resolutions;
  • an unlimited number of saved games;
  • your choice of TrueTypeTM fonts (you need to license these from somebody else or make your own);
  • two fonts that we designed and license along with the engine;
  • window and full-screen modes; and of course,
  • the adventure itself.

09.28.16 Tools, Part 2: Game Engine 4.

I mentioned in passing a few days ago that different game engines have different capabilities. In developing Storm SurgeTM, Madison focused on building an engine that would produce the type of game we liked to play. I played a lot of games in the hidden-object/adventure genre all the way through, and I played the one-hour demo from BigFish of quite a few more that I didn't like well enough to buy. Then Terri and I brainstormed about the types of mini-games and puzzles we like and don't like. Storm Surge supports almost all of the ones we like (even if they didn't make it into "A Picture Perfect Murder," and doesn't (yet) support ones that we don't like. The currently supported mini-games and puzzles are these:
  • Hidden-object puzzles. For those sensible people in the audience who have avoided addiction to these games, in these puzzles you are faced with a cluttery scene and a list of items, and you have to find each item.
  • Find an object, e.g., spot the difference, or find the five butterflies.
  • Misplaced object, e.g., pick up an item that's out of place and put it away.
  • Jigsaw puzzles.
  • Matching objects, e.g., turning over tiles to find mates, or matching pairs of items in a large group of similar items.
  • Tile swapping, e.g., repairing a mosaic or ordering a set of books on a shelf.
  • Cycling puzzles, e.g., Latin Square puzzles or interlocking, turning tracks.
  • Sliding tiles (which didn't make it into "A Picture Perfect Murder.")
Several of these games are shown in the trailer above. We also put in a couple of custom-scripted puzzles -- note that these did not require any additional coding, and you could add your own custom-scripted puzzle using the editor.


09.27.16 Tools, Part 2: Aside.

Speaking of production schedules and budgets, I've been running and participating in software-development projects since 1998. I have yet to meet a programmer who will admit that a piece of software is finished.  Guess what Madison is doing right now.  Marketing the game, right?  Wrong.  He's modifying SpectrumTM, which is what displays the graphics in "A Picture Perfect Murder." Spectrum already works, or we wouldn't have a game. He's just making it do more.

Every programming team needs programmers, obviously. What may not be so obvious is that every programming team that expects to finish a project needs a hard-nosed and unsympathetic manager. Unlike the pointy-haired boss in Dilbert, this manager must know the difference between additions to the software that (a) must be made, (b) should be made, (c) would be nice, and (d) are just the programmers' desire for endless improvement.


09.26.16 Tools, Part 2: Game Engine 3.

Let's talk about the specific capabilities of Storm SurgeTM and how they affected the development of "A Picture Perfect Murder."

First, Storm Surge was designed specifically for 2D hidden-object/adventure games. If we ever decide to build the zombie apocalypse shooter I mentioned before, we'll need a different engine. However, the playing time and complexity of the 2D games produced by Storm Surge are only limited by the designer's imagination, production schedule, and budget. The playing time for "A Picture Perfect Murder" is probably 8 to 12 hours, depending on how skilled you are at this type of game, how many hints you use, etc. We could easily have designed the game to include more scenes, more characters, more clues, more puzzles, and just generally "more." As a matter of fact, the original concept did have additional scenes and puzzles, but we ran up against the production schedule and budget (refer back to 09.08.16 to 09.10.16) and had to leave some of them out.

Zombie shooter concept art by Ducks intern Daniel Phelps.
Storm Surge doesn't have a built-in limit on the number of hidden objects in hidden-object scenes, although as a practical matter you're limited to the number of things you can show in the scene. "A Picture Perfect Murder" has 12 hidden objects per puzzle, but you could put in more or less. The hidden-object scenes turned out to have a much higher nuisance-to-reward ratio for the graphics team (i.e., me) than the other games did, so next time around, we'll probably have fewer of them, or at least no more of them even if the overall game is bigger. (You can do what you want, but I'm just sayin'.) In "A Picture Perfect Murder," the list of items to be found is at the bottom of the screen. When you find an object and click on it, it moves to the list, and the item is scratched off. In your game, you can put the name list just about anywhere you want to, or you could make the item and name disappear or whatever, depending on what animation you want to design.


09.23.16 Tools, Part 2: Game Engine 2.

Asking how much an engine will cost is like asking, "How high is up?" They run from free to expensive. Wikipedia lists about 170 game engines, many of which are free, so why would you either buy or develop one? There are two good reasons for buying an engine or getting one free:
  • Your coding skills aren't up to building your own engine.
  • You don't want to spend a year and a half (about what it took Madison, working alone) developing an engine.
There are also good reasons for developing your own engine:
  • Madison is kind of a do-it-yourself guy, which is one reason people make anything that they could buy. He knows exactly what the capabilities of Storm SurgeTM are and how to add or work around anything I want to put in the game that isn't supported already.

  • It may be that no free engine is available that does exactly what you want and that works. Some of the free engines work just fine, I'm sure, but it's entirely possible that you could invest time an effort in developing a game using a particular engine, only to discover some glitch at the end. For example, I have purchased a few games with flickering graphics. (I've never seen the graphics from Storm SurgeTM flicker.)

  • If you plan to create a series of games, building your own engine means never having to pay additional license fees, and the second game goes together much faster and cheaper.

  • If your engine is good enough, you might be able to sell it and recoup some of your development costs. Just remember that you have at least 170 existing competitors.

09.21.16 Tools, Part 2: Game Engine.

Say you have downloaded a game, such as "A Picture Perfect Murder." Three chunks of data go onto your computer. One chunk is the graphics, which to you means, "the world you see in the game," and to me means, "all the stuff I've been talking about for the past week and more." A second chunk is the game scripting, which is a particular game, as opposed to another game with different graphics and plot. The third chunk is the game engine, which you don't ever see, but it's what takes, say, the tile graphic I showed you on 09.14.16 and displays a single tile, lying on a background, that flips over when you click on it. If you want to build a game, you need a game engine. A number of reviewers have listed pros and cons of various game engines; just search for "game engine reviews."

Which game engine you need depends on what kind of game you want to build, how well you want it to work, how much money (if any) you have to spend, how soon you want your game to be on the market, and so on. We wanted to build a hidden-object/adventure game.  Well ... Madison and the interns actually wanted to build a virtual-reality, massively multi-		Zombie shooter concept art by Ducks intern Daniel Phelps.
player, zombie apocalypse shooter, but what we felt capable of building as a first game was a hidden-object adventure game.  Madison decided to build a game engine of our own, which he did, and which we call Storm SurgeTM. I'll talk more about Storm Surge in the next few days.

We're still greenlighting. If you have a Steam account, please wander on over and give "A Picture Perfect Murder" a Yes vote, and share this post with all your friends.

09.20.16 Tools, Part 1: Graphics Software.

I've only worked with a few graphics packages -- PowerPoint, Photoshop, Paint, DAZ Studio, blender, Sketchup, Spectrum Works Studio, Picasa, PhotoStudio Suite, and a few others that I tried in demo and rejected completely. Here's the one thing that I learned: NONE of them do everything, and NO PAIR is completely compatible. Caveat emptor.


09.19.16 Tools, Part 1: Graphics 5.

Jpeg files are compressed, which is why the same image gets smaller if you start with a bitmap (.bmp) and save it as a jpeg (.jpg). Small is good--nothing wrong with small. Small image files load faster and take up less room on your server or hard drive. Unless your image goes through several compression steps, your eye is unlikely to notice any difference at all. Unfortunately, jpeg file compression for images introduces what are called "compression artifacts," and boy! does your graphics software ever notice them! Here's an example of how that can complicate your life.

On the top, we have a black square against a red background, saved as a bitmap. Then I chromokeyed out the red to put the black square in the middle of a randomly chosen image -- ONE step with Spectrum Works StudioTM. No muss, no fuss, no need to cuss. On the bottom, the bitmap has been saved as a jpeg. Taking the same ONE step to chromokey gives us the sloppy result on the bottom right. By fooling around with the chromokeying settings for several minutes, I eventually got a square, but I could still see, with the naked eye, a very dark red, 1-pixel frame on the square. So the moral is, work with bitmaps (or other lossless formats, such as .png) until the last possible moment. And even at the last possible moment, most of the images you use on top of other images in your game, e.g., in a hidden object puzzle, may have to be saved as bitmaps or PNG files, depending on your game engine. That way your solid background (compare the fuchsia from 09.13.16 and 09.14.16) will disappear completely when you either chromokey or make it transparent in real time in the game.

Work with bitmaps to avoid compression artifacts.

09.16.16 Tools, Part 1: Graphics 4.

Lighting is another important aspect of photorealistic graphics. In yesterday's image (left), it seemed to me that the trio was dark in comparison to the background. I turned up the lights a little (right) -- remember that the backdrop doesn't change at all with lighting -- and now they blend in a little better with the scene. Now, shadows are a function of the shadow catcher, not the lighting. With the brighter lighting, the old shadows were a little on the pale side. I adjusted the alpha setting on the shadow catcher to darken the shadow: brighter lights, darker shadows. Now the guys look like a real part of the scene.

Make the lighting consistent to add realism.

09.15.16 Tools, Part 1: Graphics 3.

When I started playing hidden-objects games intensively as research for developing our own game, I immediately noticed that they are typically rather gloomy and dark. (Not all of them.) When I started creating our own, photorealistic graphics, I figured out why. It's because if you light the scene, you must put in shadows, and shadows are a pain in the neck.

Your eye doesn't even notice all the shadows in the real world, but if an object doesn't have a shadow in a picture, it appears to be floating in space (left). The shadow anchors the object to whatever it's sitting on (right).

 Shadows provide realism by anchoring characters to the ground.
DAZ Studio allows you to put in shadows using a shadow catcher, but the making the shadow catcher is somewhat tedious. I simplified the process by making a separate DAZ project with two shadow catchers, one horizontal and one vertical. For each game scene, I made a DAZ project with a background image and all the items that needed to cast shadows. Then I merged with my shadow-catcher scene with it. Sometimes I needed more than one set of shadow catchers, for example, in the corner of a room you might need two vertical catchers for the walls and one horizontal one for the floor. With only hours per scene of moving things around, I could get the shadows to look as if they were being cast onto the furniture, floor, or whatever, in the background. As I said, a pain in the neck, but the results make the scenes much more realistic.


09.14.16 Tools, Part 1: Graphics 2.

Let me just say here that Spectrum Works StudioTM, which Madison built, totally rocks. You can use it to layer, reposition, chromokey, resize (by pixels or percentages), rotate (by as little as 0.01 degree), crop, and flip images. Even with all that capability, it's simple to use. In fact, it's the only piece of software I used for graphics that was not annoying; it is a firm policy of Ducks in a Row, Inc., that we do not build annoying software.

In just a few minutes, I took yesterday's graphic, chromokeyed out the fuchsia, rotated the plates by 15.5 degrees and resized them by 90% to fit into the square background, and flipped the tiles horizontally and vertically. The project has 5 files -- three copies of the original image and two white rectangles to copy some of the bits that weren't cropped out. Because I can layer the file files in any order, the white rectangles are over some of the images and under others. It's taking me longer to tell you what I did than to do it.

By the way, chromokeying is greenscreening, except for any color you choose. I used it lot in developing "A Picture Perfect Murder," but it's not yet as easy as we'd like. Madison needs to do just a little bit of work to improve the chromokeying algorithm, but as soon as that's done, we think we can sell it at a very competitive price. We'll let you know.

Illustration of game graphics modified with Spectrum Works Studio.

09.13.16 Tools, Part 1: Graphics.

To create a game like "A Picture Perfect Murder," you need three basic tools:
  • Some sort of graphics package.
  • A game engine.
  • An editor for the game engine.
This week I'll talk about how we did the graphics. Most of these games appear to have hand-drawn graphics, but we chose a more real-world, photo-realistic look and feel to go with our murder-mystery plot (check out the trailer above). Some of our images are videos and photographs, but most of them are computer generated, principally using DAZ Studio and Google Sketchup. Almost all scenes had a mixture of the two types of graphics. Once we created the individual background and object graphics, we used Microsoft Paint and our own burgeoning proprietary graphics package, Spectrum Works StudioTM, to construct the final scenes and puzzles.

More graphics are needed than you might think. For example, in a hidden-object puzzle, there's a background containing none of the objects the player needs to find. Each object and its shadow is a separate graphic. If any hidden object overlaps another -- or even the shadow 		Illustration of game graphics development.
of another -- separate graphics are required for Object A without B, Object B without A, both, and neither. (Needless to say, I tried to avoid having them overlap!) Finally, you need an icon for the object as it moves down to the list or goes into your inventory. The upper left image on the right shows the difference between the glass and its shadow in the scene and the icon that moves to the list.

Almost every item that you can pick up has a highlighted and unhighlighted form (upper right).

In our tile-matching puzzles, the turning tiles are animated, so we needed a graphic for the tile back, tile front, tile 1/4 turned, tile 1/2 turned, and tile 3/4 turned (bottom). All the tile backs, tile 1/2 turned, and tile 3/4 turned are the same, but for every single tile we had to create unique graphics for the front and 1/4 turn. And so on for every puzzle and scene. Planning and developing the graphics took about half of the total time spent on the game. Bottom Line: Allow about four times as long to produce the graphics as you originally estimated.