Tag: devlog

Last  time I talked about the level editor. Today I’m going to talk a bit more about the editor, because I’ve spent a lot of time lately working on it and I need to write down some of this for my own benefit.

The game will be released on Android and HTML5. I’ve been developing on Linux, and I’ve been testing builds for all three targets. Now, the level editor has been “done” for awhile, at least for Android and desktop. Editing, testing in the editor, saving, loading, and everything else was implemented. However, the HTML5 build had an additional challenge.

On the other platforms, saving and loading levels require accessing the local storage of the device and allowing the player to choose a level to load or a location in which to save the level. However, the HTML5 version of the game isn’t running on the player’s device at all. It’s hosted on a webserver that the player will connect to through their web browser, and so it doesn’t make sense (and indeed would be a major security issue) to give players access to files and directories stored on the webserver. To allow the player to save and load levels, it was necessary to transmit data between the webserver and their local machine.

Eventually, I bit the bullet and got down to implementing saving ad loading in the HTML5 editor. I didn’t need anything fancy; from the player’s perspective all I needed was to display a dialog letting the player choose a file to upload and a dialog to save the level file. I thought “That’s easy! Obviously I can’t do anything filesystem-related, but since I’m using (HaxePunk on top of) OpenFL and Lime, and lime.ui.FileDialog exists, this should be pretty straightforward!”

Unfortunately, lime.ui.FileDialog currently doesn’t support loading of files on HTML5. That’s pretty unfortunate, as that’s half of what the level editor needs to do with files. I was at a loss for awhile, until I found these examples of creating a file dialog and invoking it through javascript. Now, I tried these examples in jsfiddle to confirm that they worked, and so I implemented the examples in the game and it worked in all browsers I tested… except Firefox.

Now, Firefox has valid reasons to limit what can happen programmatically. I wasn’t surprised that I ran into a limitation for security reasons; I was surprised that the code only failed to work correctly on one browser (and a non-Microsoft browser at that). In the end, I did manage to get saving and loading on HTML5 working, after being pointed toward open.net.FileReference. If you got here from a search engine and want to know how to make this work, here is the solution that worked for me:

I created an instance of openfl.net.FileReference (called fr in this case), then I added the following code (only compiling it for the HTML5 build):

The  important thing to note is that fr.browse() is being called in response to a stage click event. This is necessary for the file browser to work; without being called in direct response to user input, it may be blocked for security reasons.

Once the file the user selected has been loaded, you can access the data like so:

The result? Working saving and loading of levels on HTML5!

I should blog about the development of this game. I’ve been meaning to add to my blog for so long anyway.

Huh, I got so wrapped up in developing the game that I forgot all about my plans to detail the development on my blog. Oh well, I’ll start tomorrow.

Hmm, wasn’t I planning to blog about this game last month? I guess I should start tomorrow.

Well, I meant to begin this a lot sooner. Like, months ago. Still, better late than never, right?

I’m making a new game. Well, not a new game. It’s a revamped and expanded version of an old game. That I made several years ago. That I meant to update much, much sooner than this.

The basic premise is this: A snowman is stuck on a frozen lake. The goal is to guide the snowman to the carrot on each level. There’s a twist of course: when the snowman moves in a direction, it won’t stop until it bumps into something. That’s ice physics at work. Adding additional complexity are holes in the ice that the snowman can fall into, snowballs that can be pushed around, and gusts of wind that will change the direction of anything that moves into them.The original game, made for Ludum Dare, had 10 or so levels. That’s a meager amount of content, so one of the items on my todo list was adding more levels. As of writing, there are 50 puzzles in the game. I didn’t want to stop there, however.

The project has gone through a bit of feature creep. I didn’t originally intend to have a level editor, but the simple editor I threw together was so useful for building the game that I decided to polish it up and make it available to players. That’s where a lot of time and effort went. It turns out there’s a big difference between “this editor works for me while I’m building content for the game” and “this editor is intuitive and user-friendly enough to be used by someone who didn’t build it and also it gives helpful feedback and doesn’t look awful.”

Adding to the difficulty was the fact that this game isn’t just going to be released on devices with a keyboard and mouse; I’m also targeting mobile devices (just Android for now). This means the level editor needs to be usable on a mobile device with a touchscreen. The non-mobile editor looks like this:It’s a pretty straightforward editor. Click on the icons to the right to select an object. Click on the tiles in the level to place the object. It’s mouse-driven, which means for the most part it translates well to a touchscreen, with one notable exception: right-clicking. The non-mobile version uses both the left and right mouse buttons to place and delete objects, respectively, but touchscreens don’t have a way to differentiate between “left and right tapping.” As a result, the mobile version of the editor looks like this:The keyboard  shortcuts are replaced with on-screen buttons, and instead of right-clicking to remove objects, there’s another button to toggle between placing and erasing. It works pretty well. I’m happy to say that the editor is entirely functional on mobile devices (again, I’m just targeting Android for now). Placing, erasing, saving, loading, and everything else works. I’m not aware of another smartphone game that includes a level editor or something similar, so I wasn’t sure what kind of issue I’d run into. Apart from having to keep in mind that the OS will limit storage access to a particular location set aside for the app, as well as the differences in input methods, it was a rather straightforward task.

There’s one last part of the editor I’d like to talk about. You may have noticed a button in those screenshots labeled “Test.” I took some inspiration for the editor from the editor in Mario Maker (and Mario Maker 2, but I began building the editor before it was announced), and I especially liked the ability to quickly and easily test levels in that game. My level editor’s test feature works rather similarly: once the snowman and goal are placed, clicking the test button removes the level editor interface and lets the user immediately begin controlling the snowman to test the level. Moving between the editor and testing the level is quick and seamless. I’m not going to lie; getting that working felt great.

So that’s the level editor. There’s a lot more of the game I want to talk about, so I’ll keep making blog posts at least through release (this counts as marketing, right?). I’ve always enjoyed reading about how games are made, so if you have a similar itch, I hope these posts manage to scratch it.