Piggr Post-Jam Postmortem

I have been a participant in every Harold Jam since the beginning, and I fully intended to participate in this one. As I brainstormed my plans for the jam, game dev mentor Steel of Studio Blue advised that I try using an engine other than RPG Maker to create this entry. Given my desire to learn other engines and that I was working with another group to make a long-term project with Unity, I took up the challenge.

The question now was: Which engine? Give that I already was working with a group to make a game in it, the natural first option to explore was Unity. I had picked up the latest edition of the ORK RPG framework from the Unity Asset Store, so I decided this would be the perfect opportunity to try it out. Could I make a 3D RPG for a game jam? The prospect excited me.

In the weeks leading up to the jam, I spent as much free time as I could (which wasn’t much, given that I was working 45-hour weeks at my day job, plus running a non-profit organization) learning how to use the ORK framework from YouTube tutorials and the framework’s own tutorials. A little background on the ORK framework: It provides a foundation for creating several varieties of RPGs, be they turn-based combat, ARPG, or grid-based tactical, in both 2D and 3D, without needing to touch any C# code. Instead, you use a graphical database entry system known as Makinom. This sounds like a dream come true for a developer transitioning from RPG Maker to another game engine, especially since it includes the ability to create games in 3D and has native support for ARPGs, but unfortunately the reality is rather disappointing. I spent weeks pushing through the native tutorials, but could not understand the flow of setting up character attributes and why things weren’t working at the end of some modules despite following everything to the letter. The YouTube tutorials were made by users who used paid add-ons in addition to the ORK framework and were otherwise hard to follow. Frustrated, I decided to look elsewhere for my project’s foundation.

Next up was Unreal. I considered this engine because of Studio Blue’s enthusiasm for the engine and the allure of Blueprint, Unreal’s built-in visual scripting solution. Unlike Unity, I have no prior experience with Unreal, so a good framework would be a necessity. I had wishlisted the Super RPG Framework in the Unreal store on the advice of some community members who are familiar with Unreal’s stock, so I decided to buy it and try it out. It made a good first impression: there was a demo project available right out of the box that I could play around with and try modding. I successfully changed one of the background music’s tracks to a custom song and even got as far as adding a new character model before I ran into roadblocks. While I could successfully see the new character in the game, he was forever stuck in a T-pose, and I had no idea how to apply animations or rigs to him. Furthermore, I couldn’t figure out how to make more changes to the database. I could see and preview animations, but could not figure out how to link them up to anything, no less add or modify my own. While I could have reached out to the community to see if anyone could answer my questions, I was concerned that it would be too time consuming as whoever responded would effectively need to give me a full course in how the framework worked, which would obviously be asking a lot.

We were into the first week of the jam at this point, so I needed a solution fast. I perused the asset stores for both Unity and Unreal to see if there were any easy-to-use frameworks that would produce reasonable results. I considered other RPG frameworks, as well as endless runners, platformers, and shooters. Nothing seemed to really speak to me. But then I looked into visual novel frameworks. I knew that visual novels don’t require too much technical sophistication to create, as the genre emphasizes storytelling and simple choice systems over complex gameplay mechanics, so that seemed like a likely solution. I discovered a few different visual novel frameworks in both asset stores, ranging from free to triple-digit prices. I am not averse to spending a three-figure sum of money on something that will be useful to me long-term, but it didn’t make sense to spend that kind of money on something that may not last beyond the scope of the jam project. I also tried out a couple of YouTube tutorial series, but found them to be too code-heavy and time consuming. Instead, I settled on the VNCreator framework by Rambear. I found this free framework to be highly intuitive, as it uses a simple node-based visual interface to construct the timeline and branching paths of the narrative. The simplicity comes at a cost: nodes support a music channel, a sound effects channel, a background layer, a character layer, a name box, a dialog box, and up to 3 choices. That’s it; no animations, no loop points, no other fancy options. I was afraid this would leave the presentation rather dry, but it was better than nothing. I charged ahead.

Now, it’s one thing to know how to make a visual novel; it’s another thing to actually write one, and while my focus in these jams tends to be on the technical side and I love drawing, that left few resources for the most important part of a visual novel: the story! Luckily, my lady, Hamster, is an accomplished writer but had been in a writing slump for the past few years. When I approached her to write the story for the project, she agreed, seeing it as a chance to revitalize her writing skills and participate in making a game with me in a capacity she is comfortable with.

The next problem I faced was the presentation: as stated earlier, the VNCreator framework is a rather limited one, so I looked to my resources to see if it could be improved. Hamster’s sister, who happens to be a degree-carrying computer scientist with some Unity experience and has a tutoring business happened to see me playing around with the framework one day and mentioned that she could show me how to modify the framework. I agreed and set up a few sessions. While she did successfully show me how to modify some small things, there were bigger changes I wanted to make which ultimately would take more time than I had and more technical knowledge to fully realize, so I had to give up on that effort and look elsewhere once more.

By this point, I realized there was another engine that I had not considered: GDevelop. Much like RPG Maker, GDevelop is a "no-code" engine in which developers use an if-this-then-that visual scripting format to construct the game's logic. Back in the 2021 Driftwood Gaming Jam, I had created a game called “Dungeon Clicker” using GDevelop in a week. I figured if I had been able to make one simple game in a week at a time when I had more free time, surely I could make another simple project despite my limited free time? It would still fulfill my personal requirement of using a non-RM game engine while affording me more flexibility in the visual novel’s design. I tried making a simple foundation project, just change some text with a forward and back button, and it was a success. I had finally found my engine for the project.

