Here’s another idea for a video game.

The theme of the game is “be consistent”. It's a minimalist-styled 2D platformer. The core mechanic is that whatever you do the first time, the game makes it so that that was the right action. Examples of how this could work:

  • At the start, you're standing at the center of a 2×2 checkerboard of background colors (plus appropriate greebles, not perfect squares). Say the top left and bottom right is darkish and the other quadrants are lightish. If you move left, then the darkish stuff is sky, the lightish stuff is ground, and the level extends to the left. If you move right, the darkish stuff is ground, and the level extends to the right.

  • The first time you need to jump, if you press W or up then that's the jump key, or if you press the space bar then that's the jump key. The other key does something else. (This might interact poorly with an initial “push all the keys to see what they do”, though.)

  • You meet a floaty pointy thing. If you walk into it, it turns out to be a pickup. If you shoot it or jump on it, it turns out to be an enemy.
  • If you jump in the little pool of water, the game has underwater sections or secrets. If you jump over the little pool, water is deadly.

I have come to realize that I have more ideas for programs than I'll ever have time to write. (This means they're not actually all that significant, on average — see all that's been said on ‘ideas vs. execution’.) But maybe I have the time to scribble a blog post about them, and that's stuff to blog about, if nothing else.

So, a video game idea I had today: reverse bullet-hell shooter.

A regular bullet-hell shooter is a game where you move in a 2D space dodging an immense number of mostly dumb instant-death projectiles launched in mostly predefined patterns, and trying to shoot back with dinkier, but better aimed, weapons. Instead, here you design the bullet pattern so as to trap and kill AI enemies doing the dodging.

The roles seem a bit similar to tower defense, but the space of strategies would be considerably more, ah, bumpy, since you're not doing a little bit of damage at a time and how it plays out depends strongly on the AI's choices.

That's probably the downfall of this idea: either the outcome is basically butterfly effect random due to enemy AI decisions and you mostly lose, or there are trivial ways to design undodgeable bullet patterns and you mostly win. I don't immediately see how to make the space of inputs and outcomes “smooth” enough.

Here's another thing I've been doing: designing Portal 2 puzzles.

The Cube Goes in the Other Pit

(F)utile Independence

Balance, Beam

I’m probably going to keep doing this (as the inspiration strikes) — all feedback welcome!

I really haven't been posting very much, have I? It's mostly the job occupying most of my “creative energy”, but I've also been doing a little bit of this and that and not ever finishing something to the point of feeling like writing it up.

On the programming-projects front, I'm attempting to extract two reusable libraries from Cubes for the benefit of other web-based games.

  • Measviz takes performance-measurement data (frames per second and whatever else you want) and presents (in HTML) a compact widget with graphs; my excuse for not announcing it is that the API needs revision, and I haven't thought of a good toy example to put in the documentation-and-demo page I'm writing, but if you're willing to deal with later upgrades it's ready to use now.
  • The other library, currently in need of a good name, is a generalized keybinding library (generalized in that it also handles gamepads/joysticks, which are completely different). You define the commands in your application, and it handles feeding events into them. Commands can be polled, or you can receive callbacks on press and release, with optional independent autorepeat. It's currently in need of a name, and also of API cleanup.

I've been making some sketches towards a redesign of E (list archive pointer: starting here), basically to take into account everything we've learned over the years without being constrained by compatibility, but it hasn't gotten very far, partly because language syntax is hard — all options are bad. (The current E syntax is pretty good for usability, but it has some particularly verbose/sea-of-punctuation corner cases, and I'd also like to see a simpler syntax, with more facilities moved into code libraries.)

Closure is now available on Mac and Windows via Steam (previously on PS3). If you like platform puzzle games, or if you like games that play with the nature of the virtual universe, then you need to play this game. Convinced my description is inadequate for a purchase decision? Play the free Flash original.

