Introduction

Hey everyone!

Some reading this may know me from my previous games (such as the now renamed ‘CINIS - Classic’) and some may not know my or any of my games at all. Either way, you’re reading this! Thanks for that.

With the full release of this game, ‘CINIS - Survivor’, I wanted to give some insight into the project, and how it came to be, what changed during development and why it ended up being a full release instead of a in-development one.

Let’s start off with CINIS - Classic.

CINIS Classic

Whatever happened to the classic CINIS (Formerly just CINIS)? Well, simply, I realized it wasn’t much fun. I was in deep development of the newest map intended for the 1.8 Update, and I had actually mostly approved its layout from the experimental release, as I moved onto art-passing the level. It was however during this process and playtesting that something occurred to me. The level is different, yes, but the gameplay has basically been the same from the start. “Have I approached everything the wrong way?” I asked to myself, and began to really study the game closer.

What I mostly found was that the game didn’t have the right moment to moment gameplay or feeling. Certain things fell ‘off’ and even the graphics were feeling sup-par. It didn’t feel like it was the best I could make or do, just what I had.

So then came a big question - What to do about it all? The core of the game doesn’t really work, and I have no concrete direction. Do I simply try and fix the game in patches and updates? Or do I start over?

Change of plans

As you surely know by now, I decided starting anew was the better decision. But how? I started out writing some goals for the project, what it would have to be. I even still have them here!

Now, per the name of this chapter, I’ll even spoil that not all of this ended up happening, but it’s still a good way of showing how this remake or spin-off actually started, and a good way of demonstrating how I nearly made some of the same mistakes with CINIS Survivor as CINIS Classic.

Overall I stuck to most of the development plan, starting small and scaling slowly. I did only make the shotgun and movement, and made sure that felt as satisfying as I could, without having anything to really move in, or shoot at yet. But if just this felt right, surely it’d be just as good with enemies and a level.

You’ll also notice that ‘Unreal C++’ is written here, as I actually wanted to learn how to write Unreal C++ and make games with that. I also had some ideas for gameplay elements that I for some reason had deemed to be important, some of which didn’t make the cut, and I think this was a mistake. I would also bring to light how this list doesn’t mention anything of how the game is played at all. This is one of the biggest errors here, as well as the lack of a concrete scope. I write that I should set the scope right, which I ultimately didn’t and just rushed into development still…

I think the reason for this was that I had originally imagined this as the first stepping stone in a much larger game, that would mostly still play like the older CINIS. I would start with just a combat arena and making the game play well there to test, and then soon enough I would make the “real” game on top of this, removing the arenas and focusing on linear levels again!

This was very naive of me. Because what balancing and gameplay loops that work well in an arena, isn’t what works the best in a linear level. It resulted in my designing and implementing things that ultimately went unused, as I basically attempted to make two games for the price of one.

Eventually, I decided that I would only focus on the arena instead. Having to think too far into the future wasn’t sustainable, so I would focus on the gameplay and rough map I had instead, thinking perhaps elements could be used later in the future anyways, even if just assets.

Earlier this year, 2024, I had then committed to releasing the game this year. But I wanted to to still become “perfect” before then. So in February - April I worked decently hard on implementing new features I thought were needed, and more content. Some of the stuff ended up being pretty good, such as new (and current) level design. Other things such as remodeled ammo pickups or an entire conductivity and flammables system, ended up not being used, mostly due to shoddy code causing unplayable performance.

Over the summer however, I realized these things, more content and weapons wouldn’t actually perfect the game at all. They may not even work! Instead I put a focus on polishing what was there, and testing for what was needed. I ended up deciding adding new enemies, The Nailgunner and Bomber / Big Guy enemies was the right call, along with a better, more clear progression system with the new reward chests, and more fast-paced intense gameplay. By refining these systems that were much closer to the player, I better realized what was lacking, and how to implement things there, hence the ability system.

In this period I would test and showcase ideas much more, and more frequent, and really analyze my gameplay loops to make sure all the pieces fit together, and weren’t just thrown in. For balancing, I mostly went with what felt fun, vs what was fair. I don’t really care for fairness in games at all, and I don’t think players do either. They’d rather have a fun experience that aligns with their perception of what the game is, than what is actually fair. For example, few people would say games such as Elden Ring are fair towards the player 100% of the time, but their fans will be quite adamant about how fun the game is to play.

But by doing these things, I soon discovered that the game could almost be considered done, if just polished enough… While time was slowly running out, it did seem possible to release it before the year was over!

I learned a lot about technical skills, design skills, but also just finishing projects. I didn’t actually want to update this game all the time, even though new enemies, weapons or arenas might be obvious, I just felt that it was kinda good as is. I was satisfied, and I wanted to take what I had learnt and carry it on to new projects.

Games as a learning experience

That leads me on to this new concept I discovered as I finished up the development of this game - Developing games strictly for learning. Not in the sense of prototyping individual mechanics only, or trying out an idea, or following a tutorial. But creating larger games, with the end goal of a release, but not for any monetary gain, simply learning to get better. I feel the idea may be a bit crazy, especially considering this is in addition to my own school studies.

