Category: games

Robotron: 2084 and Zookeeper

Best Of, design, games, reviews
Comments

Today was the day of Cleveland’s Classic Console and Arcade Gaming Show. This year was especially well attended, and I was very happy to see a higher proportion of female gamers attending. I’ve been going since I heard about it 2005, and every time I go there is always something I have never seen before, and it’s always a good time. In addition to rows of tables with old games to buy and look at, some homebrew and modding fun, and some old school systems set up with games to play, there are drawings and tournaments.

This year, they had two of my favorite 80’s arcade games: Zookeeper and Robotron 2084. Robotron was a tournament game. I thought I might have a chance at winning, but I didn’t come close to the top score — although I did have the second highest score. I played a lot of games to get sharp, but my top score of 214,000-some points was still far from the winner, who posted a score of almost 391,000. It’ll take me a while to get that good.

While the experience is still fresh in my mind, I thought I’d reflect on what makes Zookeeper and Robotron two of my favorite games.

(more…)

Making a Configuration System in Game Maker, part 2: Requirements

design, development, GameMaker Tutorials, games, programming
7 Comments

If you haven’t yet, go back and read Part 1

Design choices

Since we’re starting from (basically) nothing, we have a lot of decisions to make. Therefore, thinking about the design of your configuration system first before you start building things probably is a good idea.

Requirements

First, let’s think of the features that we need. When I brainstorm features, I tend to go crazy. I think about everything I might possibly need. I think about all the things that would be OMG SO AWESOME to have. I find it helpful to do this, but I have learned that while having all these ideas is great and exciting, in the end you have to build everything, so every idea you come up with represents a lot of work and a lot of testing.

I’m only one person, working on these projects in my spare time — not a design house, or even a full-time lone developer, so if I want to ever have a hope of finishing my work, I have to scale back to the essentials. So why think about everything I can imagine?

  1. I like my imagination. It’s awesome, and using it is fun.
  2. The more I think about things, the better my ideas get.
  3. When I think complex, even if I don’t ever build the whole thing, I can at least create a design that will better accommodate further development later if I want to extend the basic implementation. I might do the extending, or someone else might do it later; it doesn’t matter. Building code as a foundation for future code is a good thing if you can manage to do it. Doing so correctly means avoiding having to repeat yourself in future projects.
  4. Even if I don’t have all the resources or talent that I might need in order to implement a design, having a good design documents makes it that much more likely to inspire others to contribute something to the project.

A very simple Options system might consist only of a single screen. But as we’ll soon see, there may be need to break things up into multiple screens, especially if we have many different options or categories of options.

If we have multiple screens, we’re going to need a means of navigating between them. This can be as simple as a group of rooms with room_goto commands linking them up, or it can be something else.

To design our Configuration Options system, we need to address a few things:

  1. Features: What options do we want the user to be able to configure? What choices do we want each configuration option to have?
  2. Interface/Controls: How do we want to present these options to the user? How will the user interact with the interface to set it?
  3. Implementation/Integration: How do these configuration choices get applied, technically? How will these configuration options interface with the game itself?

Features

Some of these will be fairly standard, common to many games, while some will be highly specific to the specifics of this game. I’ll address the standard ones, but don’t worry — once you see how we implement the standard features, it will be easy to set up config options for the features that are unique to your game.

You don’t need to support all of these options, but the following list is a good start for what you might want to consider:

Graphics

PC hardware very commonly has different graphical capabilities, due to differences in hardware, particularly the video card and monitor. While just about any video card is going to be capable of playing most Game Maker games at full quality, there is still the monitor to contend with.

Display settings

It might be easiest to force a specific display mode, but that’s not a flexible approach and may not work for all players. By far, it’s better to assume that the display mode the game starts up in is the player’s preferred (or only) graphics mode, and leave it as is.

If you want to enable everyone to play your game, it’s a good idea to give them some control over how the graphics of your game will be displayed on their screen.

The easier approach is to allow the player to set the display settings through the computer’s control panel, and just run in whatever mode the display is set to when the game runs.

More professional looking games usually offer the play an in-game configuration menu that allows them to change the same settings without having to leave the game program. It’s a convenience, to be sure, but it does keep the user in your game.

Keep in mind, too, that in GameMaker, there’s a distinction drawn between the Display (the physical hardware), the Window, the Room, and the View. Most of what you might think could be accomplished by forcing a specific display configuration can be better accomplished through Widow, Room, and View settings.

  • Fullscreen or Windowed mode?
  • Display resolution
  • Aspect ratio
  • Refresh rate
  • Color depth

