next »

[a-k-]

.

[a-k-]

Since the levels progression is non-linear, several levels may unlock whenever a player solves (or cheats in) a level for the first time. If there are multiple options, the game selects the next level that is best in terms of advancing the game and continuing with the path selected by the player (even if different than the default).



Scoring is also finally implemented along the lines I've already described, and the next step is providing feedback for "optimizers" that work on improving their solutions. I'm thinking about displaying a table with all the solutions (past and present) that clearly shows which solution is superior to which, or something like that.

[a-k-]

This feature has been developed for some time and has finally come to a point of bringing real value to the player. Hopefully you'll be able to get the idea despite me using obfuscated commands.

Recall that the player can run their program one input at a time, and that as they edit their program on the grid...



...the corresponding C++ code is generated on-the-fly:



With instant feedback, the program is analyzed in the background and insights regarding specific commands are displayed with comments. The player can change the level of detail with a slider, with higher levels having the potential to expand the layout of the code - some sequences of commands can be "fused" into one line (it's C++ after all...), but if any command needs a comment, that command will reside on a separate line.

What can the feedback be used for? Shaving off cycles from solutions, anticipating errors that will occur on the other inputs, and more.

[a-k-]

The Level Complete screen has finally been upgraded to a graphical one. An example of the basic metrics (there are more):



The player can toggle between reviewing the stats of all their solutions, the best ones or only the last. A simple tournament is run to determine the best solutions (shown in white) and their key metrics is highlighted in yellow.

This still needs more work - the graphs may look messy with many solutions or not show the differences clearly enough, and I need to think about sorting the solutions (it conflicts with keeping the palette colors in order).

As part of implementing this, I changed the metrics along which solutions are measured in order to make them easier to visualize. That came just in time for me as I was going to begin the save system for user solutions. The invalidation of all the previous statistics, and the realization that it would happen again, was a key factor in the design of the save system. This can be a topic for a future post.

[a-k-]

Things that I want to do without breaking user saves (or developer saves, for the matter):
1. Add or delete a level, or change the relation between levels
2. Change an existing level
3. Add new execution statistics and scoring metrics that affect all levels

(1) is trivial, so I'll focus on changes such as (2) and (3).

The challenge is, any change to the game may invalidate a previous solution of the user. Moreover, even if the solution is still valid, its saved information (e.g. statistics) may become out of date. So I would like to save as little as possible and compute all the rest at runtime.

The basic idea is that all relevant functionality of the game depends exclusively on the set of user solutions, i.e. set of pairs {(level, program)}. So if I could re-execute and re-validate all saved user solutions (including historic ones) every time the game runs, I could achieve (2) and (3) for free. This, however, is not feasible due to the time it takes to execute the full solutions history.

I came up with the approach of saving for each user solution:

• Minimal, version-independent info: (level, program)
• Extended, version-specific info: metrics, statistics etc., plus special version numbers (see diagram). This info is not guaranteed to be readable by future (or old) versions of the game.

In the beginning of the game, if the extended info is not readable or the numbers do not match for some solution, a verification screen appears. All non-matching solutions are verified and up-to-date extended info is saved to the DB, including all statistics and metrics required by the new version of the game. This way, all user saves are upgraded automatically, without requiring any custom code to handle all sorts of backward/forward-compatibility issues.

I've also provided the player with the option to pause the verification process and proceed with the game, but then some levels may not be accessible and they will need to re-run those programs manually. In practice, they will wait, just like me...

[a-k-]

Have just taken the first step towards having online leaderboards.

I'd like the leaderboards to be completely reliable, so all user solutions need to be verified and scored by the server while taking into account that:

• Verification may take a while - the server will be running an arbitrary user program against 100+ inputs, and that program may be poorly-optimized
• Malicious clients may submit solutions that take extremely long time to complete or even run forever

This was not in the initial scope of the project, there's no server and everything currently runs standalone on the player's computer. So, where do we start?



The game is developed 100% in C++, but this doesn't imply that the server needs to be built in C++. For the first building block, I have extracted the logic that a server would need (levels, execution, testing, metrics & scoring) and wrapped inside a standalone program with command-line interface. I already had full separation between the model and the view/controller aspects so this step was quite easy. Now that the game-specific functionality is available also as a standalone executable, I'm free to choose any technology stack and any programming/scripting language for the server side. Which means, lots of reading to do...

[a-k-]

Flow of submitting solutions for server-side verification:



For the server side:

• Python + SQLite DB - simple and reliable, should be enough for my needs
• CherryPy - multi-threaded Python Web server
• Protobuf - binary serialization C++ <--> Python
• A command-line C++ executable that encapsulates the game logic
• Some reverse proxy - not needed for start

The protocol for submitting solutions is simple, and the game client will periodically submit a solution to the server until a result for it is received. The game can also be played without Internet connection, albeit with limited feedback to the player.

Due to security considerations (some are explained in my previous post), the actual verification and the update of the leaderboards will be done by an offline script and not as part of client requests handling. For start, it will run periodically, but later I will run it concurrently, triggered by new solutions.

The main open issue for now is how I'm going to authenticate the user - this is more a question of user experience than technology.

[a-k-]

I finally came to check the feasibility of porting the game to HTML5. The game relies on SFML, a C++ graphics library that uses the legacy immediate-mode OpenGL and has no intention of targeting the Web. So equipped with a do-whatever-it-takes mindset, I was prepared to ditch it but decided to give a second chance nonetheless.

The beginning was promising: Emscripten comes with an OpenGL emulation layer and with a few changes to SFML, I got my triangles displayed in the browser. Well, except the textured ones, which were completely ignored. It is well known that the less text the better, but I really needed those glyphs.

I tried a thing or two, but all the shaders the emulation layer generated did not support textures. So I ended up creating my own rendering code and modifying SFML to use it. (Lesson learned: if a library outputs "WARNING: [...] This is a collection of limited workarounds, do not expect it to work" to the console, believe it.)

All this is quite hacky: I still use only one library on the desktop (SFML), but the Web build is a strange mix (SFML and SDL2, legacy OpenGL and WebGL). It does work well in practice, and the credit really goes to the wonderful Emscripten project.

What is left to be done for a complete Web version?

• Anti-aliasing is not always available in browsers, so I may need to use textures or gradients instead.
• Testing on more browsers (e.g. I had to work around a bug in IE11 support for WebGL viewports)
• Modifying the keyboard shortcuts (e.g. no function keys or Esc)
• Supporting user saves
• Communication with the server

[a-k-]

I've made some progress on the HTML5 front:

• Anti-aliasing of lines using textures (in addition to MSAA where available)
• Communication with server using XmlHttpRequest (instead of libcurl)
• User saves - for now I'm using IndexedDB, no online saves
• Adjusted hot keys (e.g. |1|..|0| instead of |F1|..|F10|)

These close the majority of gaps compared with the PC version, even though the latter is still considerably more user-friendly than the browser one.

[a-k-]

I figured I'd show some numbers:



In all cases, the downloads include everything that's needed (no DLLs / shared objects / JS packages in CDNs). JS and WASM assume gzip compression by the server. Additionally WASM includes the JS polyfill (0.8-->0.13 GB after gzip), with the disclaimer that I haven't integrated it yet.

The surprising thing is, even though the JS code is much larger than compiled code, in the end after compression, the download size is not far behind.

[RangePlusOne]

Just going by the screenshots, I can't even comprehend - that's some digital wizardy going on there. But I can't look away.... 

[a-k-]

Just going by the screenshots, I can't even comprehend - that's some digital wizardy going on there. But I can't look away.... 

Thanks! The real wizardry takes place in the player's mind, hopefully everything will become clearer soon (that is, once I finish about 50% of the 20% that take 80% of the 400%...)

[a-k-]

The time had come to add sounds to the game.

Emscripten automatically converts OpenAL and SDL_Audio to Web Audio calls, so supporting browsers in addition to PC should have been trivial. However, due to my desire to be able to run on IE 11, I couldn't make use of that. Instead, I came up with different paths for the two scenarios:



Specifically in the Web build, I use Howler.js, which defaults to Web Audio but falls back to HTML Audio on IE 11. This means that:

• Since IE 11 doesn't support WAV files, each sound effect is stored as both WAV and MP3. The first ~50 msec of MP3 files are skipped to eliminate conversion/decoding silence gaps.
• Just like fonts, all sound assets are embedded in a compressed form inside the executable, so I pass them to Howler.js by Data URIs. Those aren't treated very efficiently, resulting in x3.66 memory consumption per sound. Depending on the final numbers, I may want to patch the library or perhaps host the sounds separately in the server, unlike the PC build.
• Can use only features that are available in HTML Audio (e.g. no pitch altering)

Right now I have a few sounds attached to the basic UI actions. Will need to add sounds to other events as well.

[a-k-]

A small change with high impact: the stars system has been replaced with numerical scores, giving more nuanced feedback to the player:



For the cost component, I had experimented with different formulae till I arrived at the present one. Basically, I looked for something that reflected the elegance level of simple solutions (like the # of commands) while still discouraging the player from using too many conditions:





This may not be my last word in this area, but at least I'm getting closer...

[a-k-]

This has baffled me for some time. The first 20 levels are optimized for gradual introduction and discovery of basic mechanics and techniques. Ideally, each mechanic would be used for the first time in a specific level, but arranging everything non-linearly means that a mechanic may be "new" in multiple levels, depending on how the player advances in the game:



Occasionally, I would look at the levels map and consider one tweak or another, but any change would do more harm than good. Then it occurred to me: don't change anything, just present the mechanic exclusively on the first relevant level that the player happens to play, and do it consistently.

So if there are two levels where a mechanic can be introduced, the one that is played first will be remembered. But this info is not saved to disk - when the game is restarted, that same mechanic may be presented by the other level instead. A sensible middle ground, at last...

[a-k-]

A first attempt at animating the Level Complete screen:



Commands are visited in an order that somewhat mimics the execution flow (it's tricky, there are many inputs). Numbers reflect the differences between the accumulated metrics with/without the command. Still need to introduce a transition just before showing the score and fix several glitches.

The funny thing is that the most difficult part was deciding on a suitable location for the program since it can have various sizes and so are the other panes. As well as the screen itself. In the end I just run through all the layouts I had in mind and select one at runtime based on some heuristics. One less thing to ponder...

[walaber]

Hope I'm not intruding here, but wanted to mention that this game looks really interesting.  I'm quite fond of grid-based programming games, this reminds me of Carnage Heart and/or Marionette Handler, both of which I enjoyed quite a bit, and seem to share some DNA with your game, although from what I can tell the flow rules are a bit different.

[a-k-]

Hope I'm not intruding here, but wanted to mention that this game looks really interesting.  I'm quite fond of grid-based programming games, this reminds me of Carnage Heart and/or Marionette Handler, both of which I enjoyed quite a bit, and seem to share some DNA with your game, although from what I can tell the flow rules are a bit different.

You're more than welcome! It seems that in terms of visuals, the layout of my grid closely resembles CH (couldn't find anything about MH). I understand that it has some form of RNG, you may find that non-determinism plays an important role in this game too. I probably need to research the non-PC area a little as I was completely unaware of these two games (didn't know that programming games exist outside PC...)

[a-k-]

Have added support for breakpoints, which was on my list for a long time. It took me a few iterations to find UX that works well on a grid, for example, deciding what to do when commands are moved (I move existing breakpoints and then 'merge' them), and whether to allow breakpoints on empty cells (no).

Then I added a 'Run Back' button. It could previously be simulated by holding down 'Step Back', but once breakpoints were implemented, a dedicated button was needed.

With these two enhancements, I can finally compete with MS. Here's their time-travel debugger for an architecture having ~1,000 instructions:

(WinDbg Preview version)

And here's one for a language with 6...

[a-k-]

Import/export of user saves is now supported in the Web version. Initially done only for development, it can also be used for upgrading to the PC version. The player can simply download their savefile without the need for user accounts, cloud saves or 3rd party clients. Uploading locally in the browser is also supported, but that's mostly for debugging.

If you're interested in the scenarios:



All this may be inconvenient for players accustomed to cloud saves, and error prone in case their local storage is automatically cleared by the browser. But then, they really need to play the PC version...