nddrylliog

2 and 4 we've had on our mind (2 is already an improvement over the previous builds! still has work to do. I believe sane defaults would be enough though.)

And 3, I definitely want in. If only because I enjoy playing platformers with controllers so much. The only "problem" is that controllers are so wildly different from one another -chances are, most customer complaints we would have gotten would have been about that! It's definitely slated for an upcoming build.

As for 1, that's a non-trivial feature do to how levels work, but it's also definitely something we want as the game expands. As it stands now, with two separate worlds, it's not too hard to finish each in one go, yet saving would be nice, especially as more complex quests get added and potentially spawn multiple worlds.

As mentioned, Shift-Down will do. (Also, while holding an item, Shift will use if the item is usable, throw otherwise. Usable items can be put down with Shift-Down as well).

These controls are actually explained in the LD levels (door on the right in the very first screen of the game), which you're encouraged to play first!

Still early access, thanks for bearing with us.

itch.io does support Amazon Payments / Stripe but that's only available to US sellers, and we're based in France unfortunately :(

I'll take a look and see what our options are. Thanks for the kind words!

edit: Stripe does support France, but in closed beta — just signed up, we'll see when/if we get in the beta!

Point taken & suggestion applied. Thanks a lot for your support!

Ah well, I'm still working out my marketing skills - a field which I hate with a passion, but there's two of us and, well, someone has to do it.

Basically — environments to explore, set to an original soundtrack. That's really the selling point. The actual gameplay, so far, is mostly finding items, bringing them to characters, in exchange for other items, so that you can find your way to the exit!

Since the Christmas update, there are two separate worlds with different 'quests' - the latter being a snow/winter/Santa-themed world.

We definitely plan to add other gameplay mechanics, but we think the "charm" of the game is already there. We're happy with how Early Access is working, and totally understand if people don't like that niche and/or want to wait until there is more content / gameplay arcs.

To shed some light on the "non-linear" qualifier I used in the submission, allow me to refer you to the Ludum Dare Postmortem for Lestac: http://amos.me/blog/2013/lestac-the-making-of/ — which explains some of it.

As a side note, to anyone on HN who is interested in following the development of Lestac right from the devs' mouths, let me know, I can totally give out a few http://devsofa.cc keys for the Lestac channel.

Precisely!

Well, it's interesting that ooc returned to its roots, because when I first started working on it, it was for a small simulation game project at university.

I'll try to be as unbiased as can be, though.

Here are the reasons I liked writing it in ooc:

  - I find it hard to write bad ooc. The language is smart,
  but not too smart, so you can write code that's concise
  yet not too confusing.
 
  - Moving up from C, having a single tool manage the build
  of your whole project is really cool. I recently added
  cross-compilation support, so I produce the Windows, Mac,
  Linux 32-bit & 64-bit builds from the same machine.
  I have a simple Makefile for tasks like packaging so 
  releasing a new build is a 'make deploy' away!

  - Recent versions of rock have gotten relatively good at
  error checking (there's still plenty of room for 
  improvement), but it's often a lot more helpful than
  well, most compilers I've seen. (Clang isn't bad, but
  it's C, so it can only help you on a low-signal level).

  - Most of the libs I wanted to use (SDL2, SDL2_mixer,
  OpenGL 3.x) already had bindings, and for the others
  (stb_image, etc.), well, I wrote'em. It's usually a
  matter of neatly organizing C functions into an
  object-oriented-ish interface.

As for the downsides, well, there are things I know to work around, language features I know I'd better avoid, and the occasional compiler blips. But for a project of that scope, I got away with "using my toy language" relatively scot-free!

I still remember the very harsh comments when I first presented ooc to HN a few years back. Forunately I was in a high at that point so I didn't care. Had I listened to them, I would never have gotten where I am now. So: stay positive, everyone!

Hey folks! Even though HN is more hacker-oriented, I still thought I'd give it a shot.

Factoids:

  - It's the first commercial game fully made in ooc
  - It's sold only on itch.io (which recently made HN frontpage)
  - It was originally a Ludum Dare submission
  - We just released a Christmas update!
  - It's lame because the game is not about killing stuff!

From a user's point a view — itch.io is everything I need, and then more.

  - Upload your game & customize your game page in a few clicks, without artifical walls: check
  - Quickly generate download links for press/friends and monitor their download count: check
  - Manage sales / price / updates from the web interface: check (instead of having to e-mail people a-la Humble widget)
  - Check out analytics on page views / buys / etc. - check

I'm a happy camper so far :) With the revamped 'buyer profile' update that's coming, it'll be even better. Plus, leafo is always listening to his userbase!

What? There are plenty: http://itch.io/browse/platform-linux

Why is this submission dead? Any ideas?

It's merely a setup for a more creative problem which I didn't have time to include. Here's the actual problem: numans have different weights, which incurs a speed penalty on the transport vehicle - numans[i] has a penalty of 2^i - the goal is to write code to carry them all in the minimum possible time (15 units).

For a coder, the numan part is easy and boring and repetitive - then again, it fits with the universe. For a non-coder, it's their first or second encounter with a piece of code that's more than 4 lines long, with a detailed log so that they can go back and forth to see where they went wrong. They have several rules that they need to pay attention to (capacity, 1 passager minimum required, auto-unload, be very precise with station names) - which, again, seems trivial to you as a coder, but isn't to everyone.

There's already so many instructions for this problem, I wanted to add the time penalty part as a second problem, e.g. "your solution would work, but we can't afford to spend N time units on this transfer - (insert additional instructions here)". I'm sure you understand the need for a consistent difficulty curve.

See http://coffeescript.org/#loops for reference.

Exactly. And if you've been paying attention since the start of the game, instead of treating it like a codeacademy or similar programming challenge type, you've already picked up on a few clues that.. the government (and its minions, including EEM) don't really hold you in high esteem.

Yup, really - at this point it's not EEM talking anymore, it's me, the dev, a human being, who primarily engages with other human beings online for gamedev feedback via Twitter. It's not an HN stunt :)

That's exactly the point of the game :) Thanks for explaining it.

Basically just running 'make' will produce all the needed files in output/. Then you can use 'python -m SimpleHTTPServer' from the output server, and open http://localhost:8000/ in your favorite browser.

For make to run correctly you'll need the haml, sass, and juicer gems installed and in your path.

Well, that's true. I've tried to make the game appeal to both non-coders and coders: non-coders seem faster at solving the riddles but on the other hand spend a lot more time on the programming part - and in counterpart, have a much more significant sense of achievement when they complete the game.

It's kind of introductory material, it sets a ground level for Chapter 2 - if you can't be bothered to sit (or run) through Chapter 1 you probably won't find the next one interesting.

I try not to blame players - although it might not show I've already done quite a bit of user testing (esp. with non-coders to make sure it's relatively easy to follow.

In this case, the 'numans' part was the last one I added, in a hurry, and only had 2-3 iterations on this part of the dialog/instructions.

Which goes to show: testing matters, iterations makes things better.

Thanks for the feedback!

Thanks for the feedback!

Many people have complained about @door vs @left/@right - the reason for that obviously was poor decision-making during crunch time.

Making the game accessible to non-coders (it is - they just take more time - but are usually better at riddles) was hard, and caused some hard decisions to be made.

I'll try to make Episode 2 more polished. All this feedback is very valuable, though.

As someone once said: "If you're not ashamed of it, you haven't released it soon enough".

You're playing Episode 2 from within Episode 1. What are you doing playing the game you should fork it already.

You answered your own question :)