Yet I think there is a lot to learn here. By only prototyping you may learn to make a single mechanic, or learn how to work with a new technology. But incorporating them into larger projects has new benefits that may otherwise be missed. This includes the performance, usability, and effect of the mechanics or technology. For example, this version of CINIS taught me to challenge my own concepts of what should be present in a video game level such as this. An earlier version of the game had health and ammo pickups placed around the map, much like other shooters such as DOOM or the main inspiration for CINIS, Quake. But what effect does it have? What does it do to remove it? I ended up removing these from the game, causing the player instead to rely on drops from enemies and rewards from chests. This increased the utility of weapons such as the nail gun and thermal canon, while also further encouraging players to play aggressively instead of being passive and gathering pickups to stay alive. This I believe I would only have really discovered in a full game release, and not just a prototype.

Other things prototypes may hold a developer back from learning, is usability and polish, and especially how long both can take to make. Here I define usability as how intuitive and “useable” a game is: “Does the controls make sense? Are they easy to learn? Do players understand what they’re supposed to do?” etc. One thing that increases the usability of a game is settings menus. Settings menus aren’t a requirement for a prototype to work, but are a must for released games. Tutorials, easy or complex are rarely present as well. But both are needed for a high usability game.

And when it comes to polish it is everything from UI, graphics, sounds, effects, gamefeel, and so on. Most of these are never the focus in a prototype, but once again, a high level of polish is more enticing to players. Especially since players are quick to judge a game based on presentation alone, so if graphics, sounds, compositions and or other things are “off”, players will be less likely to engage with the game.

But learning to decorate and make your games usable is one thing, but how does it run? Prototypes are also rarely optimized for end user performance, and may not test for it at all. In a game intended for release, the visuals have to look good, and perform well.

These are the things I have discovered about game development as I made CINIS Survivor. Not just the technical knowledge of C++, but how to design games and break conventions I thought necessary, how to focus on the core gameplay and what makes the game fun. But also greatly improved my abilities to decorate levels, author graphics, and make sure it works together, and runs decently well. These things I do not believe I could have learnt just as well if I had made the game only as a small prototype, or perhaps even decided on a early release.

An early release may just have encouraged me to handle it later, as that did become the case with the older CINIS.

What could have been better?

Survivor is far from perfect. But what is actually lacking?

Well, if we ignore content for a while, I think the settings menu would need to be much more exhaustive. It has many gameplay settings that should be present, such as hit markers and UI preferences, but also essentials such as rebinding keybinds. Other usability and accessibility settings are also be sorely missing here. Controller support would be much nicer for some users, and rebinds are needed for people not using QWERTY keyboards.

I think content wise the game is decent. More enemies could be added that would make the game play much better. Even just simple enemies may add more variation to the game. For example, in the original Quake they had dog enemies, and also flying enemies. I find it to be a genius move to include these, as they force players to move their mouse up or down, and track enemies at different elevations. Something similar here would have been neat for CINIS as well.

Visually I think it’s pretty damn good, but enemies are only knight looking dudes, and more diversity in the enemy rosters visuals would be good. Some weapons also have sub-par graphics or animations, as their models were simply ported into the game from the older CINIS. I think these should have had more time to at least receive new materials and effects, or at the very least new animations. Enemies also all use the same sounds, leading to a rather stale cast in the audio department.

So how come these changes didn’t make it in?

Well, I wanted to release the game. Really, I am overall very happy with the game and it’s state. I think it is the best game I have made as of yet. However, I also wanted to finish it. Not out of being tired or feeling burnt-out, no. I feel ready to polish the game right now and fix the issues as I am writing this. But simply, I feel I learnt all I could from the project. And if I have no ideals of releasing it as its own big monetized release, I see no reason in attempting to perfect it, beyond going on a ego-trip of making the perfect game. So I wanted to stop it before I got into deep.

I also feared that I may just continue making content for the game and adjust the map, if I didn’t put a bow on it and crossed my Ts now. So I wrapped up development, and will move on to new projects.

And speaking of new projects…

What is next?

Short answer is, I am not sure about what is next. While making CINIS Survivor I actually did prototype or design a few games, mostly with friends, and I feel inclined to continue some of those projects now, that I have more time to dedicate to them. In all I have 3-4 projects in various states, most of them just a rough idea in a document, some more elaborate designs with very early mechanics testing done. I won’t talk in detail about any of these projects, you’ll simply have to see what’s next :^)

I can promise that more stuff will be releasing, but I can never guarantee when, especially with studies and work being part of my workload too, in addition to having a life. I don’t really expect anyone to be holding their breath for the next project anyways, which is the biggest reason this is section is so short.

In the end

So, that’s basically what happened to the old CINIS, how that became CINIS Survivor, and what I learned and changed during development. If I had to pick one of the most important things I have learnt from this project, then it would probably be the idea of releasing smaller games, and have those games be in a finished playable state. Even if they later grow or evolve to something lager, there should be clear endings or MVPs that are more easily attainable, and how this approach also bolsters learning.

By setting a very specific scope and size, and committing to a game in that size, it allowed me to take any other ideas and write them down as an idea for future games, and design other games in the background, which I hope to work on some day more fully.

If you made it all the way to the end of this post, then thank you so much for reading! I feel this post may have been way too long, but it’s also everything from the last two years of working on this project, so had a lot to say.

If you end up playing the game, feel free to give any feedback you might have! While I most likely won’t update this game, I always appreciate feedback as it allows me to learn for future releases.

Thanks for taking the time to read this!