Fullscreen or windowed mode?

Most games play best in fullscreen mode, but sometimes players like the option of playing inside a window, as it allows them to switch between other applications more easily. The downside of this is that it becomes all too easy to mouse outside of the game window, and lose focus. You can set the game to pause if the window loses focus, but this is still annoying disruption and can mess the player up even with pausing the game.

When to run in a window?  As a general rule, I like to develop and debug my game in windowed mode, since it’s easier for me to get at other windows that I’m working in. But for finished games, I usually like the game to run fullscreen. I want the game experience to be distraction-free.

That’s not always the case, though. Casual style games, pausable games, puzzle games, and turn-based games that wait on you to act are good candidates to have a Windowed mode as an option.

Resolution

These days, it’s probably not necessary to change the display resolution. Just about everyone uses LCD displays with fixed resolution. While these screens are capable of emulating other resolutions, they do not look as good when they do. Games for mobile devices of course will play on a device with a specific resolution that cannot be changed.

In any case, the game should never force a specific resolution on the player; you may want to offer the player controls to allow them to change the resolution for themselves within your game interface, though.

If a player wants to set a specific resolution, they can always just use the display settings control panel on their computer. If you want to provide an interface for this to them in your game, you can, but it’s a convenience or luxury feature, not a necessity. Supporting multiple resolutions means a lot of extra work and testing for a developer, so unless you’re a professional studio with the resources for this, it’s probably better to focus on supporting one resolution well.

Don’t worry about supporting every possible display size right away, the amount of work it takes to do it well will kill your project. Instead, focus on making the game as good as it can possibly be in one default resolution, and if your game ends up being popular enough to warrant it, you can build resources (primarily different sized rooms) to support other display resolutions better.

If you do change display resolution in the game, keep in mind a few things:

  • Always change it back when you’re done. Use display_reset() for this. Keep in mind if the game crashes, this doesn’t get called, though, and may leave the computer in a resolution the player doesn’t want. This can panic a non-technical user.
  • Don’t change display settings without first testing them. Use display_test_all() with the settings you’re about to set, before you actually set them. Be sure to have some fallback code that gracefully handles what takes place if the new settings don’t test OK.

You probably do want to know what resolution display the game is playing on, though. There are a lot of reasons to need to know this. Use display_get_width() and display_get_height() to detect the display resolution. Note this will return the current settings for the display, not what the display’s maximum or native resolution is.

You should decide the minimum display resolution you’ll support. GameMaker’s default room resolution is 640×480, which is the old VGA standard resolution. This is a very safe resolution to use, because just about any display will support it, but is also quite tiny these days. It’s still not a bad resolution to start out with, though. The smaller the minimum resolution you support, the more devices your game will run on.

It’s good to support larger resolutions, too, of course. Most people do have larger displays these days, and it’s desirable to utilize all that space effectively. Very large display resolutions can introduce performance issues, though, so test your framerates when running at maximum resolution, and make sure they’re acceptable.

If you’re targeting a specific mobile device, learn what its native resolution is, and use that. Read up on guidelines for Android and iOS development to learn the recommendations other developers follow.

To accomodate other resolutions, there are a variety of approaches. You can create a series of rooms and HUD graphics to provide a tailor-fit screen for every resolution you support. This is a lot of extra work, though. Scaling the game to fill the display can be an OK approach to take, and requires a lot less effort, but will result in a less attractive game with blurry edges due to the way the Game Maker runner handles scaling graphics. Another approach is to letterbox — draw the game in its standard resolution at a fixed 1:1 scale, and leave a black border around the edge of the screen, framing the game window. This can be good, too, but if you have too much black border it can be annoying.

Aspect Ratio

These days, you also have to consider aspect ratios, the ratio of the width and height of the screen. In the old days, computer monitors and TV sets in the United States all used 4:3.

Today, it’s a different story. On the desktop alone, people may have 4:3, 16:9, or 8:5 (16:10) displays. 16:9 is pretty quickly becoming the most common, particularly in 1920×1080 (1080p), and is also the ratio of HDTV, so if you have any desire to port your game to a game console, you may want to start out at 16:9.

And there are still others, albeit less common ones. If you’re planning on targeting a mobile platform, you’ve got even more possibilities.

If you’re building an HTML5 game, keep in mind that the browser window “chrome” (menus, toolbars, etc.) all take up space as well, which should be subtracted from the available display you have to run your game in, and this can change the effective “aspect ratio” of the web page unpredictably.

Enable/disable special effects which may affect performance (such as particles).