Lots of people cheated their way through without admitting to it. But the government sees everything...

See https://news.ycombinator.com/item?id=5795893

Little know fact: there are 'save codes' - you can load the codes using hashtags, e.g. http://thechoice.amos.me/#firstdoor will bring you right to the programming part.

Didn't take the time to update the hash to reflect that though - some people would've noticed the URL has changed, others wouldn't have, and I would have needed to find an interface artifact to make sure most people get it.

TL;DR design is fucking hard but if you dig most dev-friendly features are in.

As for backspace doing back, blame your favorite browser maker. And change the defaults. And report an issue. That behavior (previous on back) was always idiotic, imho.

Sure, that was example code - do you really expect the game to give you the solution by itself? :)

Nope, but I'll take this as a compliment.

There are a few references here and there (jabberwocky being perhaps the most obvious one), but otherwise, mostly original.

See cheating is part of the game - in Chapter 1 it's a bit weak really, but in Chapter 2 it's part of the game.

Surely humans do fight back at one point. Don't they?

I'm on it.

Well played sir/madam/robot.

If you have a ton of embedded if/else statements you're doing it wrong. Only one if/else is required.

Thanks for giving me a course about game design and asking questions obviously not answered in Chapter 1. Where can I send you money? <3.

Marry me! I mean, join the team!

But seriously, Chapter 2 is all about deconstructing the game.

It's easy at first.. but then it gets harder. Erasing your traces... reverse-engineering protocols.. introducing you to netsec against your will.

Consider Chapter 1 an appetizer.