Category: design

Make a Configuration System in Game Maker, part 1

One thing that’s still currently harder than it should be in Game Maker is creating an interface to allow the user to configure the game preferences. It’s a real pain to have to implement a configuration system in each game you make from scratch — it takes a lot of time away from the development of the actual game.

Game Maker is supposed to make game development faster and easier. It really should have features to allow making the parts of the game program that are not the game itself faster and easier as well. One may consider this a weakness in Game Maker, if one takes Game Maker to be intended primarily for making game development quicker and easier. Which, it is.

But, Game Maker also is intended to be an educational platform, so I see this as both an inconvenience and an educational opportunity. How often do you get to devise your own UI widget and implement them out of primitives rather than use some library?

Since Game Maker does not provide this out of the box, and due to the difficulty of implementing such a system even once with good quality, it’s very worthwhile to try to build a generic system for game configuration options, something flexible enough to allow it to be used in many game projects, rather than have to build anew for each new game you develop. The up front investment in development for the system will be regained in the re-use of the system in many projects.

This article is the first in a series which describes in detail how to design and implement such a system in Game Maker: Studio. In the process, I’ll be generating a number of Extensions which you may use in your own projects.

Unfortunately, these articles will necessarily be Windows-centric, as I do not have the means to test what I’m building on anything but Windows and HTML5. I’ll be making the source available, though, so if you want to try these out in Android, OS X or iOS, or (if needed) modify/extend them to work on these platforms, you’re very much encouraged to do so, as long as you share the source and keep it open.

I would welcome other Game Maker Studio users who are building for OS X, iOS, and Android who want to collaborate on this project to contact me.

Going wild with UI design

Many games (especially professional games) go crazy with interface design. The designer is encouraged to (pardon the clichés) think outside the box and reinvent the wheel. More than simply coming up with new skins for buttons, sliders, pulldowns, and listboxes, etc., they do something really special to integrate the game, or its theme, with the configuration screen controls.

For a superb example of such an implementation, check out the configuration screen for Derek Yu’s Spelunky.

Spelunky's ingenious in-game configuration screen

By the way, did you know that Spelunky was originally created in Game Maker? Later on, its developer re-did it for XBox Live, and released the source for his Game Maker project, so be sure to go check that out. Play the game, and see how the configuration screen is cleverly set up as a special room in the “normal” play world, where your explorer can trip switches that control the configuration of the game. Then look at the source to understand how this was implemented.

Keep in mind that while Spelunky’s solution to the config screen is original and innovative, it’s not perfect — for example, it’s not terribly fast to use. There are always tradeoffs with any design — do what makes the most sense for your game and always with the user foremost in your thoughts.

If you want to, you can create an interface like this, but it’ll be more of a custom job. This series is geared toward building a foundation out of generic, reusable code. But the good news is, much of what we cover in here will end up being useful, because really the only difference between a custom configuration screen and a generic one is the interface, and we’re going to keep the other parts of the system abstract enough that they should be re-usable even in a custom system.

So, keep reading! Besides, it’s better to learn these basic approaches before trying to tackle something more innovative and complicated.

A word of caution, though: many times these highly customized interfaces look cool, but are terrible in how they function. They aren’t intuitive or understandable, or the controls are actually difficult to manipulate. Always strive to make your UI user-friendly.

There are entire bookshelves worth of books you could read to learn about good User Interface design principles. I don’t have space here to say it all, but in summary:

  1. Avoid forcing the user to have to think about how to do what they want to do. The UI is not a puzzle. Its purpose and function both should be immediately obvious.
  2. The UI should convey information clearly to the user. This information should be: the purpose of the control; the current configuration state.
  3. Controls should be easy to use and easy to understand how to use.
  4. There should be as few controls as are necessary. It’s a myth that people want lots and lots choices. They think they do, but what they really want are choices that are relevant to them, and the options that they want. A good designer can make most of these choices for the user without having to ask them their preference, but also knows which choices need to be offered to the user.  Look for ways to reduce the amount of controls you give to the user. Show only controls that are relevant in the current context. Combine controls when they represent mutually exclusive options.
  5. Provide sensible defaults. The default option should be the most sensible choice for the most people. Often, this is one standard option, but not always. Sometimes there are two or three good candidates for what may be a sensible default, and it is not obvious which one the default should be. Knowing which is the best configuration for a default setting may depend on environment and context. So, if your program can sense these things somehow, that can aid in selecting the most appropriate default.