I bought it as soon as it came out and while I haven't finished it, I've played through several of the puzzles and it is living up to what I'd hoped it would be. The one thing that bothers me a bit is the loss of the original version's 1-bit aesthetic. (Yes, I said 1-bit, not 8-bit. I'm talking about color depth, not word size.)

The draft-standard Gamepad API allows JavaScript in the browser to obtain input from connected gamepad/joystick devices. This is of course useful for games, so I have worked on adding support for it to Cubes.

This (about) is the only Gamepad API demo that I found that worked with arbitrary gamepads (or rather, the junk one I had around) rather than ignoring or crashing on anything that wasn't a known-to-it devices such as a PS3 or Xbox controller. (It's part of a game framework called Construct 2, but I haven't investigated that further.) It was critical to my early setup in making sure that I had a compatible gamepad and browser configuration.

(There's a reason for libraries having information about specific devices — the Gamepad API just gives you a list of inputs and doesn't tell you what the buttons should be called in the user interface — and these days you're almost expected to have pictures of the buttons, too. But there's no reason not to have a fallback, too. Incidentally, the USB HID protocol which most gamepads use is capable of including some information about the layout/function of buttons, but this information is often incorrect and the Gamepad API does not expose it.)

In order to integrate gamepad support into Chrome, I used Toji's Game Shim library, a very nice lightweight library which only adapts browser-provided interfaces to the current draft standards so that you can use the Gamepad API, as well as requestAnimationFrame, fullscreen, and pointer lock, without making your code full of conditionals or browser-specific prefixes.

I've got the notion to do an occasional Minecraft video series, mainly to show off my mechanism designs and otherwise increase the value (to other people) of all those hours I spend playing. I bought screen recording software just for the purpose.

However, I haven't gotten around to recording an “episode” yet (mainly because I wanted to start with a script to reduce the “um”s, and make sure I have a quiet environment, and that hasn't coincided with enthusiasm for the project). The following video is just a test of recording and uploading to YouTube; there's no voice-over and it's short.

Let me know what you think of this proposed endeavor. I figure to do tours of existing builds with a focus on mechanism, not playing on camera.

Cubes update

Friday, March 9th, 2012 21:46

Some new features in Cubes:

  • An automated test suite. It’s hardly complete coverage, but at least it exists and so can grow. (I ended up going with Jasmine for in-browser testing. I’m not a big fan of the Englishy syntax, but it does the job reasonably well and has niceties like rerunning individual tests and adequate support for asynchronous tests.)
  • Precise collision against rotated blocks: you can now walk up the slope of those funky pyramid blocks, and so on. Stairs, anyone?
  • Performance monitoring widget with fancy graphs. (If you click the “[-]” to hide it, then it won’t waste CPU time updating itself, either.)

I’ve uploaded almost all of my published Git repositories (previously hosted on a git-only server on on switchb.org, which is down at the moment) to my account on GitHub. Please update your remote URLs if you have any git clones.

The motivation for this change is simply that GitHub offers better visibility — an automatic web presence for each project, including viewing repository contents. I am not intending to depend on GitHub’s continued existence, of course; I still have local copies of each project, and additionally I plan to arrange so switchb.org automatically mirrors my GitHub repositories.

What I've just uploaded to GitHub also includes a project which I have not previously mentioned, timeline-ui:

A user interface experiment. Multiple types of time-series data, variously static/interactive, historical/future, etc. are displayed in a single view. (This was an idea I had floating around and which I used in 2010 for a class project; there is a lot more that could be done with it.) Written in Java.

I was going to write more about the concept, but I never got around to it; this will have to do.

List of projects just moved to GitHub:

[I was asked about Cubes “Where do you think you might take the game play next?” and it turned into this.]

My original motivation for creating Cubes was a combination of the “blocks out of blocks” idea — which itself came from immersion in the graphics of Minecraft — and also dissatisfaction with certain bugs, limitations, and design choices in Minecraft. As a result, I’m not just building a voxel game; I’m building a game that shares what I like about Minecraft.

(What I like about Minecraft, broadly, is survival and engineering — I like building structures and machines to make my virtual life easier.)