There are two main reasons for making these configurable: performance on slower machines, and user preference. Some players don’t like effects-heavy games, and prefer a sparse, cleaner visual experience without all the bells and whistles. Sometimes the screen can become so cluttered with particles that you can’t see the action, and it hurts your game rather than enhances it. So it’s nice to allow the player the option to not have these things in their game.

Refresh Rate and Color Depth

These settings are controllable in GameMaker, but there’s almost no reason for it. Most games shouldn’t have any need to mess with the color depth of the display.

In the 1990’s, it was more common to see variety here, but these days it’s pretty safe to assume that the computer will be running in 32-bit color mode. Oddball machines might be running in 16-bit or 24-bit color, and even more rarely you may encounter a display configured to run in 16-color or 256-color mode, but these are rare, and probably won’t have the necessary hardware to run a GameMaker game adequately anyway.

Refresh rate is probably also safe to leave alone. This setting is more pertinent to CRT displays, which are rapidly disappearing from the desktop computer landscape. Most LCD monitors use a 60Hz refresh rate, although there are LCD HDTVs that use 120Hz or 240Hz refresh rates. Older TVs used 30Hz.

Some people can notice a difference between refresh rates, and can tell you readily just by looking what refresh rate a monitor is using, especially if they are familiar with the display in question, but most people can’t, and don’t even think about such things if they’re even aware of them.

Some game developers will say that it’s a good idea to sync the room_speed of your game to the refresh rate. Keeping FPS and refresh in sync, or at least in a whole-number ratio, is not a bad idea. But the better way to do this is to set your room_speed to the display_get_frequency() or just assume a refresh rate of 60 and use a room_speed of 30 or 60. Keep in mind that regardless of what the room speed is set to, it’s fps that is the actual frame rate, and this usually fluctuates a bit.

Sound

  • Master volume
  • Music volume
  • Effects volume
  • Mute

Again, for the most part, these configuration options could be set by the user outside of the program, by using the volume knob on the speaker, or through the Sound and Volume control panel. But it’s a nice convenience to provide an interface to the user so they don’t have to leave your game to make adjustments. The nicest one is the separated music and effects volume. This will allow the player to adjust the mix to their taste.

One important thing to do is to remember the user’s preferred volume settings and automatically set them when the game runs, and set them back when the game exits.

The harder task will be to separate the volumes for the Master, Music, and Effects volume controls. Mute is actually very simple, and there are a few techniques that can be used. One way is to have a global variable called “mute”, and to set up a conditional before each and every sound function call. This is an inferior approach because it means you have to make sure you catch every single sound function call in all your code, whichis a pain to program. The other problem with it is that all those extra if (mute){} checks take processing power at runtime, albeit a tiny amount, it still adds up and could conceivably hurt performance.

The better way to handle mute is to simply setting the volume to 0. This is done with the sound_global_volume() function, which we also use for setting the master volume. The sounds still play, but at 0 volume, you don’t hear them. You don’t have to add code for every sound_play and sound_loop function in your code. And since the computer doesn’t have to ask every single time whether the game is muted or not, it’s a lot less processing. sound_global_volume(0) mutes your game, and sound_global_volume(1) restores the master volume to full. Use a global variable to store the setting for the master volume as well, so instead of restoring the volume to full blast on unmute, you set it back to the master volume value.
globalvar master_volume;
//master_volume is set in the config screen.
mute() {sound_global_volume = 0;}
unmute() {sound_global_volume = master_volume;}
You can put the Mute function into your game configuration menu, or you can make it more readily accessible to the player by creating a control for it that they can access while the game is playing.

Separate volume controls for bgm and sound effects will take a little more work, using the sound_volume() function to control the volume for each individual sound in your game, so we’ll cover that in detail later.

Note: GameMaker Studio 1.1 introduces an entirely new audio system. The above code samples work with the old system.

Controls

  • Provide the player with a screen showing the current settings, and allow them to set up their own custom settings.
  • Allow the player to save their custom settings as a profile, load from a profile, delete profiles.
  • Allow the player to reset the controls back to their default settings, or to select a custom profile (such as for different keyboard layouts, etc.).
  • Provide the player with options to use various input devices (keyboard? mouse? joystick/gamepad?)

Difficulty/Game Options

  • Difficulty (Easy/Normal/Hard)
  • Starting level
  • Enable/disable (or throttle) specific features
  • Number of lives
  • Text size/speed (if you’re displaying lots of dialogs)
  • etc.

