The Development of Paimon Quest
We Made a Game!
After two years of development, me (ShnenyDev) and my friend (Koya) are happy to release our first game! It's startling how far we've come considering we started with almost no knowledge on game development. Koya is in game-dev college, but due to unfortunate circumstances, he never had the opportunity to finish a project, and I saw his lack of a programmer, and decided to learn programming just so he could finally put his (extremely ambitious) ideas to paper!
You might notice Paimon Quest is strikingly deep for a first ever game project, and yup two years is a very long time to spend on a first project as well. The ambitiousness of my friend was finally channeled, and because of that, I found myself learning very quickly and implementing extremely diverse new features. A large fear in game development is scope creep, when the goals of a game reach far beyond what is actually realistic to create, this was a fear that rang constantly in my mind, but as I tackled new challenges one after another, I found myself able to overcome them.
Early Development
Starting as a simple unity project aiming to recreate vampire survivors but in the vibrant land of Teyvat, Koya started by researching the intricacies of 2D pixel animation, he was heavily inspired by this article interviewing the lead artist of Crawl, a party game roguelike with an extremely simple art style, but extremely detailed animation. From this Koya learned that in order to properly animate a sprite, it is best to draw a primitive that achieves the desired motions before bringing it to life, adding detail and color.
If you follow a lot of pixel graphics games, you might notice that they have a very large amount of floating, teleporting, sliding, or dashing enemies, pixel animation is highly difficult, and in a game going for profit, the time and effort to create these animations is not worth it considering how much easier it is to make simpler animations with no real negative. A good example is the classic Mega-Man games, where every boss enemy is humanoid, yet not one of them has a walk-cycle, all instead having a single standing frame, and a single jumping frame. However, Koya, ambitious as ever pushed the limits of his artistic skill and made this very impressive animation.
While Koya was studying art, I was studying programming, Unity uses the C# language, with imported packages incorporating commands that interact with the unity engine, but me having absolutely zero knowledge of programming had no faith that I would be able to learn it. So I instead started with the incredibly arduous format that is visual scripting!
It was steady going at first, I quickly picked up how to implement simple things such as player movement, instantiating attacks, deleting an enemy, but before long I ran into a wall.
Nobody uses visual scripting.
With no learning resources, and nobody to ask for help, I came to a realization, regular text based coding is easier, and after downloading my first IDE, visual studio, I was able to achieve much more complicated tasks thanks to the support of the community, and the resources made available to me. (programming has a pretty tight-knit community, everybody borrows from each other, learns from each other, and helps one-another, it's cozy) Before long I had updating user interface, terrain generation, and enemy spawning logic working!
The Unity Disaster
Things were going too well, fate decided to intervene.
Just about a month after our development started, Unity announced a series of monetization changes. The short of it is that developers who reached a certain download threshold would be expected to spend $3000 to purchase a unity business license, and on top of that, each download meant you would have to pay unity 3 cents. The largest draws to unity were its ease of access, extremely fleshed out learning resources library, and the unity of the community, with these conventions being torn apart, and Unity's inability to answer simple questions such as how demo downloads or free software would be handled, the community was jumping ship. We all knew these changes were highly unreasonable and very unlikely to stick, but the security of our peace of mind and our future were compromised, thousands of people were dropping thousands of hours of work and migrating to other platforms.
We were pretty lucky, with only a month of time put in, we were not completely disheartened by giving up our work, but it was still very painful having to start over from scratch. We started our project fresh on a new platform, the Godot engine.
The road to release
While making the decision to jump ship was difficult, after we settled on it, rebuilding was actually extremely swift. While Unity uses a different programming language than Godot (C# vs GDscript, a modified version of Python), knowledge carryover between programming languages is very large. On top of this, the Godot developers knew Unity was the standard, and the design of the UI was meant to be very accessible to people familiar with Unity. (and indeed when I was asking for programming help, there were dozens of other 'refugees' migrating from Unity)
On top of adaptation being quick, the Godot engine has found clever ways to distinguish itself from other platforms. An integrated IDE means integrated documentation, you can simply click on any command and it will instantly pull up the documentation and instructions on how to use it.
On top of this, Godot's built in commands make concessions in performance, favoring ease of use and swiftness of implementation. The Godot engine makes up for this by being a very lightweight, simple, and clean engine, its baseline performance and load times are much faster than Unity. Especially for 2D projects, Godot offered many advantages.
This video by content creator Shesez demonstrates one of the performance deficits of unity, the fact that every 2D project in the Unity engine is actually 3D, the Godot engine features true 2D.
The cherry on top of the Godot engine is that it boots up in mere seconds, versus the minutes it took the Unity engine to load. These boons stacked up to a very desirable result for us, committing ideas into reality in the Godot engine was far faster than on the Unity engine.
From this we were able to much more easily incorporate and tweak very unusual game mechanics such as elemental reactions, procedurally generated stat-granting badges, complete character reworks, super oversized bosses made by combining and animating smaller sprites. Development of Paimon Quest was a joy, and debugging was only moderately painful! With each day I could feel the tangibility of our progress, and my own skills improving. The days breezed by, and the road to release was smooth,
Game development is remarkably accessible, you just need the passion to push yourself further, the dedication to stick with it, and a friend to keep you company, even if your goal isn't to make a fully fledged game, I encourage you to chase your dreams, as every new bit of knowledge and each achieved skill has value, I wish you all the best of luck in your endeavors.
We're just getting started, we hope you'll stick with us as we continue to develop Paimon Quest, or maybe even start new projects! I'm planning on doing dev-logs and progress updates here on our itchio page, i'm not too familiar with social media, so please let me know in the comments any platforms you would like me to share major update announcements, thank you for reading!

Get Paimon Quest -A Genshin Impact Fangame
Paimon Quest -A Genshin Impact Fangame
Return to Mondstadt in this action Roguelike!
Status | In development |
Author | ShnenyDev |
Genre | Action |
Tags | Fangame, Indie, Pixel Art, Roguelike, Roguelite, Survivor-like |
More posts
- Update: 1.01 minor bugfix patch1 day ago
Leave a comment
Log in with itch.io to leave a comment.