Jam postmortem.

Making this game was pretty difficult. This is the biggest jam I've submitted to so far, so I wasn't used to having so many people actually play something I've made after it came out. It took awhile to get over my emotional attachment and confidence in the single other playtester's ability to find issues with the game before I would really be accepting of incoming criticisms.  So, I made like a triple-a dev and just tried to play tech-support. I mean, the game works. It's not working for you? Well, here's some things you can try! That's exactly what people want to hear when they have dozens of other jam entries to get through.

That last point was also the main weakness of the game in practice. I don't think The Beacon is a bad game. I swear that's not because I made it. I think it's playable, even well designed. But it is esoteric. And difficult. Difficult, esoteric titles were fighting an uphill battle against more approachable submissions. That really sunk in when I got to Distant Paradise, my overall favorite submission in the jam. That game balanced being a technical feat with strong mechanics, presentation, and pacing. Even if my game managed to cram close to as much content as there was in Distant Paradise, very few people would have actually seen it. Even with the relatively low amount of content in The Beacon, I don't think anybody finished it! 

The other playtester was my roommate. He must have some insane videogame skills to have beaten the game so quickly, or maybe he knew what to do just because I had been talking to him about my working on it leading up to the submission deadline... That's also possible.

Post-release

I patched something in the game during the extended release window. I then ate dinner and went to bed. I had work the next day. Somehow, somewhere, someone at microsoft decided that I had been a naughty boy and the zip files I uploaded were corrupted! How does that even happen? I had exported my game from Godot, zipped the files to upload them to itch, assumed- by selecting the files and telling my computer to compress them into an archive -that the uploaded zip files would be valid zip files. This is of course a massive skill issue on my part. I guess I'll set up butler for my next project.

Suitably, I was pretty anxious. I didn't want to just pin a link to the files in a google drive. The game already asks for access to your network. Which we'll get to. Adding another layer of crust like this and anybody who downloads this game and doesn't already have a virus on their computer might as well have gotten one anyways. I tried to play it cool. Maybe all the people who downloaded the game already were all the people who wanted to play it? But of course, a complaint came in 1 or 2 days later. I made a post in the jam forum asking for help, since the rules specify that entrants should make a forum post about questions regarding submission.

Process flaws

In my opinion, the design flaws of the game currently are much less interesting than the process flaws. The flaws in the workflow that made it hard to modify the game quickly. If there's anything anybody can learn from this project, it's here.

First, the environment system. The Beacon has a system to change the sun, footstep sound, and ambient music based on the area the player is in. It works via a set of handmade entrance triggers for each area. The trouble with this is that there's no way for the player to know what area they're in when they first spawn. For some reason, it didn't occur to me to place such an area at the player's spawn, and register it as an "entrance" to the hub zone. So, when I exported the game, if I wasn't careful, I might have the wrong default environment selected. This was especially annoying when baking the lightmaps for each zone. This process required manually enabling the environment for the zone I was working in, and manually dis-abling the environment for whatever zone I was previously working in. I had no editor tooling set up for this. So much time was wasted on broken lightmaps and exports because of that issue. I needed to take a step back to fix it, but I never did. This is probably the first thing I'll be addressing as I work to update the game.

Second, the multiplayer. This game looks a virus. That's because, even before you've unlocked multiplayer, the game instantly tries to start a host session. This is the reason the web version doesn't work, which was a big pain point for most players. I don't think the "___ is trying to access your network" message would have shown up if I architected my game to use a dedicated server instead of a peer-to-peer connection system. Since the server-client architecture is also much more well documented, I would have had better support through forums and would have been able to implement the multiplayer more quickly. That also would have made it web-compatible (you can't host a peer-to-peer connection in a browser due to security concerns on the side of most browser developers, but you can have a tcp client)

Third, the temple. Remember that thing about lightmaps? So, the temple, the part of the game with the gun, is much too spicy for my gpu to bake the lightmaps for. I was lazy with the lighting and put a lightsource in every window of the temple to simulate light beams coming through. The result is 130-odd static lightsources. If you try to bake anything on the temple, the editor crashes, simple as that. So, I had to hide the temple when baking the lightmaps for that area. But of course, that's one more thing to remember to un-hide when launching the game again. I got super paranoid that maybe I had shipped a version of the game with the temple missing a few days before the end of voting. Luckily this didn't happen, but that shouldn't have even been a possibility!

Design flaws

First, the platforming. I really, really wanted to implement a dark souls style recovery-point system. In dark souls, an invisible ghost is following your player at all times. It's not symbolic or anything, it's literally just recording where you should spawn. Once every 3 seconds or so, it checks if you are on safe ground, then teleports to your location. Then, when you quit out of the game, the last location of the ghost is put into your save file. This is an incredible translation of the classic platformer mechanic of sending you back to the beginning of a room. But it seemed a little rough to implement. I didn't want the heat, and my game suffered for it. I added "safety platforms" below the critical path: broader platforms that were easier to navigate, but it came off less like a safety net and more like a Bennett Foddy torture trap. Because you keep slipping off the critical path and keep landing on the "safety platforms". It's so frustrating and not at all like the mechanic I was trying to substitute for.

Second, even with proper precautions, the platforms should have been wider. I stand by the idea of the player moving quite quickly. I like that. But the level should have respected that more. I love precise platformers a little too much. And the challenge of getting up the tree was something of a treat for me to look forward to when I was moving between playtesting an programming. But this didn't work for other players. When testing with my roommate, we actually caught this design flaw, but I determined it was too late to fix.

The good parts

So, what's good about this game? I certainly seem to think it's good. Even that there's reasons that you should play it, though I would recommend waiting for some updates to roll in.

First, the story. It's a simple, funny story that, if you can get around some of the awkward points of the design, adds some nice context to the game with just a few words and drawings. Depending on how attentive you are, you might be able to figure out why you're on this planet within seconds of starting the game, while other people might not realize until the end credits. Especially for a multiplayer experience, I think it's important to have details like that that friends can have a discussion about.

The metroidvania. My game is a metroidvania. The movement abilities change how you see a mostly static map dotted with some scripted shortcuts, and after you get the first jetpack upgrade you have two branching paths of progression, both with their own loops back to the hub area. It's small, sure, but I think I executed the mechanical flow of the map quite well. I'll strive to make the visual flow better in time, of course. I like that you can meet the monster before you have the means to hurt him, even though most players found this frustrating (especially when you get the gun and it doesn't help, you need the titular beacon).

Finally, the sound! Of the other submissions I played, very few of them paid much attention to the music and sound. I paid a lot of attention to these, and it paid off. The music is moody, but also goofy at times, fitting the vibe of the game perfectly. I want to make more tracks in this style, maybe with different variations of the area themes.

Things I want to add 

I want to add back a mechanic where players in multiplayer could shoot each other. Since you have 3 health, this can be done up to 3 times. This could be motivated by a second temple, one where there are hallways of lava that take a lot of jetpack fuel to get across.

I want to add a new area with a new boss. I have an idea for another ability that, like the beacon, I hope will take players by surprise, and fits the theme of a suspiciously ghost-powered set of space gear.

Then there's all the fixes I listed on the game page. 

If you're reading this and played my game during the jam, I hope this gives closure to some of the mysteries you might have encountered. I'll start working on updates in a week or two. Thank you all for playing.