This part is highly dependent upon your game. You can set up an interface to allow the user to set these things, but integrating them into your game will be highly dependent upon your game. Some things (number of lives, starting level) will be trivial to implement and integrate; others will take a great deal of design sense and playtesting.

High Scores/Achievements

An Achievements system, again, will be highly dependent on your game. But we can probably provide some abstractions that make it easier to implement your achievement system in a consistent way, such that the specifics may be different from game to game, but they way they are handled will be the same.

Some features we might like to see:

  • Record more than 10 high scores
  • Record other types of achievements
  • Record achievements per player account
  • Clear achievements
  • Upload scores/achievements to an online “Hall of Fame” server

Localization options

  • Language
  • Keyboard layout – keyboard layout could tie in well with the Controls. A user with a non-QWERTY keyboard could set that here, or have it be auto-detected from a system variable, and automatically update the keyboard controls with default keys appropriate to the layout map of the local keyboard. But then, the user should still be able to override these with their own preferences.

Save States/User Profiles

If your game stores user profiles or save state data, provide an interface to the user to do things with them. Common activities include:

  • Create new
  • Delete
  • Copy
  • Rename
  • Edit info (for user profile data, such as user name, password, and other profile data).

What’s in the save state file will be a bit beyond the scope of this series, and in any case should be highly dependent on your game. While I won’t tell you what to put in your savefile, I can tell you how to set up some file i/o functions that will enable you to read and write your savefile, and maybe some suggestions for how to protect this information, validate it, and format it.

It’s also a good idea to save the configuration settings themselves. Configuration settings (graphics, sounds, etc.) should be separate from game savestate data (My character’s name is XYZ, He is level N, his inventory consists of…, he has visited the following locations… he has achieved the following goals… etc.)

We have a few design choices for how we want to do the config save. The simplest would be to simply revert to defaults every time the game is launched (ie, not save anything, but remember a basic set of options that will definitely work on any system the game is run on.) From a user’s perspective, however, this would become annoying, as they will need to re-configure settings to their taste every time they quit the game. The next simplest approach would be to remember what the settings were the last time the user set them, and to remember the defaults in case the Last config profile gets corrupted.

This is probably as far as you really need to go; but once you are saving profiles, you’re not too far from allowing the player to save multiple configuration profiles, or per-user profiles. We’ll probably implement this later on as an advanced feature.

  • Other stuff

  • Network: These days, you may also want to have configurations options for network (TCP/IP settings, firewall/proxy server settings, etc.)
  • Social: Or you might want to have some kind of social networking features, such as sharing your game progress with your Facebook and Twitter friends, inviting friends to try out your game, or even send friends in-game items to help them, and so on.
  • Hall of Fame/Achievements: Or a “submit high score to server” feature. Or you might have a registration and payment screen.
  • Update Checker: Or a “check for updates/download/install” feature.

These things are much more complex to design and implement properly, and as such will be outside the scope of this tutorial for now, but it’s good to think about them!

Personally, I would like to see these type of features built in to Game Maker, and I hope that YoYoGames will incorporate features like this in time. When I say “built into Game Maker, I don’t  just mean having a library of available GML functions that one can use to build a configuration system out of. That is, after all, what we are going to do with this project. What I mean is, it would be nice if such a system existed as a ready-made component that you could just drop in to any project, and set up with just a few clicks or lines of code.

These features, and the interface the user will interact with to manage them, will be challenging and time-consuming to implement, and are not really “the game”. A good configuration system and interface is excellent polish for a professional-quality project. Game Maker’s purpose is to make game development easy by doing the hard technical stuff for you. So far, they’ve done that by focusing on the in-game building blocks that a designer would use to produce a play experience. Now that they’re turning Game Maker into a more professional tool, I hope that they’ll start thinking about including these kind of features, too.

Until then, we have to fend for ourselves. The above list of features represents a significant amount of work that we need to do. Setting up a system that is flexible enough to allow us to do this easily is no small task. If I’m lucky, by procrastinating long enough, I may find that they end up doing the work for me:) If I am going to do all this work, then I want to get the most return for that work that I possibly can by making a re-usable system that I can apply easily in any game. This means a de-coupled, generic system that can be adapted easily to a wide variety of projects. This is a good situation to create a Game Maker Extension (.gex). However, an extension will not give us a complete system — an Extension allows us to package a library of useful new GML functions that we write, but our built system will also need room, object, sprite, and sound resources, and a .gex cannot include those resources. Ultimately, this means that we may not be able to realize a dream of a drop-in system. But even providing better building blocks to create such a system would be better than nothing.