There are always exceptions to the above rules. Like, I’m sure that for a certain puzzle game, a really innovative configuration screen that is itself a puzzle, and in its way serves to introduce the player to the game’s mechanics and gameplay would be awesome. But if you’re going to pull something like that off, you need to be very careful that your design works.


A Game Maker Weakness: No UI widget libraries

Game Maker has nearly nothing in the way of traditional interface control widgets. This alone makes creating a Settings screen very difficult for a novice Game Maker user. However, figuring out how to do this is an excellent opportunity for an aspiring Game Maker user, provided of course you can figure it out. Learning this will give you a lot of useful skills and insights about how to design both software and user interfaces.

In the long run, I believe it will be better for everyone if YoYoGames extends Game Maker to provide better built-in tools to allow developers to create polished, professional configuration screens without having to sink huge amounts of time into it. Preferably, some widget objects based on the native OS, but skinnable to allow the game to have its own look and theme would be the best way to go.

Until then, we have to make do, so we might as well come up with some useful approaches and share the knowledge about them. Fortunately, creating our own widgets out of Objects, a few sprites, and a little GML isn’t that difficult.

In the next article, we’ll talk about the Design of our Configuration System, and brainstorm the features we want it to have. I’m not just being editorially cute by using the “royal we” either — if there’s something you’d like to see in what I’m building, drop a comment.

Part 2

The Early 80’s Arcade Aesthetic

My friend Sam recently asked the internet if there were any books on early arcade game aesthetics. I’m not aware of any books that particularly stand out as being focused on game graphics, so I didn’t have any titles to suggest, although there are starting to be quite a few really good books on the history of the arcade.

To help him out, I brainstormed as much as I could, and since I think this ended up being pretty valuable, I figured I’d turn it into a blog post.

Basically every design principle in the graphics of early 80’s arcade games was governed by the insane limitations of the tiny systems of the day. Memory was SUPER expensive, 16k of RAM was a LOT in the late 70s/early 80s. CPU was 8 or 16 bit and SLOW – 1MHz or so. At the time there often wasn’t a dedicated video processing unit, or even dedicated video memory — everything was handled by the CPU, which often dedicated most of its processing power to simply drawing each frame of video, leaving relatively little processing power left over for handling game logic.