Now, anyone who has made a game of any substantial length will know that if you try to just jump into making a game, you will likely run into all kinds of unforeseen issues that can completely derail your progress, so I decided to try to plan out the game’s structure outside of the engine. I decided to use PowerPoint to storyboard out the project so I could easily see what each scene would look like without getting bogged down by technical issues. I didn’t have the art for the project yet, so I pilfered some sprites from an abandoned project and modified them to give me a sense of the size, shape, and position of the characters in each scene. It also helped me see the patterns in the design, like how many characters would be on the screen at one time and how many story branches would be present.

Once I had the story visualized, I fleshed out the in-engine framework some more. Starting with just the text, I got the major story branches fleshed out and working, and ensured I could traverse both forward and backward without bugs. This part was pretty straightforward since I was dealing almost exclusively with text; no visuals were involved yet.

Speaking of visuals, I wanted a visual component to this visual novel, so I needed art. Drawing and other art forms have always been a part of my life, so I have decent art skills, but I haven’t had many opportunities lately to showcase my abilities. I saw this project as a perfect opportunity to focus on the art and show the world what I am actually able to do, and not just the deliberately poor quality of the Bad Ducks series or the RTP-centric art of games like Dracula Is Dead. Since I wouldn’t be limited to small sprites typically seen in other games, I was able to utilize tools I don’t usually get to touch. The majority of Piggr’s artwork was done on my iPad Pro with Adobe Fresco. If additional edits were needed, I did them in Gimp on my computer, then imported them to GDevelop. I spent the majority of the rest of the development time making the art as Hamster finished writing the script.

When I wasn’t working on making the art, I was assembling the game in GDevelop. The overall construction was simple enough: click the Next button, increase a variable that told the program which elements to show and which to hide. Unfortunately, computers are very literal machines and won’t infer that a “Back” button means “do everything you did for the Next button but in reverse.” Due to this oversight, a rather pervasive bug emerged in the project in which some elements would stick around when the Back button was pressed. I did my best to patch the issue out, but I didn’t have enough time to thoroughly test every route back-to-front, and as a result it’s rather easy to get into a situation where some visual elements persist after pressing the Back button.

Once the final week arrived, I felt the project was in a good enough place for me to try creating a soundtrack. I pulled out Logic Pro X on my Mac Mini, found a fun ukulele loop, added a bass and drum track, and called it my title screen song. Unfortunately, I still had a large quantity of art still to do, plus a Back button bug to squash, and the hope of adding animations and other polish to the visual presentation. I even took a day off work to give me more production time, but it just wasn’t enough, so the title track is the only song in the project.

I have found publishing games in both web and Windows formats work wonders for traffic, and since GDevelop supports both types of deployments, that’s exactly how I released the project. GDevelop is a very web-friendly engine so I doubt much, if any, fidelity was lost in the web version. In my typical game jam fashion, I was working on features and bug fixes up to the last hour and posted the project to the jam with just minutes to spare.

Jams are always great sources of feedback, but I was not content to limit my reach to just the jam participants; I took to Twitter and Facebook, writing posts promoting my latest work. I also posted links to the project in several Discord self-promo channels. I was surprised by the response: many people I had not seen comment on posts like this in the past responded with promises to play the story or even share feedback on their experience with it (mostly complaining about the darn Back button). One respondent even gave a rather generous donation to the project, making Piggr my top-grossing project of all time – impressive, considering it’s a free jam game! Final rankings for the jam have yet to be released, but it seems that even though Piggr likely won’t get top ranks in any of the categories, its strong points are comedy, story, and graphics, which aligns with my expectations. Piggr has 74 browser plays and 17 downloads as of this writing, which in my experience is a respectable performance.

Looking back, I would say Piggr was a success in that it accomplished what I had intended: create an entry for Harold Jam using a non-RM engine, as well as give Hamster a way to collaborate with me and even an outlet for me to finally show off my art skills. However, I can’t help but think things may have worked out better if I had stuck to the VNCreator framework in Unity. I didn’t get nearly as many animations in as I had intended, and of those that made it, most were plagued by backend structural issues that resulted in navigation bugs (a.k.a. more Back button woes that, even with workarounds, didn’t result in good user experiences). Not having to create the entire backend and troubleshoot Back button issues would have left me with more time to focus on filling in the frames that were missing art and possibly also create a full soundtrack. Given this revelation, I have started to explore porting Piggr to Unity and use the VNCreator for its post-jam update – stay tuned to see if that actually happens. As for GDevelop, I don’t fully regret using it for the project. In fact, I learned a lot about how to best structure a visual novel in the engine, as well as increased my general proficiency in GDevelop, so I may well use it for another project in the future. Will that be another visual novel, or maybe something in another genre? Time will tell. Also, many respondents expressed a disappointment about a lack of ability to date Lucius. Hamster enjoyed writing for this project and says she would be happy to write a sequel rectifying that, so watch for that in the next Harold Jam.

Thank you for reading this rather long behind-the-scenes recounting of my experiences. I hope it was enlightening in some way, and I hope it gives you a greater appreciation for our little labor of love.