To begin, we’ll start small, and implement some basic things, and then iterate and refine our solution until we have something that hopefully works really well for a wide variety of games.

In our next article, we’ll discuss the code needed to make these configuration settings, as well as how to store and retrieve them.

Game Maker Studio Automatic Updates Failures (and workaround)

games, reviews
2 Comments

YoYoGames has been releasing updates to Game Maker Studio at a very fast pace lately. For a while now, new builds have been released every few days now, and it seems like every time I fire up the development environment, it’s got another update for me.

The last two or three of these have been extremely problematic, with very slow downloads, and repeated silent failures of the updater to run when the download shows that it is completed and the update is ready to install.

In the past, I have found that (on Windows 7, at least) one or two things might make the update process a little more reliable: launch Game Maker using “Run as administrator”, and exit the main Game Maker program while running the updater app. I’m not sure if these really do make a difference or not, but in the past when I tried these measures it seemed to help. But last night none of this made a bit of difference.

Yesterday, I spent many hours patiently waiting for the latest update to download. Each attempt took an hour or more, and when the updater indicated that the update was complete and ready to install, nothing would happen — it would fail silently, and on next launch, prompt me to re-download the same update again.

I tried looking for an alternate way to download the update, and it was difficult to find a direct link to the file — the only way to obtain it seems to be through the YoYoGames store. Eventually, I found a link that someone provided in the Game Maker Community forums, and began downloading it with Google Chrome.

About an hour later, I saw the download terminate as though it had completed successfully, but when I checked the file size, only about 50MB of the 93MB I was expecting was there. Obviously, an incomplete installer won’t work, so that appears to have been the culprit all along.

It’s clear that auto update fails due to heavy server load causing the download connection to fail, resulting in an incomplete download. When the program tries to run the update, it fails silently when it detects that the downloaded file is incomplete. When it tries to re-download the file, it starts over from 0% rather than resume from where it left off. These re-try attempts only add to the server load, and users re-trying but never succeeding only end up exacerbating the problem.

Even with the direct download link, if YoYo’s server is under heavy load, the download would fail when I tried to initiate download using Chrome. At times that I’ve had problems running the update, I’d get speeds of ~14kbps, which is terribly slow considering I’m on a cable modem that routinely tests at 20mbps. Under normal circumstances, this download should take a minute or two, not an hour.

Game Maker Studio seems to be a victim of its own popularity. YoYoGames needs to add server capacity to address this issue. Some mirrors or a CDN (content delivery network) would alleviate the problem. But the updater is to blame as well: It should not fail silently when the download fails and it has an incomplete file. By telling the user that the download is complete and the installer is ready to run, the user is mislead and does not have any way to know what the problem really is.

It would also help a great deal if the Auto Updater supported resuming partial downloads, rather than discarding a failed download. That way, users could complete the update after several attempts, rather than continue re-trying and starting over, and continuing to place a high demand on the server. After they complete the update process successfully, they’ll no longer place demand on the server, and it will become more available to others who need the download.

When the server was under heavy load, the only way I was able to complete the download was by using Orbit Downloader to handle the download. Orbit is a specialized download tool for Windows with robust capability to resume downloads. With it, I was able to successfully complete the download where Google Chrome and the Game Maker auto update feature both failed. Once downloaded, I ran the update manually, and everything worked as it normally should.

A bit of warning, I consider Orbit to be an annoying application, borderline malware. The installer wants to change your web browser’s default homepage, which it has no business doing, and it wants to install a toolbar. It is somewhat intrusive in the way it tries to integrate itself with the operating system and any browsers it detects. It’s nice that it has those capabilities, if you want to completely replace your normal downloading with Orbit, but if you don’t, it still wants to insinuate itself so that it always downloads anything you ever want to download.

It also has various social network integrators which have no point (what, am I supposed to Share with my friends on Twitter and Facebook everytime I download something, what it was, and let them know the link? Get real!) Also, it will — without asking — scan your computer to check for out of date applications, and notify you of available updates. Unfortunately, while it sounds like this would be a useful feature, it does not actually make downloading the updates any easier, and is frequently error prone as to what the latest version number is, leading to some false positives.

However, Orbit’s core feature of downloading anything faster and more reliably than just about anything else is good, as long as you can keep the rest of the junk that they’ve built around it tamed. Just be careful when installing the program to say no to most of the stuff it wants to offer you.

Otherwise, try to download updates during off-peak times. Early morning (6-7AM) if you’re in UTC-05 (Eastern US) seems to be good currently.

Currently, the form of the direct download link is:

