next »

[sublinimal]

(Not sure if I should have a combined devlog extravaganza for my One Game a Month entries, or separate threads for each, because some entries won't be developed exclusively for the event and probably won't get finished in one month. We'll worry about that later.)

To kick things off for January, I want to finish this prototype I've already started earlier. I'm aiming to honor programming as the creative artform it is by turning it (quite literally) into a game. Your primary mode of interaction is entering commands that the robot will carefully execute. The challenge lies in predicting game states and manipulating them to your will with elegant solutions.

[sublinimal]

I think it makes sense for the game to be presented through some kind of console. Like, you're a worker in a factory where warehouses are too risky for humans to manage, so they rely on people like you to move stuff around by commanding robots.

"Why is there an endless pit in the warehouse? I don't get paid enough for this."

Usually my games are pretty cryptic and avoid text in favor of visual cues, but this is the sort of game that profits from constant feedback, so I'll try to give lots of advice for the players.

Like I've said, the point is to let players experience the fun of programming. Checking for null pointers is not included in my idea of fun. The programming in this game will be about lateral thinking rather than bit-twiddling, with semantic mistakes rather than syntax errors. Things like moving a crate and being clever enough to write the robot's further moves based on the new position of the crate, not the old one.

I have a few levels planned out, so now I'm working on pinpointing what sort of in-game language gets the most out of my ideas. It needs to be flexible enough to allow for hacky solutions - and creativity could be further encouraged by high scores for things like the most compact solutions. One such solution could be moving right, then redefining the "right" function as another action at runtime, and reusing that. But as for control structures, functions (actually more like 'goto' labels) and branching logic ("move left until interrupted") are likely the most complex it's going to get.

I have a nagging thought that this should be a Flash game, but I'm not very confident in my ActionScript skills... well, I have a month to learn.

[kinifi]

This is great This would be really fun! for games like this I'd never want to leave my hand from the keyboard but thats just a preference.

[Lain]

This is an excellent concept and an interesting approach to gameplay. I dont think i've seen anything like this but my mind might fail me.

This is a game that would put your mind into work hardcore style, especially with cool puzzles.
I really hope this gets finished.

[sublinimal]

This is great This would be really fun! for games like this I'd never want to leave my hand from the keyboard but thats just a preference.

Yeah, I figure mouse controls wouldn't fit in. Just complicates things.

For the same reason, I'm considering not having menus at all. You'd either read text on the blue screen or write commands into it, and level progression would be linear.

Alternatively, there could be reserved commands like "/level n" in case you want to backtrack, or even a hub world with its own robot... but the point is that I want to keep things minimal interface-wise, so you could fully focus on the programming. Also, it keeps the fourth wall intact if the in-game console is all you have for interaction.

This is an excellent concept and an interesting approach to gameplay. I dont think i've seen anything like this but my mind might fail me.

I've seen the concept done in different forms, but they're usually more abstract. One recent example would be Extinct : Humankind fade in the mist from LD25, which isn't explicitly about programming, but is based on the same mode of thinking.

Anyway, I'm not out to imitate anyone, this is just a game I want to make.

[sublinimal]

I want the in-game language to be as expressive as possible with minimal rules, and I think I'm heading in the right direction with what I've got.

For a start, the syntax couldn't get much simpler: each command consists of one character. Hard-coded actions, like walking ('w') and carrying objects ('c'), are lowercase letters. The uppercase letters are reserved for user-made functions. Numbers loop over the next character; if you want to repeat multiple commands, pack them into a function. There will also be a few special characters.

The philosophy also includes that you should never have to worry about syntax errors: if you have something like a number as the last character, it's just treated as looping over a NOP.

The robot executes whatever is contained in the 'M' (or main) function, reading it character by character from left to right. A function consists of one line, where the first character is its name, the rest its body. For example, Mwwww defines a program that moves the robot 4 tiles to the direction it's facing. This is of course equivalent to M4w.

A new function is defined when an uppercase letter is invoked: in the program MT, the main function calls an empty function T, and therefore does nothing (but takes one turn for that). If we move to the letter 'T' with arrow keys and press Enter, we enter its sub-program that only shows T on the blue screen. If we expand it to T4w and return to the main function, the program MT is again equivalent to the previous example, because T is now synonymous with 4w.

Well, not quite synonymous. This is where things start getting interesting. If one command fails in a non-main function, the entire function fails and control returns to the previous function in the call stack. I could have a function S, defined as S-w, where the '-' symbol means an infinite loop. In the main function, -w would indeed keep on walking until the program is aborted, but inside 'S', we'll have to take into account that the command 'w' can fail if the robot bumps into something. If there's also a function 'R' that calls 'S' and has another command after it, the implication is that we can use branching logic without 'if' statements!

Let me show you by examining a program with three functions: M-R RSf S-w  

• Execution begins from 'M'.
• 'M' goes to an infinite loop, calls 'R'.
• 'R' calls 'S'.
• The robot keeps on walking until it hits a wall.
• Control returns from 'S' to 'R'.
• The 'f' command flips the robot around.
• We've reached the end of 'R', and control returns to 'M'.
• ...But since we're in an infinite loop, we bounce back to 'R' again.
• ...And to 'S' again. But thanks to the flip command, the robot is now walking in the opposite direction.
• Repeat from step 4.

Basically, it can be used to elegantly solve a level like this:



I know this post is terribly confusing, but obviously the game won't be such an infodump. The levels will go through the concepts gradually.

[Quarry]

This is extremely cool

[happymonster]

Reminds me of a very old game for the BBC Micro were in one part you had to guide a car to a destination around routes with these kind of commands and distances.

[sublinimal]

Reminds me of a very old game for the BBC Micro were in one part you had to guide a car to a destination around routes with these kind of commands and distances.

Sounds like it's based on turtle graphics, usually associated with LOGO. That's partly what inspired Control Room, but this game isn't just about movement. I'm more interested in puzzles that explore overlaps between game states.

[Zaxuhe]

this game looks awesome !

[Sergi]

Sounds great!

It reminds me of this flash game I played years ago, you also had a set of instructions, like turn left, right, jump, walk forward, that you gave a robot to reach the end, and I think also collect some coins or whatever. You could also define functions because you had limited instruction space. It was really cool if you already were familiar with programming concepts, recursion, etc. I wonder if anyone knows the game I'm talking about.

[SolarLune]

Yeah, this looks cool. I like the simple graphics and the cool colors you've got going on for the GUI. They seem to compliment each other pretty well.

[sublinimal]

Alright, so I guess I'm going with FlashPunk after all. The prototype in the OP was Pygame, and I would've had to rewrite it anyway.

I have the fundamentals working to the point where one can enter some basic instructions and execute them. There's a Parser object that holds Func objects, each containing an user-modified string of commands. Once you decide to execute the code and the Parser encounters an uppercase letter, the corresponding Func gets pushed to a stack. The functions you've written won't get reset after execution, but the robot does.

Loops are implemented as LoopFunc objects that inherit from Funcs, with the difference that they're created on the fly by the Parser, and won't be removed from the stack before their counter runs out. Not sure if this was the best way to do this, but it works well enough. (Except for nested loops, which will require some kind of scoping, or a recursive solution.)

Here's a silly proof-of-concept program in action, walking the robot three steps to the right and back.



Not too interesting yet since all output is text, but I'll get it to the point where you can play around with it as soon as possible.

[sublinimal]

Not sure if this was the best way to do this, but it works well enough. (Except for nested loops, which will require some kind of scoping, or a recursive solution.)

Scrap that, nested loops were a non-brainer. Instead of looking at the next command in loops, I just needed to search for the next non-number command. Didn't think it would be as easy as copying a longer string, but I guess it's a sign that my parser is well-organized.

[sublinimal]

First playable build! AKA "holy shit it works". There's just that one level and no goal, just mess around, maybe see if you can build something cool with the crates, etc.

-Lowercase functions: c: carry a box next to you, d: drop the box, w: walk forward, f: flip around, j: jump forward.
-When your cursor is pointing at an uppercase function, press the up arrow to enter/edit it, and down arrow to return to the previous function. Each function can hold 8 commands.
-Enter to execute your program, and Esc to abort.

User-friendliness needs more work for sure, but what's there is functional, and that's important right now. It contains the central features from my post above, and more.

This program's a pretty comprehensive "demo", try playing around with it: MTR3Y Tfwjw Rcfwwfdc Yf9w

With that, I'm optimistically bumping this devlog to 20%.

[DustyDrake]

Augh, why can't you navigate the commands by using left and right arrows?

[sublinimal]

Alright, you can now.

[sublinimal]

Reflecting on the first build after a good night's sleep.

-The timings are weird. In particular, function call/return should probably be instantaneous. It was originally that way, but I think the reason I changed it was some side-effects with the display. Right now, the time it takes for the robot to execute a function (or loop) feels unexpected, leading to trial-and-error gameplay. Even though puzzles won't be as much about timing/counting steps as those "turtle graphics" games, it still bothers me, because it's like you're being punished for using more functions. Besides, you can already add extra pauses by making a NOP function like "Q3". (It even shows a countdown!)

-There should be an easy way to share programs. Just a save feature that copies a string to the clipboard, and a corresponding load feature that allows people to paste a string to their console, automagically turning it into an executable program. Programs are compact and more or less self-explanatory to read, so I'm hoping I can encourage players to collaborate and compete when solving levels.

-I hate UI and graphics programming so much. Copy-pasting code with minor tweaks, without the use of logic or creativity, is truly the lowest form of programming. At least the in-game language steers clear of it.

-Now it's really a matter of designing content: levels and their briefings, more lowercase functions, more language hacks, and clarifications for existing ones (like what does it mean for a function to fail).

I guess levels would consist mostly of moving items to their correct places before heading to the exit. To make things more interesting, there could be different machines to interact with: extending bridges, conveyor belts that can be reversed with switches, and also some kind of crane. Maybe the crane picks up solid tiles on command and allows the robot to ride them like an elevator. Or something.

As for the language, I still want to include some sort of registers that the player could modify, read and use indirectly through functions.

[sublinimal]

So like I've said, I want the challenge to be about inventing algorithms, rather than doing automatable tasks by hand. For this, I figured there needs to be some element of uncertainty to encourage generalized solutions and discourage "brute force" ones.

For example, since the location of the robot is one typical thing to consider, there could be teleporters that connect to each other randomly. The players would need to understand branching logic like "if the robot's at point A and there's nothing left to do there, enter the teleport again until it's at point C", and try to implement that with the building blocks they have. Basically, once the players have gotten a hang of it, it becomes more a matter of using branching logic than just counting tiles and walking that many times.

One nice example of the clever solutions I'm aiming for: a warehouse with a pit that you have to fill with crates to cross. The robot's position has multiple possibilities after it's retrieved a crate, and it can't predict ledges when it does return near the pit; it can only sense when it's falling, and by then it's too late to do anything about it. The intended solution involves always leaving a crate on the edge of the pit (instead of throwing everything in mindlessly), because the robot can sense it's pushing a crate, and you can use that data to do conditionals.

The gameplay will be pretty autistic, so it could use some comic relief for balance. That's why you're being bossed around by a neurotic, incompetent executive who has bursts of megalomania and total incoherence. The monologues I've sketched out have a kind of "Portal meets Monty Python" vibe, and I like that.

I guess I'm approaching the so-called middle-age crisis of a game project. The point where I start doubting whether anything about the game is actually all that fun, and whether it will eventually devolve into one big mess of bugs. It usually results in looking back at what I want to achieve and re-evaluating the mechanics, accompanied by minor breakdowns.

Frankly, I feel like most people are going to hate the end result no matter how satisfied I am with it, as usual with my games. Innovation is alienation.

[sublinimal]

I'll be introducing devices such as 4-way moving platforms that the robot can pass functions on to. And they can pass code on to other devices with modifications, like some Olympic torch of burning autism, possibly even communicating somehow. That's going to open up whole new horizons, as your thinking won't be limited to one entity.

The more I do, the more I feel like this when trying to estimate the progress. Whatever is there works and could pass as a game as it is. Most of what's ahead should be plain design, but surely I haven't seen the worst bugs yet. Since the month's halfway through, I hope 40% won't be much of an exaggeration.

Posting a more refined build in the following days.