Thursday, May 29, 2014

Spring 2014 quarterly progress report

A progress report on "small" projects:

"Intimate, Infinite" is 80% done, and it's for the Series pageant at makega.me. It will be done soon. I've kinda surprised myself with how much I'm putting into it, so I think I'll sell it for pay-what-you-want.


"Vaquero" is about 50% done, and it's for the Space Cowboy Game Jam. It will probably be done soon.


"Peon" is about 50% done, and it'll be a larger project for most of June, alongside prepping Nostrum for exhibition at GaymerX2.

Tuesday, May 20, 2014

Notes on discontinuity and interiors in open world games

To enter a different level in Thief 4, you frequently have to mash [E] to pry open glowing windows (or lift fallen wood beams) as the game "seamlessly" loads the next level in the background. You will see this screen a lot.
An "open world" is a marketing tool / level design structure where the game world is gradually loaded or "streamed" as you explore it, so that it seems like one large long continuous level. In many respects, this continuity is an illusion; the game developers built the world in chunks and the game engine thinks of the world as chunks, but players experience the chunks as they're stitched together. It's an immersionist fantasy -- of no loading screens or progress bars, of seamless transitions between worlds.

But as I mindlessly mashed the [E] button on my keyboard for the 30th time to enter a different level in Thief 4, I realized that (a) this is a really bad attempt at hiding load screens, and (b) I tolerated the (brief but just as frequent) loading screens in Skyrim much better because those are honest about what they're doing. A loading screen unambiguously signals discontinuity to the player, a break between parts of the world. An open world overworld can only exist if there's an underworld beneath it, and I argue that it's okay (or better) if you clearly mark the borders because it's okay if we stop interacting with a game for a second.

When do open worlds choose to be discontinuous with a menu, loading screen, or lobby? When does one wait to "enter" an interior, to voluntarily break the flow of play?

Tuesday, May 6, 2014

DECK (Doom Engine Creator's Kit) needs artists and sound designers.


JP LeBreton has recently announced the "DECK" (Doom Engine Creator's Kit) project, an open-source public-domain all-in-one bundle of Doom technology: a game engine + editor + game assets + tutorials, all integrated together and easily accessible. It's intended to empower people to easily make cool lo-fi 3D first person games and it sounds really cool...

... but it needs help. It needs some Doom-style character sprites, some Doom-style environment textures / decoration sprites, and a lot of audio design. Pitch in and help build free indie game tools!

Here's my contribution so far, some painterly-ish pseudo-photo "medieval manor" textures:


It was kind of fun to work at low resolution without having to worry about shaders or 3D meshes or UVs or whatever. I recommend it.

Saturday, May 3, 2014

"SERIES" is the first MakeGa.me pageant theme!

"We make game, do you make game? MakeGame is a place for you to show some similar-minded folk what you're working on. Get feedback, discuss design problems, share inspirations. Every couple months we host a pageant. A month-long 'slow-jam' where we all make games to explore a chosen theme. Welcome!"
MakeGa.me is a new game development forum from the ashes of the former Super Friendship Club. A lot of the original guiding principles remain: to learn from each other and help each other make great work. To help motivate each other, there are monthly "game pageants" -- a game jam-like that de-emphasizes winning or losing. Ian Snyder's organizing the first one, focusing on the idea of a "series"...
"Instructions: Make a two or more small games all revolving around one central theme or idea that when taken together form one cohesive whole. Make the games good. For examples of this in other media, you might look to Thirty-Six Views of Mt. Fuji36 or Thirteen Ways of Looking at a Blackbird30 or [if you have other examples or items of inspiration, reply below!]

Starts on May 1st, finishes on May 31st. You're welcome to enter any media you prefer, games or not. Disobey any instructions, or follow them rigorously. If you haven't made games before, and aren't sure where to start on the technical side of things, just ask : there're plenty of people here who can give guidance."
Full briefing is here. Looking forward to seeing you all over at MakeGa.me!

Wednesday, April 30, 2014

Get Better Soon, dev diary #4: conceptualizing input in virtual reality.


This is a development diary series for "Get Better Soon", an NEA-funded gay club VR simulator game I'm making for Different Games. You can check out previous dev diaries here.

Virtual reality is weird and terrible for a lot of reasons: "simulator sickness" is the frequent sensation of nausea that attacks many players, simply from trying to exist inside virtual reality. (There are lot of complex reasons why that happens.) There's something fascinating about that -- a reality where existence makes you want to throw-up. A lot of that bizarre beauty is going to get smoothed-over and destroyed as the technology improves, which is unfortunate.

One of the more upsetting developments in VR progress is the specific user flow and use-cases that the two biggest VR influencers (Valve and Oculus) are prescribing for VR games. They imagine every VR user is going to be seated in front of their computer, with a positional tracking camera on a desk in front of them. The idea is to seat the player so they always know which way is "forward" by their dead reckoning, which simplifies how head tracking will combine with controller or mouse input. That way, it matters less whether you're blindfolded with a screen strapped to your face.

I think this is kind of a conceptually lazy way of solving the "input" problem.

Tuesday, April 22, 2014

Some dogmas I perpetuate

  • When the player does a thing, there should be some possible reason why or situation when they would NOT do that thing. Unless you specifically want it to not matter because ____.
  • When the player does a sequence of things, there should be a reason why they did it in that sequence vs. a different sequence. Unless you specifically want it to not matter because ____.
  • Things should feel embodied / have "feel" and feedback to them, according to how important they are to understanding what's happening. Unless you specifically want players to not notice it sometimes because ____.
  • Your game should occasionally be a little boring, or occasionally be a little exciting. This is called pacing.
  • Make the smallest possible game you can make. You can always make it bigger later. Each prototype / iteration is a different game.
  • Don't implement most suggestions that people give you. Think more about why they made those suggestions. Also, don't be upset when a dev ignores your suggestion, you're not the one making their game.
  • Don't plan too far in advance. Your plan is going to change anyway.
  • When tuning, double a value or halve it or increase / decrease by magnitude of 10 or randomize it.
  • How you talk about your game affects what your game actually is.

Tuesday, April 8, 2014

"Get Better Soon" dev diary #3, skin and light iterations


This is a development diary series for "Get Better Soon", a commissioned game I'm making for Different Games 2014. If you want to see it and play it, then come hangout at Different Games next weekend in NYC!

Kris Hammes is finishing up the character. The 3D model geometry is basically "done" so now I'm just waiting for the last texture tweaks like chest hair. In the meantime, I've rigged the model with a standard "HumanIK" skeleton in Maya (so that I can easily re-target animations in Mecanim) and I've configured the shader so I can start figuring out how to implement these characters into the game.

Tuesday, April 1, 2014

Second time's the charm; procedural NPC dialogue in Nostrum


Last time I tried some type of "procedural narrative" thing, my hubris got the better of me -- naming the system after one of the most famous and influential writers of all-time was, perhaps, just a little arrogant.

Despite my attempt to scope it properly, that system suffered greatly from trying to do too much stuff... It was so much stuff that it was difficult for me to write anything with it. So with the procedurally generated NPCs in Nostrum, I'm developing a much simpler system which will hopefully work better, to solve a smaller problem...

The basis is still the same: Elan Ruskin's GDC 2012 presentation on AI-driven dynamic dialogue in Left 4 Dead 2.