http://store.yoyogames.com/downloads/gm-studio/GMStudio-Installer-1.0.exe

(I’ve been informed that this url will always contain the most recent build.)

Hopefully if users start using the advice above, it will help reduce the load on YoYoGames’ server, making the experience of updating better for everyone.

Make a Configuration System in Game Maker, part 1

design, games, programming
2 Comments

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

Game Review: Home by Benjamin Rivers

games, reviews
3 Comments

Last night I attended Akron Film + Pixel‘s Indie Games: Play and Discuss, and (among other things) played a game called Home, by Benjamin Rivers. As it turned out, it seemed that there was a bit more Play than Discuss at this event, so I thought I’d review it the day after.

This game held my interest enough to play through it once, which was all I had time for. I don’t know that I’d play it again, although I gather from the ending that if I did play it again, it would be a different experience of a different story, assuming I made different choices.

Unfortunately, I didn’t find the choices to be all that interesting. Do I pick up the gun or do I leave it where it is? Do I pick up the key or do I leave it where it is? Do I pick up my wallet now that I’ve found it, or do I leave it where it is? Do I flip the switch or do I leave it alone for now, only to come back later and flip the switch because that’s the only way forward? Do I look at the thing that automatically highlights when I walk by it so I can get another element of the story, or do I no longer care and just want to continue walking until I get to the end of the game? I DON’T KNOW, ALL THESE DECISIONS ARE TOO MUCH FOR ME! WHAT WOULD YOU DO?!

This and many other decisions like it await!

Apparently if you make different choices, the story that unfolds in flashback as you walk through this amnesiac world trying to put the pieces together and figure out if you’re a murderer or not changes. Not that your decisions affect the future, but that your decisions somehow retroactively affect the past, such that, as you recall in flashback what happened before you blacked out, what you recall will be different based on what you did or didn’t decide to do in the present.

This might make it seem interesting, but when all the story elements are as boring as they are likely to be (based on the ones I actually saw when I played through it), probably you don’t care what other stories you might have crafted had you made different decisions enough to actually go back and make those different decisions in order to find out. After your play-through, there’s an invitation to share your story on the game’s web site, so if anyone actually does that, I suppose you can find out how things worked out differently for them based on their choices, but it all seems so boring an uninteresting that I really have to question the sensibility of anyone who’d actually spend time describing what they’d been through on a web site, other than as a to warning to others. Ahem. Like this.

Home bills itself as a horror game, but the only thing horrible about it might be that it could have been interesting and immersive, but wasn’t. Each play-through feels very linear (despite the fact that you can make choices that change what you remember happened in the past), provides no danger or challenge or conflict, every bit of blood in the game has already been shed before you begin playing, and the tension that rises as the story unfolds while you re-discover your recent past never sufficiently pulls itself into the present moment. The apparent climax, when you decide whether you find the body of your wife in your cellar, or whether you don’t find her and realize that she must have never actually existed except as a delusion, leaving you with even more unanswered questions that never get answered, is the textbook definition of anticlimax.

As I played, I kept expecting to run into someone else — anyone — maybe my girlfriend/wife, maybe someone (a familiar friend? a stranger?) I’d need to rescue or team up with in order to survive, maybe the killer(s), or even the police — would they keep me safe? Would they arrest me? Would I have to convince them of my innocense somehow? Were these items I was picking up going to incriminate me? Did picking up the gun protect me from the murderer finding the gun and using it against me, or did it implicate me in the murders that had already happened, whether I’d actually perpetrated them or not? There were so many ways which the plot could have developed that would have made the game vibrant and interesting. But none of that ever happened.

What else can I say about it? The pacing is slow. There’s no run button, no jump button, no way to go any faster through the game. There’s a tiny bit of exploration offered, but it’s not terribly interesting. The pixel art graphics are OK to pretty good, and I do like pixel art, but when blown up to fullscreen, there’s so much jpeg artifacting (or what looks like it) that it ruins the work put into it.

Worst of all, there are parts where I wanted to go backward, and was prevented from doing so by the game telling me “You don’t want to do that.” I think I should be the one who decides what I want! I guess I should thank it for sparing me from wasting time going back to someplace that will not advance the game, but it’s much better to provide an external reason, as it does in certain parts of the game, than a “you just don’t feel like it, sorry” reason that is total bullshit.

And there are so many unanswered questions: What happened to everyone? Who was the killer? Is anyone still alive besides you? Why do you need a flashlight everywhere you go, even outdoors, or indoors in places where there should be light?

