Okay, I went overboard with the title. Let’s move on.
When you’re making a game (or, I imagine, embarking on any creative endeavor), you find yourself navigating possibility space. Your game could feature dolphins or sharks. It could be played from a top down perspective, or via a text parser. Each of these decisions affects the game and helps locate it in possibility space, so each time you make or change a decision the game moves. If you’re doing this with any intention (such as to make something awesome) then I think it’s fair to say that you’re navigating. Ahoy, land ho, etcetera.
With many constraints and clear goals this becomes an excercise in problem solving, and can be quite fun. If you’re simply cloning an existing game then you just need to accurately map your destination and set sail. Without any constraints or goals you could conceivably create anything, but you’re far more likely create nothing, having no idea where to start on a giant blank canvas. Here be dragons.
I follow a different approach, which I call selfish design. I create games tailored to my tastes, specifically so that I can play them. This keeps me clear of the paralyzing dragons of possibility, and helps me stay motivated. Also I get to play cool games that I like. Obviously I’m also keen on distributing and sometimes selling these games, but I find if I keep to the selfish design principle the other motivations can also be satisfied. Sometimes.
Right now I have a problem. If you follow this blog you’ll know that much of Captain Jameson is played via Command Line Interface, and that I’ve recently been testing the game with real, live, squishy humans. The strongest indicator I’ve found for whether a player is able to engage with the CLI and enjoy the game is this:
Is that player me?
This is where selfish design falls apart. I built the game systems, I understand how the ship computer terminal operates, and I know what few commands it can process at any time. Everyone else see a blinking cursor. Even when prompted to type a specific command, players know there are almost limitless things they could type, and any of these things might work. They face infinite, paralyzing possibility.
Though I love the CLI, I think I’d be happier making a game other people could play and enjoy. With this in mind I’m experimenting with a new system, based on the Multifunction Electronic Display Subsystem (MEDS) currently installed in NASA shuttles. You can see a little old man fiddling with one in the picture here. I’ll keep the ASCII stylings of the CLI, but instead of typing arcane half-remembered context sensitive commands I’ll have the player pick from a series of options at the bottom of the display by hitting number keys on their keyboards. Hopefully these six buttons will present finite, liberating possibility.
<3 Farbs
**********************************
Welcome to your shipboard computer
Please type “help” to see a list
of valid commands
*********************************
>hepl
“hepl” is not a recognized command
or program, use the help command
to see a list of valid commands.
>help
The valid commands for your
shipboard computer are:
help – view the help document
ls – list directories
cd – change directory
tel – use telnet
cat – concatenate a file
(etc)
use “help [COMMAND]” to
learn more about a command.
I definitely won’t make it, but I still cannot wait for the day where piloting space is so nonchalant that you can dress up like it’s Casual Friday.
Hmmm. The CLI always seemed like an awesome addition to the game, but if the testers did not seem to get it, it would have to be tweaked. Shame though. Could you make it possible to toggle between CLI and MEDS?
@brandonnn In the next photograph, we pan left to show the interior of a comfortable interstellar RV.
@William Yeah, I know. I tried that.
@Vaconcovat I think supporting two interfaces would take a lot more time than it’s worth, unfortunately. I have a special dream however of building a version of Forever played only via text commands. I suspect I’ll have time for this the same day Brandonnn dons a pair of old jeans and a short sleeved shirt to go visit Mercury.
I love the infinite possibilities that the command line enables. As long as you have things like manpages and tab-completion, it should be great! Even better would be if you could have user-defined scripts that link up multiple commands!
this sounds good, might open the game up to more players, the chunkiness of it sounded like fun but this might improve gameplay a lot.
If there are only a few valid commands at any time, it would make sense to display these commands to the player. In a command line interface you would either click a corresponding number, type them out or just click them with your mouse.
I like text parsers and puzzles, but I fear I would not play the game as much if I’m always a bit confused. A non-confusing text parser would be good.
On the other hand, if this new system is visually pleasing, and has a a connection to actual space travel history, that could be even cooler!
@Farbs: On time restraints: Possibly a case to include lua, letting people make mods? (much like ticky-tacky)
We ran into the “infinite possibilities” problem with Clockwords – many players felt like the possible word space was too large to attempt a “best” word. We do put time pressure on this situation, forcing more of a “stream of consciousness” gameplay, but some players are frustrated with this, thinking that they always could have done a better word.
I’m really torn about this, because I was honestly looking forward to learning the ins and outs of the command line interface.
However, there’s no denying that a more graphical interface that displays exactly what the player can do at any given moment in time would make the game much more accessible and ultimately fun for a lot of people. And ultimately that’s what matters most from a design perspective.
Concerning the idea for a text based CF game: I really hope you do experiment with different types of gameplay like this moving forward- staying locked into the same basic style could easily grow old with time. And plus there is a lot of potential for a text based CF adventure- you could tell specific stories within the CF universe that help flesh it out a little bit and teach us about aspects of it that we don’t see in the main games. Plus I think it could potentially be pretty cool if you released bits and pieces of that game over time. It could give people something to do in between the bigger games in the series and eventually you could end up with a pretty meaty adventure.
I understand the pain of wanting a certain system in the game, and having to take it out for something more readily understood… and the hope that the more accessible option will still somehow capture what you loved about the original… and who knows, this new system might actually be better in every way to the CLI one you started with.
The trouble is Farbs, for those who follow your blog and twitter (which by the way, you need to update more often – thanks), we already knew about the CLI, and any change like this (that will undoubtedly delay the games release) will disappoint us.
So, how about I present another element to your process… one that you are not currently considering in your testing.
Your testers aren’t paying to play your game.
If you follow your current pay model, no one will be able to play Jameson without first paying to play all of your games. This means that only the invested and interested will be playing it… and that investment is significant.
Help, Tutorials, and better methods of discovery are all great tools at the fingers of those who are invested, but for someone who is just trying your game in a fairly quick play session (say an IGF judge) they fail to support complex systems.
It’s like sitting someone who has never played an RTS in front of one, and saying go! You can put great learning tools at their finger tips, but if they aren’t already invested, they won’t stay interested long enough to understand.
So, may I suggest that instead of loosing the CLI so quickly (not to say that it shouldn’t change) you first explore ways of getting the player invested in the experience more gradually through the play session before presenting them with the complexity of that particular system?
Cheers!
Just a thought, but perhaps work the two concepts together?
When the game starts, have Jameson set the basic commands to hotkeys or whatever on screen, then turn a ‘display quickloads’ setting on or something. Then the player takes over, and they have available commands listed by number key as before, or they can type them out, or they can turn off the display of available options altogether. A robust system that sets itself up simply to start.
If I were to go about this I would force them to be mapped to F1-F12 function keys like the old electronic card catalogs were…
I think that would give it the right archaic feel with out confusing the players with too many choices.
THIS is a GOOD IDEA.
Six choices per screen allows a lot of branching. But it’ll be confusing if options aren’t sorted right. What kind of commands would there be?
But considering that you did a game with exactly one button, I think there won’t be any problems here.
AWESOME!
@mackat Function keys are a great idea. Thanks!
@Pen Cheers :) Most of the time F1 will handle cancel/exit/back type functions, and I expect the majority of screens to have no more than three other options. You can find F1-F4 quite easily by feel, which should be nice. I’ll spill into F5 and F6 occasionally, probably just for when you need to scroll through lists.
There is another style of interface that I had dealt with that used telnet style terminals.
It had several dozen commands and they were usually abbreviated to just four letters and there were several other typed fields that could be filled in with records ID’s and options depending on the command inquiry or modification .
The cool thing they did with the interface was that in the rendered lists or panels of information that returned from the mainframe the list items had input boxes for single or double character abbreviations in certain context to create a query with out going back to the main screen and re-typing every thing. In those contexts a strip of characters explaining the common codes was displayed at the bottom of the screen.
However I don’t think it would be useful in this case as the data trees would never get *that* complicated in game and only a few people would actually get the reference. But for those who may be familiar the application was an Aerospace Materials and Resource Planning system and I am fairly certain it was written in COBOL.
Hey, I used an interface just like that at my old job. It was pretty cool, but maybe a little too archaic for the average player.
It is not possible to be too archaic.
Umm, I’m pretty sure there does exist a point beyond which the average person will get frustrated and give up if a system is too convoluted or unfamiliar. Especially in a day and age where people are used to working with fairly intuitive interfaces that don’t require them to remember text commands, how to enter queries, look up and fill specific forms, ect.
I personally do love things with a retro feel (I also love new things every bit as much), but most people just want something that is easily understood and is likewise easy to interface with.
I think I’ll be able to invoke the old mainframe-function-key feel without exploding too many brains. That’s my current goal.
Oh, I’ve got faith in you.
It sounds like you’re going for an interface that’s pretty straightforward and easy to understand.
…Though as I said before, the CLI will definitely be missed, at least by myself and some of the people here.
I am interfacing now
Welcome to your shipboard computer
Please type “help” to see a list
of valid commands
*********************************
>hepl
“hepl” is not a recognized command
or program, use the help command
to see a list of valid commands.
>hlp
“hlp” is not a recognized command
or program, use the help command
to see a list of valid commands.
>help
The valid commands for your
shipboard computer are:
help – view the help document
ls – list directories
cd – change directory
tel – use telnet
cat – concatenate a file
opn – open mailbox
use “help [COMMAND]” to
learn more about a command.
>opn
You open the mailbox. You see a leaflet.
>read leaflet
“WELCOME TO CAPTAIN JAMESON!
CAPTAIN JAMESON is a game of adventure, danger, and low cunning. In it you will explore some of the most amazing territory ever seen by mortals. No computer should be without one!”
One Key Per Command.
At least for basic piloting, fighting, navigating.
You want a text entry system for some of the story-telling aspects? Sure. But piloting should become intuitive, not a semantic-construct operation. (Like typing a sentence.)
Muscle-memory for the controls is important. You can use every key on the board, but:
One Key Per Command.
Otherwise, you’re not making a game, you making an operating system.
Also, we want more screenshots. ;)
♫All we want to do is eat your brains…♫
I completely understand the trouble with assesing the usability of your own interface.
You already know it inside out.
May I suggest looking for another game/program with similar controls, to get an idea of what a new player would feel like using yours.
I would suggest Dwarf-Fortress as an extreme example of using context sensitive hotkeys.
I’m sure Jameson won’t be that complex though.
Heh. If anyone compares the final game’s interface to DF then I’ve made a huge mistake :)
ah… excuse my newbie-ness but WTF is ‘DF’… i googled it and it didn’t help =P
@Chris K:
I LOVE THAT SONG
oh! and Farbs, try to keep some of the command writing… it will be a horrible system to use straight away for people out of the know, but it is also something to set your game apart from every other game floating around out there.
love from your number ‘1’ CF noob
DF is Dwarf Fortress
And its controls are fearsome. The controls are the only reason I’m not playing that game right now.
Is it possible to try it out online?
Tx :)
Keep up the good work! :D
Farbs: You say you will use the F-keys… Remember that a not insubstantial part of the fanbase are “Maccies” where you will have to press down a function-key to be able to use F-keys :)
maybe we should add some right click functionality too as that is way old school for “maccies”
If only you could right click in flash games…
And in all fairness, current Mac mouses have some kind of weird multitouch right-click equivalent…
Though it seems to me that the Mac design of packing all the functionality of a normal mouse into a single button mouse is more cumbersome than anything.
Arg! Stupid Apple. Standards exist for a reason.
Perhaps you could A) Make a second version of the game with the keys remapped for mac users (the website could ask you what your platform is before your first play and automatically bring you to the right game every time after that) B) Include an option in the game to change control schemes to accommodate Mac keyboards C) Forget the function keys entirely ( sad face )
@chris
or programatically take care of that…
http://www.java2s.com/Code/Flash-Flex-ActionScript/Development/DetectingtheOperatingSystemUsetheflashsystemCapabilitiesosproperty.htm
and add the annoying text scramble from imposter set to eleven to troll users of a certain OS…
and then have some thing like “user terminal corrupted” remapping input device message appear as it corrects..
Here’s what I would like:
Map all major functions to individual keys.
Hitting the “?” key pauses the game and floats a window with a virtual keyboard on top.
Mousing over or pressing a key gives you a tool-tip of the key function.
Pressing “?” again resumes play.
Oh, I didn’t know Flash could detect your OS. I guess that simplifies things a great deal.
@Cullpepper:
love that idea but is it realy necisary if all the is being used is the ‘F’ keys? and as for macs, you could always just use the top line of lettters after and right from the ‘W’ key
I’ll try just using function keys, but allowing people to alternatively press number or numpad keys.I imagine a lot of people will end up using number keys instead of function keys, which is a little sad, but better than ~5% of players not understanding how to play the game at all.
True that
Anyway, aside from the interface, are there any other major things that still need to be fiinished up before launch?
I mean, I know you’re going to get this out as soon as it’s ready and that it’s going to be ready as soon as you can get it there- I’m not worried about that. I’m just curious to know what might be going into the game in the last few weeks (months?) of development
I have a couple of things left to do, yeah. Off the top of my head I need to:
* Finish rewriting the interface code and adjust all the stations and programs to use it
* Save and load games from “the cloud” (really just my server)
* Write the game launcher (php and javascript fun)
* Rewrite ingame dialogue
* Build the endgame
* Direct the player towards the endgame
* Possibly make repair and upgrade stations a little more identifiable (not critical)
* Muck around with some ideas for homing missiles (maybe)
* Rewrite the death sequence (since the new ships don’t detonate)
* New background face(s)
* General polish
* Update the website
I’m sure there’s more!
Wow, no wonder it’s taking so long
Well, keep up the good work. I’m sure the game will be better for it in the end. And soon enough I’ll find myself thoroughly distracted by Portal 2. So maybe I’ll leave you alone for a while :P
fucking hell Farbs… your a fucking machine =P im swear, im having fun just going ” wooooow…. 0.0″ at the shear awesomeness of captain forever and the work your putting in
I’m hoping the endgame is where the pilot meets the vessel alpha-omega, which FILLS THE ENTIRE FIELD WITH A SOLID CONSTRUCTION OF SHIP PARTS!
The challenge is then to blast a path to the middle to shut down the mother brain. (Or heart, I suppose.)
Reminds me of Yar’s Revenge, kinda.
But anyway, somehow I doubt Farbs would design anything that would cause massive lag into the game.
Sorry for sending you a suggestion in email form Cap’n.
Had no idea you were more focused on utilizing your own ideas.
Jeez I need to learn how to not bother people.