Here’s a list of qualities and factors that fed into creating the early 80’s aesthetic:

  • Portrait aspect ratios. Most of the old games, particularly vertical scrolling shooters, had monitors mounted in the cabinet in Portrait orientation (3:4 aspect ratio, as opposed to 4:3 ratio). Portrait gave vertical shooters more range to fire, and enabled manufacturers to build narrower cabinets, which allowed them to store, ship, and display more units in a given area.
  • Large pixels. The dot-pitch of those old screens was pretty coarse. You might have had a 15-, 17-, or 19-inch screen displaying 320×240 resolution, or even 240×160. Individual pixels were quite apparent, particularly in the late 70’s. Macro lens photos of the screen would reveal visible gaps between pixels. Early home computer monitors were capable of displaying a mere 40 or 80 characters of text, and the screens were tiny — 13″ or smaller.
  • Tiny sprites (usually 16×16 or 32×32 max)
  • Animations typically limited to 2-3 frames, though there were sometimes exceptions. Each frame of animation in a sprite cost valuable storage.
  • Bright colors and pastels. Here’s a great collection of color palettes available to home consoles and computers.
  • Grid-based graphics. Most terrain, characters, etc. were sized to fit within a standard grid size. Terrain, mazes, etc. were generally built out of repeated tiles.
  • No alpha channel. I don’t recall seeing any translucency (colors blending when two sprites overlap) in this era. Any transparency would have been all or nothing, provided by a mask. Before masking techniques became widespread, many early games had the background color drawn into the sprite, resulting in artifacts when two sprites would overlap.
  • Limited color palette. 2N colors to pick from, where N <= 8. So, generally 256 or fewer colors on screen. The most common color depths were 1-bit (B&W) and 8-bit (256-colors), although there were a few notable grayscale games, such as Fire Truck. 8-bit color ruled in the arcade until the 16-bit revolution came to the arcade, around 1986-87 — the golden era (roughly, 1978-1984) of the arcade was exclusively B&W, and 8-bit.Oftentimes, computers of the day had a pre-defined color palette and were further limited by the number of distinct colors they could draw on the screen at any one time, such as out of a total of, say, 4096 possible colors, which were baked in to the hardware and could not be changed, and you can only draw 16 (or 64, or 128) of them on the screen (or, in some cases, up to 4 colors in any one sprite) at any one time. If you want to emulate specific hardware, it’s a good idea to research the capabilities and narrow your color selection to match the authentic palette of the original hardware. These limitations often resulted in workarounds such as dithering (drawing two colored pixels closely together to allow the eye to blend them to a middle value). Here’s a fascinating article about the Commodore 64, describing a technique for getting “secret” colors to emerge from the C64’s limited palette by rapidly switching between two colors in the palette to synthesize a new color. It also meant that smoothing your images with anti-aliasing wasn’t possible, because there weren’t enough available colors to do proper tweening. Jaggy pixels ruled the day. Many home computer games of the era did their graphics in Text Mode, which has its own distinct look.See also: MDA, CGA, EGA, VGA
  • Palette swapped sprites. Old computers used color palettes, or indexed color. Out of a gamut of, say, 64 or 256 or 1024 or 4096 possible colors, a sprite typically could only use, say, 4 or 16 out of the 256 available colors. These four chosen colors were defined by a “palette”, and each color on the palette had an index value used to refer to it. By changing the colors in the palette to different colors, or in other words swapping one palette for another, the indexes in the sprite would be updated to use the new colors. Re-using and re-coloring the sprite, saved on storage space. A palette swap took a bitmap and re-mapped the values in each pixel to a different color from the new palette. This is why Mario is red and Luigi is green, for example. It was also very common to have different power levels of enemies denoted by using palette swaps.
  • Blinking and flashing. Rapidly flashing colors as a cheap, eye-catching form of pseudo-animation.
  • Flicker. If the processor couldn’t handle drawing all of the sprites on the screen in every screen refresh, something had to drop. So a sprite might not draw every screen update if there are too many on the screen, or too many in a horizontal scan line.
  • Abstract, iconified representations of things, and cartoony drawings, as opposed to realistic drawings.
  • Reliance on clichés, tropes, and popular idioms to help make graphics more easily recognizable, and a willingness to extend the idiom in a clever/absurd/zany fashion.
  • Fruit and keys and things are canonical bonus items.
  • Giant head/face, tiny body/limbs. They tried to fit the entire character into a 32×32 square, and most of the detail needed to go into the face/head to make the character recognizable and memorable.
  • High contrast is important for foreground/background.
  • Shigeru Miyamoto once gave an interview where he discussed why the original Donkey Kong sprites for Mario…mario
    • had white skin (the background was black, so they wanted strong contrast),
    • had a mustache (it helped his nose stand out and a mouth and chin were too complicated for the number of pixels left in the region)
    • wore red overalls/blue shirt (the overalls helped with the contrast of his swinging arms, which you otherwise wouldn’t get from a solid colored top.)
    • Wore a hat (his dark hair would have stood out less against a dark background, and presented problems with animation.)

Don’t forget vector!

Notable vector titles of the era:

  • Asteroids was the first hugely successful arcade game that used a vector display. Note the intense glow of the UFO and missile in this image, due to the vector display over-drawing those lines many more times than the refresh rate of a raster scan CRT would have allowed.asteroids_630x[1]
    I’m not sure what the very first use of a vector monitor was in the arcade, maybe Lunar Lander?
  • Battlezone When gamers of the area think about vector games, probably the first two titles they’ll think of are Asteroids and Battlezone.battlezone[1]
  • Qix Actually, Qix used a raster monitor, but it was primarily line based art, so I’m including it anyway for inspiration. Plus, it gives you an idea of how a line art game would look on a low-res raster display of the period.Qixingame[1]
  • Tempest Tempest was the first color vector game, and was a sensation at the time of its release.maxresdefault[1]
  • Space Duel is one of my all time favorite games. It featured innovative 2-player co-op/competitive play, and awesome graphics.Spaceduel[1]
    Note the distinct difference in this photo of an actual vector monitor screen photograph vs. how the game looks when emulated on a modern display:score8055_20140504190722[1]
    spacduel2[1]
  • Star Castle An often overlooked classic, the arcade version Star Castle used a color overlay over a monochrome vector CRT:star_castle_large[1]
    Later cabinets made use of a color vector CRT display, and looked much better: screenshot1[1]
  • Star Wars (really impressive achievement vector graphics, actually — convincing 3D, accurate wireframes of familiar star fighters from the movie, simulated fills, etc.)Star_Wars_Screen[1]
    1181242172192[1]

