The Dawn Star – Build #3, Oxygen


The builds continue to continue! Despite last week’s kerfuffle I’ve doubly settled on the title The Dawn Star. This time for sure.

Here are the changes for this week’s build:

  • New exciting low-oxy start
  • Added Primary Thruster module
  • A new series of sectors to explore
  • Double the spawn rate of oxy tanks
  • Made guardian designs more variable
  • Made asteroids flicker at least a little on damage > 0
  • Added key binds for arrow keys
  • Oxy stations returning as atmosphere stations
  • SOS marker on some atmosphere stations, including the first
  • Removed guardians from ~half the settlements
  • No modules on new game start
  • Fixed some savegame issues w/ new modules
  • Added new custom font rendering system & test (Ctrl-T)

Here is where you go to play the game

<3
Farbs


The Future of Jameson

Vertex Nebula

[tboot_spacing size=”40px”]

Here’s the ultra short version of this post:

[tboot_well width=”50%”]

  • Weekly videos and builds!
  • Becoming less like the fourth sequel to an obscure niche browser experience, more like a videogame

[/tboot_well]

[tboot_spacing size=”40px”]

Here’s the long version:

I now have four days a week to work on Captain Jameson, unlike two and three years ago where I had one day, or the past year where I had none. Though this pause in development slowed things down a lot, it also gave me time to reflect on the game, and on the project as a whole. Looking back on it, I’m pretty sure that I need to work more to communicate about the game, and that the game needs to better communicate itself. I’ll break these down below:

Communicating About the Game

A weird quirk of working solo is that you have complete freedom about how to spend your time, which often means you have no idea how to spend your time. In a team with two programmers, two artists, a sound designer and a PR manager, every week you get two weeks of programming, two weeks of art, one week of sound and one week of PR. When you sit alone in a room for a week you could do between zero and one week of any of those things. Most often though you figure that the game needs to be playable and fun, so you just focus on that and let the rest slide. PR, sound design, and often even art, go out the window.

Instead of diving responsibilities by person – which doesn’t work when you have only one person – I’m going to divide them by day. Here’s how my average week should look:

[tboot_table strip=”yes” border=”yes” condense=”yes” hover=”yes” cols=”Day,Work” data=”Monday,Planning then playtesting,Tuesday,Development (code art sound as required),Wednesday,Development (code art sound as required),Thursday,PR,Friday,Parenting”][/tboot_table]

So, every Thursday I do “PR”. It’s an ugly word, and nobody wants to hear they’re being PRed to, but I think it best describes what I’m setting out to achieve. Basically, I’m setting out to be Wolfire. Every Thursday I plan to create a new build, video it, and upload the video and the build for you to watch and play. I’ll spend the rest of each Thursday writing blog posts and press kits and landing pages and generally pretending to be Rami.

The Game Communicating Itself

Captain Jameson is a big game, and it’s going to get bigger. Unfortunately, since Captain Forever is small, and since Captain Jameson looks like, has a name like, is described as being like, and is even sold in a package of games like Captain Forever, that message of bigness is completely lost. The point of Captain Jameson is to create a vast world of interesting, interplaying mechanisms, and to let the player navigate a course between them. The point isn’t to create the fourth in a series of little web games about neon vector space ships. Part of the problem lies in how I’ve been describing the game, but the larger issue is, frankly, the game itself. At first glance, that’s exactly how the game presents itself. Here’s how I plan to address this:

  • A New Name – This should create a clear distinction between this game and the earlier series.
  • New GFX – I’m looking to build a new GPU based renderer, aiming for a visual target like Gratuitous Space Battles in the style of Homeworld. This will help convey the idea that this is a new game, and a thing of value. It’ll also help create a vibe, which I’ll talk about later. Oh, and it’ll free up a lot of CPU time, especially when playing in fullscreen.
  • More Gameness – The original games all present themselves as interfaces to ships, rather than, y’know, games. This was fun, and it gave me direction when writing the website and designing various interactions and interfaces, but it was also a massive pain. I’d really like for this game to have a title screen, and music, and maybe even an options menu. I’d like to be able to use the word “game”. All of these things were off limits with the previous approach, and I think that was a mistake. Explaining things in the context of the gameworld is fun, and I expect to do a lot more of it, but limiting myself to that has become a problem.
  • Desktop Builds – I probably don’t need to explain this.

The other aspect of the game communicating itself lies in-game, in how the game teaches the player and guides them through the experience. Right now it doesn’t. Unless you wade through the in-game manuals – which most players never even find – you’re stuck just sort of bumping around in space, then you run low on oxygen which you didn’t know about, and then you die. That’s not fun. Oh, also the manuals are out of date. Right now I think the mid-game experience is great, and I and a lot of the hardcore supporters really enjoy it, but the majority of players never get there. It’s completely fine that the game is in this state – I built the mid-game first, and had always expected to have this problem. But now I need to fix it.

The only way I know to fix this is to Kleenex Test, which means to find a fresh new player who has never seen the game before, and watch them play the game. You take notes about every wrong button pushed, and every incorrect assumption. Then you update the game in one of two ways. You can update it to encourage the right button and the correct assumption – which can be very difficult – or you can update it so that the wrong button and the incorrect assumption are actually the right button and the correct assumption – which can be quite easy but might destroy your gameplay. Knowing which approach to follow, and how, can be tricky, but without Kleenex Testing it can be impossible to determine where the problems are in the first place! Since I work from home, alone, I don’t have a steady supply of Kleenex Testers walking past my desk, but I have a few ideas about where to find some, and will be pursuing those ideas in the coming weeks.

So, that’s where I’m at. I’m working on Captain Jameson again, except it probably won’t be called Captain Jameson. I plan to present it more like a regular game, and less like a Captain Forever web thing, and I plan to release weekly builds and videos. Will these plans succeed? I have no idea. No plan survives contact with the enemy, but you don’t want to start without one, and this here is mine. What do you think?

<3

Farbs