In fairness, I did not get to play the game with sound, so it could be that I’m missing out on some crucial elements that would have made the experience more enjoyable, even worthwhile. And to be honest, I didn’t find myself hating the game so much while I was playing it, as I did after once I had been through everything and realized that that’s all there was. It just built up to something that it never delivered. I did continue playing it, hoping that the plot would deepen until it got better. It just never did. Home tries to offer an interesting interactive narrative, and while it does contain a good bit more narrative than many videogames, that doesn’t make it good narrative, or a good videogame. Other narrative art forms give you way more (read any halfway decent book!) and other video games give you more as well (pick your poison).

I don’t get it. There are plenty of positive reviews for the game. Is it possible that I simply made all of the most boring choices possible, resulting in an anemic plot where nothing drastic actually happens, in spite of copious dead bodies found nearly everywhere, without sufficient explanation other than maybe you did it? Or is this some kind of “art game” that is great art because it turns the notion of a game on its head, and offers for your consideration that a game can be boring, thereby challenging your notions about what games are about?

I won’t recommend staying away from Home if you are in the mood for reliving the experimental 80’s text adventure genre in a rather dull implementation that offers barely any puzzle beyond how to navigate around the screens and no interesting choices or decisions. If you absolutely have to play every game in this genre, then so you shall. Otherwise, there’s probably something better you could do with your time, like trim your toenails or perhaps watch an aquarium full of snails.

Game Review: Superbrothers: Swords & Sworcery EP

games, reviews
Comments

Yeah, way late to the party on this one (as usual — I’m quite patient these days when it comes to to getting around to playing games, and I don’t have to be the first kid on the block to play something. I’ve grown immune to hype and appreciate bargain sales.)

Speaking of which, Humble Bundle 5 is out, and as of this posting you have about 7 days left to buy it for $NameYourPrice. I really suggest you do. First, because naming your own price is awesome. Second, because the games are so worth it: Bastion, Amnesia: Dark Descent, Psychonauts, LIMBO, and Superbrothers: Swords & Sworcery EP. [Update: They just announced the addition of Braid, Super Meat Boy, and Lone Survivor to the Bundle!] Thirdly, they’re DRM-free. Fourth, they’re cross-platform, playable on Mac OS X, Windows, and Linux.

Of the five titles in the Bundle, so far I’ve only played Superbrothers: Swords & Sworcery EP, or S:S&S EP as it’s commonly abbreviated. I’d longed to play it since I first heard about it, but considering it was launched as an iPhone game and I do not own an iPhone, that was kindof hard.

The EP release was an enhanced version released for PC/Windows, and I feel it probably made the transition from touchscreen and tilt sensors to traditional PC reasonably well –although since I still have never played the original platform version, it’s hard for me to say. Still, it’s a very enjoyable experience to play it on a PC.

Despite not being all that challenging, I’ve really gotten into Superbrothers’ Swords & Sworcery EP, I guess mainly due to the flavor and vibe of it. While disarmingly crude at first, the minimalist beauty of the pixel art graphics is charming and evocative, providing incredibly vivid mood and atmosphere, the audio effects and music is absolutely excellent (who is Jim Guthrie?!?), and the sense of adventure is there.

It has a bit of the feel of a tabletop RPG come to life. There’s no dice-rolling, no stats and leveling, and very little hack and slash, but something about it reminds me of children making a game out of telling each other quasi-medieval fantasy stories, and figuring out weird puzzles that they’re making up on the spot as they go along. That sense of adventure, and I’ve never had it so full-flavored in a computer program. The anachronistic text narration and “regular guy” voice acting amplifies the effect, perfecting it.

The game does not focus on combat, which is rudimentary yet satisfying, and instead the game seems mostly to be about exploration and puzzle solving. The puzzles, once I got a feel for the first few, have actually been quite easy, so far, but it took me until about 30% completion to actually figure out how to see what I’m supposed to do.

Once I caught on, they became rather fun to solve. The early puzzles were more frustrating than challenging, with lots of staring at the screen and wondering wtf I’m supposed to do, while clicking, tapping, dragging around all over like mad until I finally accidentally do something, then puzzle out the rest of it from there. But as soon as I learned the idioms of the interface and became immersed, I was hooked. From that point, the puzzles still weren’t all that challenging, but were delightful and satisfying to solve anyway for some reason.

The way the story is presented, using variously camera pans and zooms, music, visual cues from the in-game characters gesturing or barking at you, on-screen text, is very well thought out and executed nearly flawlessly. It’s a highly polished indie game and the developers’ artistry is fully realized.