There might be other notables that I’m forgetting, as well, but these should have you pretty well covered.

Color vector screens were something rare and expensive, most vector games were B/W or monochrome (green or amber). I believe before proper color vector monitors became cheap enough, some vector games may have made use of cellophane overlays attached to the screen which filtered the vector image painted on that part of the screen to make it appear colored.

When you DID have colors, they were very bright colors, almost always primary colors (RGB).

The way the vector monitors worked:

  • There are no pixels (not easy to emulate, but maybe the retina display on the new iPhone/iPad can help make this more convincing?) This meant no aliasing or scaling artifacts.
  • A->B, not scan lines. The cathode beam was drawing from A to B for each line segment, not drawing scan lines from top to bottom.
  • Bright and sharp. As such, a vector display could spend much more time drawing each line segment, far faster refresh rates than the 30Hz that is typical of pre-HDTV raster CRTs. Unlike a raster CRT, there was not a fixed refresh rate; the cathode beams traced over the line segments as quickly as they were able to. This resulted in a very bright, flicker-free vector line (again, not easy to emulate) compared to the brightness of a white pixel on a raster display. There was often some ghosting as the intensely bright phosphor dimmed after the object on the screen moved. This was a hardware artifact, not something programmed in to the graphics routine as a special effect. Vector displays GLOWED and were sharp and gorgeous.
  • More stuff to draw means dimmer lines. This also meant that the more stuff being drawn on the screen at once, the overall brightness of each individual line was diminished, ultimately resulting in visible flicker if too many things were being drawn at once.
  • Even brighter vertices. Where line segments intersected, or at vertices, the beams additively excited the phosphors resulting in an even brighter point at the corner in relation to the brightness of the rest of the line segment. We’re talking REALLY excited phosphors!
  • Geometric shapes and polygons, not curves. Curves would have required far too much computing time to calculate precisely. Curves were always approximated with line segments. Linear functions are way faster than polynomial and trig functions, and the processors of the day didn’t even have dedicated floating point units (FPUs).
  • (Usually?) a single line thickness for all graphics. I can’t think of any vector games where the line thickness varied, but it’s possible there may have been some. Typically the lines were quite thin, like pencil lines.
  • No fills. Everything is a wireframe — maybe a simulated fill by drawing in a bunch of lines in a pattern. Fancier 3D games would occlude line segments that were “behind” the surface of some other object, but a lot of them just let you have a kind of x-ray vision effect where you could see through the wireframe.
  • Black background. You can have any background color you want, as long as it’s black.
  • Favorable to 3D. These properties made 3D games much easier to draw in vector than for raster graphic displays of the time. So a lot of the early 3D experiments were done with vector displays, most notably Battlezone.

Further reading

http makes us all journalists.

Something I did made the paper a year ago, and I just now found out about it:

http://blogs.sfweekly.com/thesnitch/2011/09/anonymous_circulates_diy_press.php

The blog article mis-attributes the quote “http makes us all journalists” to Peter Fein, who I’ve never met or had any dealings with, but I actually came up with the slogan, and the 1.0 design of the press pass. [Update: It turns out that I have met Pete, but it was long after the fact of the BART protests. In fact, without realizing that he was the same person from the article above, I met him and his wife Elizabeth at Notacon9. I’m happy to report that they’re wonderful people.]

After I created the design, and it was put up the noisebridge wiki, I remember at the time a number of journalists took offense to the slogan, completely missing the point of it while being defensive about their college major or profession. I guess it stings when your career is threatened by the emergence of a new medium that the old guard doesn’t understand readily, misses the boat on, and you watch newspaper after newspaper go out of business or get swallowed up by corporate media conglomerates.

I get that Journalism is a serious discipline and has standards, most of which are completely gone from broadcast and publishing these days, but whatever, they’re important standards. Saying “http makes us all journalists” wasn’t meant to insult your diploma, your profession, your Peabody, or your Pulitzer.

The point was that the slogan is directly after a quotation of the full text of the first amendment, which guarantees freedom of the press. The internet, especially http, enables all of us to be our own press. Freedom of the Press isn’t just freedom for Journalists, but for artists and authors and everyone who has a mind to express thoughts with. “With HTTP, All Can Publish” might have been a more accurate slogan, but I came up with the idea in about 10 minutes, and I like the spirit of it, so I’ll stick with it. Frankly, I’d rather there be more agitated journalists in the world, rather than the corporate media shills that have largely supplanted them, while abdicating the Fourth Estate for a comfy paycheck. If you’re a journalist and the slogan pissed you off, good. If it inspired even one person in the general public to take up the mantle and aspire to become a serious journalist, even better.

