A small RPG company

Name: Marvellous Inc.
Version: dev
Author: Renato Lui Geh, Ricardo Lira da Fonseca and Yan Soares Couto
License: Code: GPLv3, Assets: CC-BY-SA 4.0
Operating System: Linux, Mac and Windows

What is Zachlike?

The Open-Source Community group on Steam had a list of open source games on steam. That was how I stumbled on Marvelous Inc. The game was described as "a zachlike coding puzzle open-source game." A coding game sounded interesting but I had never heard of zachlike.

The term came from Zachtronics and founder Zach Barth. He created many programming/puzzle games. That style of game had become synonymous with his name. The game didn't have to directly tell you it is programming. It could be hidden behind the colorful frontend that claims to be something else.

Marvelous Inc. had you programming robots. The language used was effectively assembly language. You had no stack. The only flow commands were jump and various conditional versions of jump. The language had add and subtract but nothing more advanced. The puzzle aspect came from the limitations imposed by the puzzles. For example you needed to divide a number by another number but you have only ten lines and one register.

No Love

While it was available for purchase from Steam or itch.io, I downloaded the git repository and tried out the game. It used Love, an open-source engine you program in lua. I started up the game and received a warning that the game was written with Love 0.10.2 and may not work on Love 11.2. I tried to type in my username. The textbox for username remained blank despite my typing. I clicked the login button anyway.

I was greeted with two panes. The right was a splash screen. The left presumably would have the information to play the game but it was completely white like the username textbox. I exited but found when I loaded it again the name I had typed was displayed in a list on the right of the username textbox. The textbox must have been working just not visible.

I received some warning about the deprecated love.filesystem.exists function but that didn't have anything to do with the display problem. I looked at the release notes for Love 11.0. There I found "under other changes": "Changed all color values to be in the range 0-1, rather than 0-255". Since many colors were going to have at least one in red, green, and blue values, they appeared as white. Fixing all the code to use the proper ranges took a couple of tries.

Frustrating Keys

The game worked smoothly. In playing I found a minor pain point for me. I ran the game on a laptop. When programming I used the cursor keys to move around plus the home and end keys from the number pad. These keys were not supported under Marvellous Inc. It did support home and end and I could use the function key to generate those keys but I never did that. I added support for those keys on the number pad.

The developers did a very good job with their text editor in the game. The only other missing functionality that I noticed was the lack of page up and page down support. I did find the code tab didn't behave as I expected when the code was running. It still maintained the position of the cursor even though it didn't display it which meant moving up or down might not actually move the text display if it wasn't at the top or bottom of the screen. Neither of these were important enough to me to fix.

Custom Puzzle

Custom Level

While playing the game, I came up with a much too complicated solution to the puzzle "Hacking Forensics". The solution didn't work because I ran out of lines before I could output a solution. My solution used a bit field to represent the computers that were infected. It would have been needed if more than one computer had been infected at the start.

Logically it meant I needed to create a custom puzzle to implement the problem I solved. It would need more lines than the original and have at least two computers infected at the start. I started by copying the original puzzle and modifying it. Placing that into the custom puzzle directory didn't do anything.

The problem was that the development version of Marvellous Inc. doesn't support custom puzzles like that. Instead you need to create a new directory with level.lua and possibly email.lua. I followed the example in lparser/sample_level. I didn't completely implement it but started getting errors very quickly. After some investigation, I found the sample was using an older API.

This made me wonder what the last official release used for custom levels. Looking at the v1.3.3 tag, I found it lacked this API entirely. That version suggested copying the existing puzzles and modifying them. This meant if I made a custom level with the new API, no one on v1.3.3 could play it.

The reason a new API was created was for safety. The puzzle lua code could do anything to the user's computer. The custom puzzle interface API could restrict what functions the code was allowed to use. However in order to create a new puzzle that was usable by others, I backported the old custom puzzle implementation. The development version still supported the safer custom puzzle API but also allowed users to enjoy custom puzzles from v1.3.3.

I now had my custom puzzle loaded in the game. After a few robots were sacrificed to debug the level, I had my solution working. I tried running my custom puzzle in the v1.3.3 release. The puzzle crashed after I completed it. Turns out v1.3.3 had a bug which meant completing any custom puzzle will lead to a crash. In classess/puzzle.lua it calls self.custom_completed which was set to LoreManager.completed which didn't exist. Development build checks to see if the function exists before trying to call it.

I decided to fully implement my custom level in the new API as well. It has the nice feature that you can have an email introducing your custom level. I didn't find anything that I couldn't do. I've also updated the sample level to work. I didn't update all the documentation so there may still be incorrect information in the files.

STEAMING

Marvelllous Inc. was built with the STEAMING game template for Love. It was not built with the latest version. The game template seems to be changing things without sound reasoning. Between v2 and v3, the type field in the color object was renamed to tp. Granted you would probably never need to access that field. It continued to use values of 0 to 255 for colors so it was not compatible with new Love releases.

STEAMING looked reasonable. Not sure why the developer decided to default to HSL instead of the more commonly used RGB. STEAMING uses the HUMP library to provide common features needed for games like timers, game states, etc. It definitely appeared to aid in getting a game up and running. Marvellous Inc. showed that Love can produce commercial quality games.

Comments

No comments yet.




(optional, e-mail address only visible by admins)

Last modified: 2019-12-13, 15:19

© 2009-2019 Identical Games

powered by phpSQLiteCMS