Overall as I played, I felt relaxed and like I was having a pretty good time. The fights gave me a little bit of tension, but only a little bit. There was a certain feeling of dread and pressure, but after dying a few times and realizing that the consequences of doing so weren’t too bad, and got a feel for how the combat system works, I was able to calm down again. The game never punishes you excessively for failure, which makes for a soothing and relaxed play experience. I don’t think I’ve ever played a game where the combat system is both turn based yet fluid and time sensitive, and where patience, anticipation, and timing is more important than reflexes and rhythm.

If you are lucky enough to have enjoyed the 1991 classic Another World [US Title: Out of This World], I found that I had a very similar emotional experience with this game. And that’s a very high compliment.

Game Maker Studio 1.0 Launched

development, games, reviews
Comments

Today YoYoGames announced the launch of Game Maker Studio 1.0. This long-awaited release finally gives Game Maker developers the ability to build games that run natively on Windows, OS X, iOS, Android, and HTML5. I’d heard some time ago that there was a Symbian module in the works as well, but I don’t see any mention of it in their releases — I doubt that it will be missed. Also announced today is that Game Maker HTML5 is no longer a standalone product, and has been folded into Studio.

I participated in the HTML5 beta as well as the Studio beta, and reported a fair number of bugs. While I’m enthusiastic, I think it remains to be seen how successful the new Studio will be — the impression I’ve gotten from my limited work in HTML5 is that the differences of each platform impose constraints on a unified project, and often during the beta I found that stuff that worked in a Windows build didn’t in HTML5. Hopefully that’s all just part of the beta. I definitely like the direction YoYoGames has been headed in, and as long as they execute, it should be a good time to be a Game Maker developer.

The highlights of Studio:

  1. Multi-platform build targeting
  2. Source Control
  3. new built-in Physics features

Game Maker’s proprietary language, GML, is going through some redesign as well, but we probably won’t see the full vision for a time, until Game Maker 9 is released. With Studio 1.0, it seems that YoYoGames has started deprecating certain functions, in order to drop Windows-specific stuff and embrace a more platform-agnostic approach, which should mean that developers won’t have to worry about whether a given instruction makes is supported or makes sense on the OS they’re targeting. Hopefully this will encourage cross-platform application releases and make them the norm rather than the exception.

With the launch, YoYoGames announced pricing, and it’s a little different from what I expected. The base Studio Core (giving you Windows and OS X build capability) is $99. Considering that Game Maker Standard was $40, roughly doubling the price to give you access to OS X seems reasonable.

The HTML5 module is an additional $99. $199 was the original price of HTML5, so for $198 you get Studio with the HTML5 extension. I think a lot of Game Maker users were shocked at the price jump, but when you consider how cool it is to have the capability of distributing your games through the web with no extra plug in or extension needed to run, it’s awfully nice.

The mobile platform modules are another $199 each for OS X and Android. This means the full Studio suite will run a developer almost $600, or 15 times what it costs for Standard. YoYoGames justifies this by saying that these are optional modules for professional developers, and I’m sure it costs them lots of money to develop the runner for these platforms. It’s a bit odd to think that for just $200 you can reach 3 major platforms, but to get another two platforms it triples the price. In any case, the idea seems to be that the ease of selling on the mobile markets makes it worth the cost of the tools, and I’m glad they tiered their pricing rather than force everyone to pay full price all or nothing. Starting out at $99 or $200 is a lot more reasonable, and buying the mobile modules later takes a bit of the sting out of the price. Compared with Unity Pro, which is $1500 for its base, and an additional $400 each for iOS and Android, it’s still quite inexpensive as a professional developer tool.

Ludum Dare 23 Rankings are in

games
Comments

Here’s how Bactarium ranked in the Ludum Dare 23 Compo:

Ranking/1072 Category Score (out of 5)
Coolness 56%
#204 Innovation 3.41
#259 Theme 3.34
#431 Mood 2.68
#511 Graphics 2.75
#520 Humor 2.07
#545 Fun 2.62
#562 Overall 2.76
#587 Audio 2.07

Not too bad for my first LD48 entry, though certainly much room for improvement. Considering how happy I was to have been able to complete the game within 48hrs, I’m pretty happy with how it was received. It definitely wasn’t a great game, but it’s not bad, and has potential.

I’ve been working on a rewrite in Game Maker Studio which I hope will address some of the shortcomings that I didn’t have time to address in the compo.

The Early 80’s Arcade Aesthetic

Best Of, design, games
4 Comments

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

Ludum Dare 23 postmortem 3

design, development, games
1 Comment

(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…)