I created the design when a friend in SF tweeting about the Bay Area Rapid Transit protests, that were happening at the time, said that people who didn’t have press passes were being denied access to the protest area. The protests were in response to a police shooting and killing of an homeless man who was on the prone on the ground at the time he was shot, and not a threat to anyone. That shouldn’t have happened. I felt strongly that the protesters had a right to protest and a right to cover their own actions and publish about it, so I created the press pass. It took maybe a half hour, a couple of rectangles in Illustrator, and I was done. The idea that the right to be present to cover an event should be limited to those who possess a Press pass struck me as an unconstitutional abridgment of rights reserved for all. So I created a Press pass for all.

The version I created didn’t have the photo of the Guy Fawkes wearing person in the ID photo. My idea was to take your own passport photo and put it in there — I measured everything out carefully to be sized correctly, and made the card the size of a ISO spec for an ID card that I found details on the internet.

The image at the right is the symbol for Noisebridge, a SF hackerspace that I’d like to visit someday. I ganked the image from their website and incorporated it into the design, since the friend who got the idea started was affiliated with them, and they were involved to some capacity in organizing the BART protests. I’ve met some cool people from Noisebridge who I consider to be good people: bright, conscientious, inquisitive, concerned.

The reverse of the press pass had the text of the First Amendment and the slogan “http makes us all journalists” which I meant to emphasize the fact that the internet is a truly democratizing force, enabling each and every one of us to communicate with everyone else, reaching people we might never otherwise have known about, and impossible to censor… though, they never do quit trying.

Someone else put the Guy Fawkes image in there, but you could just as well replace it with your own image if you wanted, as I originally intended. The “points system” for doing this or that with the pass to make it more authentic looking was also someone else’s idea, as was the information resources to help people know their rights. Each contributor acted freely of their own accord to contribute their ideas and built off of them without ever talking to each other. It is what you make it. Modify to suit your needs. Do what you want, be responsible for what you do. That’s the power true freedom gives you.

I’m not a member of Anonymous, as I’m not posting this anonymously. Anonymous does some good, some bad, just like anything else. I don’t know anything more about them than what you can read on the internet.

###

More favorable coverage, with an image of the original design:

http://lafiga.firedoglake.com/2011/08/23/http-makes-us-all-journalists/

Ludum Dare 23 postmortem 3

(Part 1 | Part 2)

Making Enemies

Saturday I developed Enemy AI and Food. The first Enemy was actually done Friday, simply a renamed, re-colored (red) variant of Player with a collision event to handle contact with the Player, and the control scheme modified to have the Enemy bacteria follow the nearest Player bacterium, not the mouse.

What resulted from this was actually surprising: (more…)

Ludum Dare 23 postmortem 2

(Read Part 1)

Once I decided that my idea to create a game based on bacteria was both interesting and within my capability, I needed to figure out if it would be technically feasible. I knew that I would be working in Game Maker, because I know it the best and can get results quickly with it.

Choose Your Weapons

I toyed with the idea of (more…)

Managing Categories and Tags in WordPress

For the longest time, I’ve paid little attention to the categories and tags on this site. I played with the features a bit, but didn’t really understand them well enough to feel like I knew what to make a category, what to make a tag, how to do it consistently, and so on.

As often happens, I figured it out “naturally”, by just using the site and over time the purpose became more clear. Then for a long time I just didn’t feel like going through the tedium of going through all the old posts and re-doing everything. I hated feeling like “If I had to do it all over again, I’d do things differently”, though, so eventually I had to do something about it.

I’m here to share the lessons I learned.

Know your purpose, or if you don’t know your purpose, find it

When I started this site, I wasn’t entirely sure what I wanted to use it for. I knew I wanted it to be a site for promoting and blogging my professional activities, but beyond that I wasn’t sure how I wanted to do it. This was something that developed for me over time, as I became more comfortable. At first I was very risk averse about putting up any content at all. Putting my real name up on the web made me feel inhibited and over-cautious. I didn’t want to make a mistake, embarrass myself, offend someone, lose my job, etc.

As time went on, I began to get over these fears, and it allowed me to post more frequently, feel more free about saying what I want to say, and knowing what I wanted to talk about. I surmise that most web sites develop their purpose over time, and refine what they do. I couldn’t have known how to do everything before I started.