Now, creating a Minecraft clone would be lame, rude, closer to using someone else’s intellectual property, and just plain unoriginal. But I don’t have experience with what little exists of a genre of voxel building games to synthesize my own thing, and I myself am looking for something like Minecraft. What can I do? Here’s what I’ve been trying:

  • Be different.

    Whenever I see an opportunity to do something specifically unlike Minecraft, that doesn’t compromise what I’m trying to do, I take it and see what happens. However, most of these experiments have failed; for example, Cubes originally had a larger-scaled player character, but this turned out bad because it means tunneling and building is 8× more tedious, and it reduces the apparent size of the world. Also, it leads to thinking “OK, add this feature Minecraft has — but (superficially) differently!”

  • Be generic.

    This is my long-term goal, and it is one that ties neatly into the “blocks made of blocks” theme. The characteristics of blocks can be defined by building circuits (programs) inside them. What I’m aiming for is that by creating a blockset (collection of block designs which the player can build with), one is defining the game that can be played, by giving those blocks specific behaviors.

    In this way, I am working towards having a game which can be programmed to emulate Minecraft.

    (I have a working prototype of an importer for Minecraft worlds as well as for Minecraft blocks — that is, turning the terrain.png from a Minecraft texture pack into Cubes' 3D blocks — but I am not going to release that code until and unless I determine that Mojang doesn’t mind my doing so. I still love Minecraft and they deserve my not stepping on their toes that far.)

    However, this means both that Cubes itself needs to be very generic, and that the built-in example uses of such features should feel different from Minecraft.


So, returning to the original topic of “where am I going next”, I need to add the following functionality to the game world:

  • Extend the circuits feature so that there can be blocks that are active and interactive (e.g. opening and closing doors, “physics” like Minecraft falling sand and growing plants).

  • Add moving objects (for vehicles and mobs). I intend to generalize these so that they are worlds in themselves — this will allow large or unique vehicles, and mean that they can be designed using the same game tools.

  • Add some form of resource constraints/conservation laws (as in Minecraft survival mode) — that is, you have to gather stuff to make it into other stuff. I haven’t figured out specifically how I want to do this yet, and this seems particularly tricky to make programmable. One idea that keeps coming to mind is that when you break a block, specific subcubes are “resource cubes” (according to their type in the block world) which you collect, and in order to place a block you need to have the corresponding resources for its type. However, I’m not sure I like the “raw material counter” feel of this.

  • Add player attributes that can be modified (e.g. health) so that e.g. death, or other effects-by-the-world can be supported.

Less grandly, I plan to work on one of these specific technical features soon:

  • Allowing circuit blocks to be rotated to change their connectivity. (Right now, circuit blocks have specific faces — e.g. on a certain one the +X direction is always the output.)
  • Figure out what more circuit primitives I want to add. (Right now, the circuits are definitely not Turing-complete, and not capable of all the effects on the world they should be, but there are also already a lot of different primitives; I may have to invent new block-picking UI just to make them practical.)
  • Add moving objects (bodies) — things which can collide with the terrain as the player does. The current code is entangled with player behavior, and the player does not persist in a world.
  • Add subworld/multiple-world handling — the ability for more than one world (grid of blocks) to be present in the same space. Right now, there are hardwired assumptions that the player is in the single world’s coordinate system.

Another core feature which is currently missing is the ability to design a blockset and then reuse it for multiple worlds. The problem right now is that we're using a simple object-graph serializer, so each world has its own blockset which is modified independently. To fix this, it needs to be possible to save a blockset under a user-visible name, and have individual worlds which reference that blockset; also, the world generator needs to decouple blockset generation from terrain generation. The “persistence” framework which added support for multiple worlds is a step towards this; the main thing I am pondering is what the semantics of these separate-named-persistent objects are and what the user interface for editing them is.

I need to stash this info somewhere; might as well be well-indexed.

Stereo photos such as those taken by the Nintendo 3DS, with a .MPO file extension, are actually JPEG right-eye images with the left-eye image embedded as extra data. They can be interpreted as JPEG files (perhaps after changing the extension to convince your software to read them), and the left-eye image can be extracted with exiftool, as follows:

exiftool input.mpo -mpimage2 -b > L.jpg

A standalone right-eye image without the extra data can be produced with

exiftool -trailer:all= input.mpo -o R.jpg

Source, via.

(no subject)

Sunday, August 14th, 2011 14:30
I just wrote up a couple tips for debugging simple physics simulations (of the sort you use in 2D games), in a bit more detail than the context required.

The Witness

Sunday, August 14th, 2011 07:54

So, this is potentially interesting. The developer of the game Braid has started a new project, The Witness. It’s apparently going to be 3D, set on an island, and involve solving puzzles scattered around the island (while being able to move freely around it). Their blog is talking a lot about their graphics engine design as opposed to the gameplay — naturally, as graphics tech is more usefully shareable and isn't inherently spoilerish.

What particularly caught my eye as “I agree with this” was their post Experiments in Texturing. Good textures are hard; it's often easier to make a good, clean model than it is to make a texture that is not jarringly unrealistic. The Witness is putting a lot of emphasis on lighting: “We’re on a low budget here, being an indie game; so not only was it an open question how to solve the Ugly Texturing problem, but we also needed to solve it with relatively little manpower. I knew that, ultimately, we could just fall back on untextured geometry with lighting, if we had good precomputed lighting.” They go on to describe using textures as accents, to add texture rather than defining significant features of the object.

As a Minecraft player (structures are built of pre-textured blocks) and former Avara map designer (graphics engine does not support textures), I entirely approve of this approach.

I have updated the Minecraft topic at my web site, bringing it up to date with changes, adding many new links, and information about my new world. Also, I didn't previously announce this:

I am running a Minecraft server. I've been running one for a while, but it had a rocky start trying to run on a shared Linode. It now has a dedicated machine (though one which is rather old and running on a home cable connection) and is running 24/7.

The address is: mc.switchb.org

This server runs a copy of my single-player world, updated each day, so changes you make are not persistent (except for your inventory). This is a place to tour, or use for building experiments, not to live in. However, I have attempted to make it suitable for multiplayer use, with direction and instruction signs and multiplayer-capable rail stations (though most of the rail tunnels are single-track).

Feel free to suggest improvements to the facilities, or additional builds.

(Home sweet home.) (Cactus and flower farming.) (Mob tower and access routes.) (Rail hub station.)

(Note for those who have tried the server before: I recently fixed a problem causing new players to spawn nowhere in particular rather than at the spawn station.)

“Tile Game” was a game I wrote in the spring of 2010 as my final project for CI272 Visual Basic at MVCC. It was written in, of course, Visual Basic. I have just finished porting it to JavaScript and you can play it online.

I've written a new topic index page for my site: Games, simulations, and animations. Except for the note about Tile Game, everything on it is something I've already published.

Condensed list of the contents: Tile Game, Fire Worms, Mouse-maze, 15-puzzle, screen savers, Varychase, Linkage, Bouncyworm, Brownian Tree, pendulum animation.

I've added a mini wheat farm to my Minecraft world, just for the sake of building one. If you're interested in looking, it's southwest, with underground access branching off the spawn tunnel.

I've published my Minecraft notes and bookmarks.


This is a slightly different sort of addition to my site; it is a page that is nearly all information and links I've gathered rather than my own work. I've been wanting to write this type of page on several topics for a while now, having them be a place for:

  • material organized in a non-chronological way (unlike this blog).
  • bookmarks, which when in my browser are (a) hardly ever looked at after being created, therefore not benefiting anyone, and (b) are not accessible to me off my own computer.
  • keeping non-bookmark notes and documents in the same organization as bookmarks.

More fuzzily, I hope that giving myself this organizational concept will get me to publish more of anything. Here are some topics I hope to write about in the future:

  • Android apps
  • LaTeX (this would also be publishing existing notes)
  • Webcomics and other serial fiction

I've also thought about adding to various pages of my site automatic indexes of related blog posts (via tags), but I'm not sure it's worth the effort.

Minecraft

Saturday, October 2nd, 2010 01:02

(A view from the observation tower.) (Inside a cave.) (Home sweet home.)

On September 26 I bought Minecraft.

This game is a severe productivity hazard. Unless you count hollowing out virtual mountains as productivity.

(For those that haven't heard about this recent craze, Minecraft in its most interesting variant is basically a sandbox game with resource limitations and enemies. You get an infinite-other-than-coordinate-limits procedurally-generated world (often beautiful) made up of cubical blocks, with resources scattered (and buried) around it. And monsters whenever it's dark (i.e. nighttime and in caves). Then you get to reshape your part of the world by adding and deleting blocks, and crafting objects out of the resources you've dug up. First you build shelter, then you explore caves and build farms, then you build grand castles — or underwater bases — or intricate traps and mazes — whatever. It's very open-ended.)

I've put up an automatic copy of my world as a multiplayer server; just connect to switchb.org in Minecraft Alpha. (With the usual caveat that Alpha multiplayer is glitchy, so the mechanisms won't work as intended.) I may take it down if the load is significant, though.

