Postmortem: Sharp Turn
A beginner’s indiedev experience of creating and publishing a text-based role-playing game
Introduction
Hi, I’m HardPenguin! A solo indie developer specializing in programming and QA from Warsaw, Poland. For my day job I currently work with Python in the corporate business world. In my free time, I work with C# and Unity.
Nearly two years have passed since I completed and published Sharp Turn, my first semi-serious game development project. What was supposed to be a small training task, started solely to learn a new programming language, ended up consuming three months of full-time work.
In this article, I’m going to highlight what went well during the production, what did not, and what other beginners could learn from my journey.
Sharp Turn is a text-based role-playing adventure in which the player becomes one of the three available characters: Barbarian, Enchanter, or Sneak. The main objective is to find and help your lost partner. In order to do so, the player needs to stay alive during randomly drawn encounters. Choosing the right action while making sure not to run out of food are both the priority. The game features permadeath, so if you fail, you start over — which is basically the core mechanic behind the game. Try, die, repeat, until you win.
Was it the first game I have ever made? No. A couple years ago I spawned a turn-based minigame in LÖVE (Love2d) using Lua. As a kid, I also produced a short title in RPG Maker 2000. Both of these were significantly smaller though, and much simpler to create.
Plans & beginnings
Why make a game?
First of all, a bit of context.
In November 2018 I was in between jobs. My goal was to keep working in the video games industry. I wanted to be as close to games as possible, preferably making them. However, the mismatch of my experience with the direction I took was posing a problem: so far, I worked “only” in a digital distribution company, not in a game development studio.
Although my previous job involved, among other tasks, resolving OS-level issues in hundreds of games released on our platform and doing overall QA for them, in order to become a full-time game developer I needed quite different expertise than the one I gathered for over 4 years there.
After browsing gamedev job boards for a couple days I could confirm what I already knew — Unity with C# and Unreal with C++ were the two most desired skill sets on the market. Since my passion lies mostly within small 2D indie games rather than large 3D productions, Unity seemed like an obvious choice for my next career step. I planned to learn it by creating a game, while enriching my portfolio at the same time.
I had some affairs with C and C++ in the past, but they were rather short-lived. Unity meant working with C#. To fill the gap in my knowledge I went to Tutorialspoint, which I recommend to any coder looking to learn a new programming language or framework in the most straightforward way possible.
Even though my friends definitely do not think of me as a Microsoft enthusiast, C# turned out to be an okay language. As a Linux user, I am grateful to the Mono team for their effort over the years to make C# easily accessible on this platform. Their documentation is also a pretty solid resource, along with the official Microsoft docs.
Long story short — one would think that after finishing all of the language tutorials I would just move on to Unity, right? Unfortunately, that is not what happened. For some reason, I decided it would be a good idea to finish a small game project utilizing C# in a more “basic” form first, just to strengthen the foundations I had learned.
After taking a peek at C# SDL (which looked outdated and abandoned) and somehow failing to notice the well-maintained SDL2# (I have nothing but respect for flibitijibibo’s awesome work!) I suddenly had another idea. I decided to create a game in… a GUI framework.
Inspirations
During my childhood years, I spent many blissful hours playing a niche freeware Polish game titled Biznes Filmowy (Movie Business). Made by the independent developer Tomiga, it was a tycoon simulation released in the early 2000s. In the game, the player was responsible for producing a Hollywood movie. This involved selecting the cast, picking the director, special effects budget, and managing the marketing campaign. The result was calculated by a rather mysterious RNG-powered algorithm that took into consideration properties such as acting level and popularity of the hired actors.
Considering that the game could be played in multiplayer hotseat mode, it was a big hit in my friend group. If you are interested in it, the Movie Business series has been translated to English and is still being maintained. You can download both games for free from the author’s website, or just the sequel from itch.io.
This bizarre, yet brilliant oddity of a game could be played in a Windows window only. It used regular GUI elements, such as buttons, checkboxes, radio buttons, and others. I suspect it was simply coded in MFC. And even though the limitations of this technology were apparent, the gameplay was super fun. It was Biznes Filmowy that inspired me to do something similar in Gtk# — and thus the Sharp Turn project was conceived.
My other significant influences were:
- Hand of Fate — which inspired me to use the idea of randomly drawn encounters (just like cards from the deck!) with multiple choices deciding the outcome,
- Fallout —which was utilizing meaningful abilities that affect how the situation unveils for the player,
- Tajemnica Statuetki —which presented the unique art style achieved by heavily pixelating photographs (which were taken during the vacation by one of the developers).
I would like to highlight Tajemnica Statuetki (The Mystery of the Statuette) since it is yet another curious Polish title. This first person adventure game was developed in the early 90’s by Metropolis Software. The studio founded by today well-known, at least in Poland, industry personalities: Adrian Chmielarz (currently of The Astronauts) and Grzegorz Miechowski (currently of 11 bit studios).
Ow, that hurts
Time management
When I began the project, the premise was pretty simple and the planned scope was small. The estimate was that the game would take me about one month to make. This included 3 weeks of coding in a language I did not have any experience with, and 1 week of creating some simple visual assets.
If you ever shipped any software product you can already see how wrong I was. This kind of thinking ended up being the biggest fail of the entire endeavour. Yes, the code took me 3 weeks altogether — just as planned. But the assets? 3 long months.
If you are interested in game development, and especially if you are still fresh in the subject, I am sure that you hear lots of advice from industry veterans. Have you heard this one? “It does not matter how much time you estimate your project will take — always plan for at least two (or three or four) times as much”. This pearl of wisdom turned out to be painfully true for me.
By the time I finished my project, I was no closer to mastering Unity than when I started. At this point I was running out of money and had to start a new job.
Choice of tech
The second pain point was certainly my bad decision to make a game in a framework not designed for this purpose. Gtk# is a solid toolkit for creating day-to-day application software, or specialistic and productivity tools. It offers a straightforward and logical way to send information between application windows via events. It blends in a nice, consistent manner with the rest of operating system applications on Linux and Windows.
But because of that tight system theme integration, Sharp Turn ended up looking differently on each machine it was played on. A most common example was the use of a dark window theme. Such preference was the cause for a bug causing some sprites blending in with the background.
The choice of Gtk# also forced the user to install additional redistributables, as without them it was not possible to even launch the game. This was confirmed by the early testers. I was not able to alleviate these issues at the time. Common game making tools such as Unity have already resolved the majority of such basic problems, which is a good reason to use them instead of reinventing the wheel.
Inconsistent art style
I could not afford to hire a qualified artist so I embraced the common saying: “beggars can’t be choosers”. By that principle, I downloaded tons of free photographs, sprites, and drawings that even loosely matched the medieval fantasy setting which I had in mind. After making sure they were explicitly listed on a permissive license, I processed them to match the project’s “vintage” vibe, and scaled the dimensions properly.
The end result is better than I expected, yet still it clearly shows lack of consistency. The culprit was likely the vast variety of source materials, as well as my limited abilities.
From this point, I would like to extend my thanks to Marcus J. Ranum and his freely available collection of fantasy stock photography. And I want to thank every artist sharing their work for free. I would not be able to finish this project without your selflessness and generosity.
Doing everything by myself
From top to bottom, I was responsible for: managing the project, writing the code, designing the gameplay and the UI, testing, debugging, inventing and writing the plot, processing game art and producing the music background.
That is enough work for an entire game studio, even if we assumed that one person did more than one thing. And while handling it on my own was satisfying, it was often frustrating as well. As stated before, I am a programmer. Not a graphic designer — despite my vivacious passion for making memes in GIMP. And certainly not a writer.
Work on the graphic assets took 3–4 times more than the code. For most of development time, my routine looked like this: Every day, I was waking up, eating some breakfast and ingesting some caffeine. After that came searching the internet for freely accessible images. Then I was spending hours in GIMP by scaling and tuning them, making them look “more retro” by using the “pixelate” filter, and reducing their color palette.
Still, making the visual art was tedious but easy. The biggest, most time-sinking challenge turned out to be writing. To this day, I am not sure how I managed to write over 40 unique encounters without going crazy. It was a demanding, creative work, very often conditioned (or, rather, limited) by the available sprites. One thing I know — I don’t want to do it ever again. Humbled by this experience, I can say for sure that my respect for writers has grown exponentially.
Not so bad after all
A chance to learn
From beginning to end, working on Sharp Turn was a big opportunity for self-improvement. Which is good, considering my long-term objective to get hired as a full-time game developer. Some things which I have learned, often from scratch, were:
C# programming language
Coming from a scripting languages background I expected to be eaten alive by a new language from dreaded Microsoft. In the end, it turned out to be easy enough and in fact pretty similar to coding in other languages I already knew.
My own limits
At work, being able to evaluate what I can do by myself and what I need help with is crucial. This project showed to me clearly that I am not a one-man army and probably will never be. It is good to get backup from outside, especially for my own sanity.
New organisation and motivation techniques
Even when you are working for yourself on your own terms, finding motivation to achieve your goals can be difficult. That’s why lots of tricks help. In my case it was meditation, caffeine, and splitting work into smaller bits. One particularly revealing discovery to me was “warmup”. Before facing a big, intimidating task, I first did a smaller, easier task, possibly one that does not involve much thought. After a while, I entered the state of flow, and more challenging tasks became much easier to do.
(Hopefully) better project management
After spending over three months on something that was supposed to take one I really hope I will not underestimate project scopes and timelines so grossly again. I hope. Task trackers and such help — I used Trello.
Publishing on itch.io
itch.io is truly every indie developer’s friend. It comes with a thorough documentation, easy to use interface, plus a bunch of publishing and analytical tools. Uploading builds from the command line tool butler to then run them from the itch app was a breeze! Perhaps this experience will translate nicely to publishing on other distribution services in the future, who knows?
Free art is a blessing
I can not repeat this enough: content posted online on permissive licenses is a gift from the internet people for the internet people. Authors of such content usually do that with the intent to help others. Keep that in mind and use it as help with your work: with changes, “as is”, or as an art reference.
Leveraging existing talents
As a kid I received musical education and played multiple instruments. This came in handy when I had to adding some music to the game. I fired up LMMS to create a couple instrument lines, edit them a bit, and then export them as a track. Sure, I did not create a masterpiece. But it is very important to note that creating music took me about a day, especially compared to how long it took me to develop other aspects of the game.
Testing
There are not many elements of the video game production process that are as crucial as testing is. It not only helps you deliver a better, more polished product thanks to bug reports, it can also be a source of opinions on whether the game is actually fun or not.
My prior experience with the games QA served me well here. Both organizing tests and collecting feedback with Google Forms went smoothly. Testers were mostly volunteers from Twitter, sometimes fellow game developers. Without their work and perspective from outside, many issues with the game would go unnoticed until after release.
Summary & advice
I would like to close this text by outlining some advice points which I have for other inexperienced independent game developers, now that I was able to produce a game from the beginning to end myself. First of all…
Know your strengths
Not only know them but remember to use them as well. My advantage was prior experience with coding and music making. If I decided to make a game emphasising on those two elements, I know that I could end up with a better end product with less work. Instead, I spread myself too thin and wasted too much time. Which leads me to the next point…
Outsource as much as you can
There are very few of us that can do it all. Once you identify your strong points, think what you will need help with. In my case: I know there are artists out there which are in the same situation as I am — being fresh to the gamedev but having experience in their own field. Bringing them in to your project will benefit not only your game but also their own portfolios. But how to do that as a solo beginner?
Ask other developers, artists & community for help
The indie development community is vast and usually very helpful. Some people will want to help you out of kindness, boredom, satisfaction from participating in a game project, or simply for a mention in the credits section. It is okay to reach out for volunteers. That was the way I was able to get my game tested before I released it to the public. Ask for learning resources or for recommendations of specialists that might be interested in joining your project. The internet shall provide.
Exchange favors
If you cannot afford hiring an experienced artist, a musician or a coder, you can also offer an exchange of favors. One of my Twitter gamedev mutuals was kind enough to provide proofreading for the story text. It was crucial in the context of a text-heavy game. In turn, I helped a little bit with the Linux aspects of his game. Voluntary cooperation ending with mutual benefit.
Remember: doing poorly is better than not doing at all
Sharp Turn development was a bumpy road. While I am not overly proud of the end result, I am very happy with the fact that I produced an entire, even if small, video game. In the end, I learned a lot and proved to myself that I am a capable game developer. Because of that I can say with confidence that it was a priceless experience to me. It could never happen if I turned my back on it or decided to move on to the next project.
What comes next
As I am writing these words, I have already ported Sharp Turn to Unity. You can play it in browser right here. You can also download an offline build for Windows or Linux.
Learning Unity is an awesome journey with loads of learning resources and documentation available online, totally free of charge. That is what I am gonna focus on from now on. Hopefully, each game I make will be easier to develop than the current one.
I hope you found this text useful, or at least, entertaining. Let me know what you think and visit my Twitter profile.