Doing it is an essential part of the process of learning how to do it.

This means making mistakes, and you shouldn’t let yourself be inhibited from making them. Learning from them quickly and doing things better is more important. But sometimes lessons take a while to sink in, and when that happens it is not always the best thing to start making changes right away. You don’t have the time and you quickly lose energy if you put yourself through a comprehensive overhaul several times in quick succession. So before doing a drastic overhaul, take time to think about it, and before you do the whole thing, do a small part of it first and see how it works. Iterate a few times until you think it’s just about right. Then do the overhaul.

Categories

Here’s how I think about WordPress Categories: If my WordPress site was a book, the Categories would be the headings I would use for my Table of Contents. This isn’t quite right, but it’s a close enough way of looking at it.

If your site has a relatively narrow purpose, you should have relatively few categories. Categories should be broad. Think of your categories as sorting bins for your posts. Your posts fit into or under them. It’s OK if your posts fit into multiple categories, since there’s often overlap. You can create a hierarchy of categories as well, which can be helpful if you have a number of closely related category topics.

If you find that you are constantly writing posts that fit into the same group of categories, you should think about whether those categories would be better off consolidated into a single, broader category, and perhaps your former categories re-done as Tags.

Tags

Tags are like index keywords that help describe the major ideas that are contained within your post. You should think about the content of your post, and what the main ideas or topics were, and tag appropriately. This is not a SEO game, where you want to try to guess all the variations of words that people search by and include them. So skip the -s/-ing/-ly game.

Tags should be short, single words or phrases of two or three words. Try to avoid redundancy, but some small amount is probably OK. WordPress separates tags with commas, so you don’t have to worry about using spaces. It’s OK to use spaces between words, rather than running words together.

I frequently see tags being misused as a sort of meta-commentary on the content of the post or page. This is witty, entertaining, gives some personality to the site. I’m not sure that it’s helpful, but the occasional humorous tag might be amusing.

Witty tags work when you’re reading at the bottom of a post, or reading the summary or digest of an article before you click to Read More. But the intended way for your readers to use tags is to find other related content on your site that is of interest to them. If you over-do the witty tags, you’re not giving the reader useful ways to find a reason to spend more time reading your site.

How your site’s users use Categories and Tags

How, indeed? You can guess, and you can assume, but the truth is unless you have some system of measuring that can watch your readers behavior while they’re on your site, you don’t have too much of a clue how a site’s users actually use the category and tag features.

With WordPress sites, typically it’s the authors who are doing the tagging and categorizing. Readers merely consume them. Some sites, where there is an element or even an emphasis on user-generated content, give users the capability to creating their own tags and categories. If your site does this, you absolutely need to observe and track your users’ behavior. It’s fascinating, amusing, and will give you a lot of insight.

If you retain sole control the category and tag features, you need to think about what your readers need and how useful you are making your site through these features. If you can, try NOT to have to rely on guessing or “common sense” to tell you this — find ways to observe user behavior (though logging, perhaps), or solicit user feedback, and use that to influence your planning and decisions.

Another useful thing to do is to monitor the way people are searching your site, or the search engine query that brought them to your site. The most common search terms your users used to find you should jump out as terms that you should use for tags, possibly for categories as well. And if you’re advertising your site, or using advertising to generate revenue on your site, knowing what terms users are searching for is crucial to drawing traffic and generating revenue.

WP-Admin and the Category/Tag Renovation

My experience with this was that it could have been faster and less tedious. It’s probably my host more than anything, but it seemed that reloading the post, tag, and category administration pages took longer than I had patience for. Clicking update, then waiting a few seconds for the refresh, times however many posts I updated, adds up.

If I wanted to apply the same changes to multiple posts, there’s no way to do this through the web interface. A “mass action” feature to allow adding/removing the same category or tags to multiple posts at once would be very useful.

I could have attempted to directly manipulate the database through building a custom update query, but I didn’t want to sink time into doing that, didn’t want to run the risk of messing it up, and in any case, it’s probably beyond the capability of most WordPress bloggers, so I don’t recommend it. If you have an absolutely HUGE site that needs hundreds or thousands of changes to be made the same way, look into it. If you’re just dealing with dozens, just do it manually.

The other thing that would have been helpful was some kind of redundant tag merging. It’s not uncommon to apply very similar tags inconsistently over the history of your site.