(If anyone has already used this title, that wasn't my intent.)

Screenshot of the game.

“Fire Worms From Outer Space!” was a game I wrote in spring 2009 as my final project for PH115 Science of Multimedia at MVCC.

It was written in Macromedia Adobe Director, and designed as “with the structure of a shoot-em-up and the mechanics of a physics game”; you must defeat the enemies in each of a series of levels — by smashing apart their chains-of-spheresical bodies with your wrecking ball of an inexplicably orbiting asteroid.

Most of the development time was focused on getting the physics right; the graphics, sounds, and level design were all secondary.

(I'm not particularly a fan of Director; it's just what was used in the class. If I ever get around to it, I'll rewrite it in JavaScript.)

Play Fire Worms

  • Play on web (requires Shockwave plugin)

    (Please let me know if this doesn't work; I don't have the Shockwave plugin so I can't test it.)

  • Mac OS X app (standalone)
  • Windows app (standalone?)

Source

The Director file, plain-text copies of the scripts, and all of my saved development history (reconstructed; it was originally a bunch of directory copies) are available in a Git repository at git://switchb.org/fire-worms/. (No web view yet; need to do that.)

Other than the background image, credited in game and in “Title Page” to NASA, all elements of the game are Copyright 2009 Kevin Reid. I haven't gotten around to sticking a license on it; contact me and I'll get around to labeling it MIT or CC — let me know what license would be useful for what you'd like to do with it.