For example, I used the tags “GameMaker” and “Game Maker” quite a bit. I had a few other GameMaker-related tags, which included a specific version, such as 8.0, 8,1, etc.

My first attempt at merging these was to simply re-name the “Game Maker” tag to match the label of my “GameMaker” tag. This did not merge the tags, though; it just created two identical tag labels, which were still separate as far as my WordPress site was concerned. A reader clicking on the “GameMaker” tag from one of my posts would only find about half of the posts I’ve written about Game Maker. Not good!

In order to fix this, I had to remove the redundant tag from my tagging system. To avoid losing the posts that I wanted to be tagged, though, I had to go through and re-tag those posts with the correct tag. At that point, I had a bunch of posts that had BOTH “GameMaker” tags — the correct one, and the incorrect tag that I’d re-labeled. I still needed to remove the incorrect tag to get rid of the redundancy, but looking at my Posts I couldn’t tell which was the redundant tag! So, I went back to the tag admin page, and changed the label of the incorrect GameMaker tag to “dup”, and then went through my posts and removed the “dup” tag.

It would have been much simpler, easier, and faster, if I could have simply navigated to the tag admin page, selected both the “Game Maker” and “GameMaker” tags, hit a button to merge the two tags, and specified which label I preferred to keep. I hope they include that feature in a future WordPress release.

Conclusion

I’m sure there’s still more room for improvement with the way I’ve done it, but I’ve managed to clean up my categories considerably, and applied tags much more consistently through all of my posts. It took a couple hours, but I hope it is worth it. I see a few benefits worth mentioning:

  • Users will have an easier time finding content that is relevant to their interests or related to something they came to the site to read.
  • It will increase the amount of time users spend using the site.
  • It will decrease the amount of time users waste on the site.
  • Better organization will convey to users that the site is of good quality.

Games and stories

Humans are storytellers, and we do it more or less instinctively, but many of us are not great storytellers. Humans are also game players, and we also do that instinctively, and most of us are at least decent in some game or other.

The use of Story in videogames is a rather deep topic, but suffice it to say that games have done well with minimal story, with trite and clichéd story, and often with just plain bad story. Games do have the potential to deliver great story, and some have.

This article at Ars Technica raises some points that I mostly agree with, in that a game doesn’t need a story to be a great game. But I disagree with it insofar as great stories should only be told through established, proper forms. Reading it prompted the following thoughts in reaction:

Even Chess has an element of story to it: Two kingdoms at war. It’s abstract, but it does have meaning. It’s not really the point of Chess, and it’s easy enough to re-theme the story a particular chess set tells. Understanding the course of a game of chess through the metaphor implied by the significance imparted on the various pieces doesn’t really add any insight to winning strategy, though. Chess is loosely coupled to its story. It’s there for flavor, and there’s some symbolic meaning there, but it’s not very important.

A game like Tic-Tac-Toe has no story at all, right? It’s just an absolutely abstract conflict based in the geometric realities of the grid and the arbitrary significance of orthogonal lines. Well, suppose we take the British name for the game, Noughts and Crosses, and then let’s to a tiny bit further to modify the Noughts so that they’re Crescents. Instantly, we’ve created story: a retelling of the age-old, pointless clash that nobody can win between Christianity and Islam. It’s so slight, it’s almost stupid that this change is all that is needed to convey a story with a moral, yet it’s strangely powerful. And that’s how ingrained story is to games. It’s there because we can’t help ourselves putting it there.

Some attempts at telling a story that is the equal of our finest books, plays, and films through the medium of videogames game end up being a failure, and this ends up hurting both the game and the story. This much is true. I think “So don’t ever do that” is the wrong lesson to take from that. Game design is a rapidly developing art form and it’s entirely likely that new ways of integrating story and game are possible, many of them still over the horizon. We can imagine a lot, but we can’t imagine everything the future will bring. Which is why the future is so fascinating. Closing off an entire branch of game design because it was a bad idea in the past or because past attempts failed is just shortsighted.

If you’re making a game, the first goal is make sure that the game is good. There are a lot of ways to do this, likely infinite.

If you support the game with story elements, it can enhance the game. Game developers should try to make those good, of course, as they should make any element in the game as good as they are able. But they don’t have to be concerned about telling great, serious stories. Stories told through games can be great, though, and it’s fine to aspire and experiment to find what works and what doesn’t, but clearly most games do not require a level of storytelling the equal of a classic novel in order to be great as games. It’s OK for them to aspire to do so, though.

Design crossroads

So in Boobie Teeth 0.15, I created a surface for my ocean. The way I designed it, if you breach the surface of the water, gravity takes hold of you and you fall back into the ocean. Beneath the surface, no gravity.

I didn’t realize it until I played for a while, but if you breach the surface and wiggle the controls, the input seems to give you extra momentum, which can keep you above the water indefinitely. This wasn’t what I desired, but I wondered whether I should do anything about it. Should I consider it a glitch? Should I leave it in, and let the player discover it? Gamers like to discover things like this, and it’s kindof fun, if useless, to fly about over the waves. But if I leave it in, I should give it some purpose.

I have to think about it for 0.16. Maybe something will come to me. Maybe if you fly about enough, you can get someplace secret.

I don’t like when I design something and it doesn’t work the way I conceived it in the beginning, but sometimes I like the surprise. Even when I do like the surprise, I like to figure out what went wrong and figure out how to make it work the way I originally intended. Maybe I’ll keep it in mind for later.

So I figured out a way to fix the problem, it was easy enough: just set the controls to be disabled when you’re above the water. This causes your above-surface trajectory to become purely ballistic, but at the expense of not being able to control your direction at all. Conceivably this could cause you to leap out of the water, only to be doomed by your trajectory to land right on a big fish that will eat you when you plunge back into the water.

That seems so much less fun than being able to fly out of the water for as long as you care to wiggle the stick. On the other hand, I don’t want there to be a cheap, easy way of avoiding danger indefinitely.

There may be another way. I might just need to find a way of making the simulated gravity increase each step of the game engine until it can’t be resisted. Then you could still wiggle, and might be able to gain a little bit of extra effort air while out of the water, and affect where you will splash down somewhat, likely enough to evade big fish near the surface. I’ll have to play with it and see. Sometimes this experimentation ends up being fruitless, other times I can figure out something useful and understand the tool or the model better than I did. Usually the experimentation is time consuming. But generally, it’s worthwhile.

Any time I run into a design crossroads like this, I think the solution is easy: it’s like Yogi Berra said: “When you hit a fork in the road, take it.” Keep all interesting variants, and make them configurable options. Play through the different options and keep them for as long as they make for interesting play. Some options may make it into the final game as official options, some may be used as hidden easter eggs, others may end up disabled. But keeping the options around as long as possible makes for a more agile course through the development process.

Success!

It’s time for a catch-up for my neglected blog…

What I’ve been up to lately: The Computer Game and Simulation Design class wrapped up this week, and I both did extremely well in it and enjoyed the class very much. I ended up carrying a 101.5% average in the course.

I pwnd CGSD120!

My grade for CGSD 120

Since I now have some spare time with the class out of the way, I’ve started my first independent project. I’m not really ready to talk about it in depth just yet, but in the next few weeks or so I hope to get it to a playable alpha state, and then it will be made available over on the releases page.

Games: 5 Colors Pandora looks cool

I love graphical minimalism, and this game by Jordan Magnuson takes it pretty close to as minimal as you can get. The graphics are so low res, and only use about four shades of grey for the most part, yet you can tell exactly what stuff is supposed to be, because the shapes and animation suggest and the brain fills in the rest. Caves, buildings, cars, doors, are all readily apparent.

“You” are just a 3-px line, yet it’s enough to convey “person”. Foreground/background objects are conveyed through how dark/light its color is. I have little idea what’s going on plot-wise, yet, but it looks like you go around exploring a world trying to figure out puzzles to take you deeper into the world. Musical cues seem to communicate something about what’s going on, but that’s all I can make of it so far. Stylistically, I really like it.

It reminds a bit of Terry Cavanaugh’s Don’t Look Back because of the low-res graphics + atmospheric and evocative background music. The gameplay is a bit simple and could use a little more elements to this basic formula, maybe, but I’m not sure what just yet. Mostly you explore these large, empty areas and it seems like there should be more things populating these spaces in order to make them more interesting. You get a good sense of travel and exploration, and figuring out how to navigate and get around obstacles is an interesting puzzle that will take some time to figure out, but once you get past that, there’s not much more to engage the player. Items to collect and use, creatures or other people to encounter would make it more interesting. I could see it being developed into a deeper game with a story, maybe. Certain aspects of the game remind me of so many different titles that I like — everything from Pong, Adventure, Zelda II, Mario, Don’t Look Back.

Built with GameMaker, the developer is even distributing the source for it, which is very awesome. I might have to tinker with this a bit…

Get it here