What's this game anyway?
While I can entice you with all kinds of interesting facts about my game, I will not. As I do not know anything about the game yet. All I can tell you is the idea of the game: COD Zombies but in 2D and it's set in Medieval times. The game will take place on a small level where the player has to fend off swarms of zombies, equipped only with medieval "tech". I like the idea so much since I love the period and wanted to make a game based on sword fights and old-timey battles for such a long time. What's better than making that with medieval zombies? Again, I do not know the finite details since I'm still prototyping the game, but I do have a plan to add some variety in weapons and armor. The game will be as gruesome as possible, with blood and flesh flying everywhere on the top-down map. I want to make slashing the zombie's body as satisfying as it could be.
If you think that's a little bit vague and not straightforward, then that's because the game is just in its infancy. As I said, the game is still in the prototyping phase. Even I don't know where it can go. However, one thing I do know is the game's scope should... nay, must be kept to a minimum. I'm only one man with minimal programming skills and I'm devoid of any artistic talent. Yes, I'm reminding myself while I write this.
The Idea Struggle
Making games is hard. I'm sure you heard that a billion times before. But it's true. I'm sure you feel it when you make games and I'm sure even industry professionals feel it. Games can be hard for several reasons. Perhaps it's the technicality involved, maybe it's the art, the music... but my struggle with game development for the past couple of weeks hasn't been any of these. In fact, I never started making a game in the first place. I had no idea for a game...
For weeks I tried to think of some game to make. I struggled for so long that I made a half-baked game engine called Oak Engine. I tried to make a 2D tile editor but failed. I also tried to make another half-baked game engine and this time I called it Gilgamesh. I discovered that I was just stalling for time. I had no game idea and I knew it. And instead of trying to think of some game to make, I decided to spend my time making generic game engines and other tools. They were helpful still because I learned a lot from them but it wasn't what I was supposed to do. After finishing my last game Poly Shooter, which was just made to test SDL2, I struggled to find another game idea that suited my skill level. I'm not the best programmer out there, far from it. And I found out I had a deficiency called I-can't-draw-for-shit syndrome. My skill level in game development is average at best. I'm getting better. But I'm not there yet.
And this is why I struggle with game ideas. I have other game ideas that I want to make, sure. Game ideas that I think are fun. However, I don't even know where to begin with them. It's either a roguelike made in the style of DOOM or Wolfenstein3D. Maybe an investigation game where you play as the perceived murderer and try to get yourself out of the situation. Perhaps a tool where you can make procedurally generated landmasses. They're all ideas I had for a long time. They're all ideas I want to start working on at some point. But, for now, they're way too big for me and I am too small for them. And that, my friend (are you my friend?), is the reason why I procrastinated making games by making libraries and game engines for weeks instead.
The Idea
But I wouldn't be here without an idea for a game, wouldn't I? After weeks and weeks of struggling, I finally found that game idea. How did you find it you may ask. Well, in the bathroom, of course. As I was sitting in the toilet, emptying my bowels as the commoners say, I was stricken by what seemed like the hand of God. A revelation I call it. My mind took me back to when I was a wee lad (like 3 or 4 years ago). I remembered a game I played on my PS3. Actually, it wasn't the actual game, but, rather, a mini-game. A mini-game you'd play once and say, "That was fun. Now back to sniffing cocaine!" The game is simple and can be done by yours truly. That mini-game was inside Call Of Duty: Black Ops 1 and it was called Dead Ops Arcade. A 2.5D top-down take on the popular zombies mode. I played the shit out of it. I played it more than the multiplayer or the actual zombies mode. It was fun, addictive, and hard. The idea was to make COD Zombies but in 2D.
But the idea is already taken, isn't it? Activision already made the game. Also, Vampire Survivors is kind of like that, right? Am I trying to capitalize on the success of Vampire Survivors? Well, not really. Though I'm planning to play it, I confess I never played Vampire Survivors before. Most of the influence will be coming from Dead Ops Arcade since that's where I came across the idea in the first place. I will take some inspiration from other similar games, of course.
Except... there's one problem. When I got out of the bathroom (the birthplace of this idea) and went to my very expensive 2016, 4GB RAM, 500GB HDD Acer laptop to make a quick demo to test the game, I discovered something that every game developer has to discover in their journey of making games: the game wasn't fun. Well, in my case the game felt too similar to Dead Ops. While Dead Ops is my inspiration, I did not want to just rip the whole game, make it 2D, and call it a day. I wanted to make my own game. It should have the same satisfying feeling as Dead Ops, but it shouldn't be a one-to-one copy. And, unfortunately, it turned out that way. Despite the dead end, I still had faith in this idea and I wanted to keep going with it. I kept prototyping the shit out of the game. I tried different styles in order to see which one fit the feel I was going for. And, as I was prototyping the game, I found something that made me play the game non-stop every time I opened it, forgetting what I originally was trying to do. Clench your butt and listen closely because this is the best idea you ever heard of: COD Zombies but 2D in Medieval times. Instead of guns and grenades, you get swords, spears, and arrows. Instead of tactical gear, you get steel armor.
But how? How could I go from having no game ideas to a half-baked idea and finally to a concept that I can pursue. Is it by pure luck? Is it by the intervention of God? Is it because I went to the toilet. Well, it was none of these things. It was all thanks to prototyping.
My Experience With Prototyping
So far, I have not prototyped any game I have made before. Simply because every game that I made was just a copy of a classic game. And if it wasn't, then it was a very simple game to make. One that didn't require any thinking or planning. However, I wanted to change that. As I said before, I have an average skill level at making games. Still, I'm way better than the game developer I was a year ago. I wanted to be bold this time and make my own game. A game that I have to design and implement from scratch. A game I would call my darling. Perhaps that is why I struggled with getting an idea for a game so much, it's simply because I had never really done it before. I tried, of course, but I never seemed to push through the end.
When I got the first idea for this game I went ahead and decided to take the advice I heard from many game developers before: always prototype first. As I was setting everything up, I found myself thinking about the architecture of the game and the code style it's going to have. I thought about the art and the music. My mind was cluttered with things that did not matter for the time being. While thinking of these things, I got discouraged, slowing down my pace. I was thinking of the future too much and got overwhelmed. This is what happens every time. I think of a game to make, think of all of the things I want to add to it, get overwhelmed, and quit. Rinse and repeat. Since the beginning of my journey into game development, I had this issue. And I'm sure everyone went through this at some point or another. I don't know how folks get out of this rut but the way I got out of it was by just telling myself to only focus on the gameplay and nothing but the gameplay.
I remember a comment I saw on Reddit a long time ago. It was an advice given to someone who struggled with the same things as I did. I never remember the exact words but it went something like this: "If your game is not fun with just squares and circles, then your game will never be fun with sprites and music." To this day I still remember this comment. To me, it says, "To hell with all of the visuals and the audio! Just focus on the game."
Of course, aesthetics are always important, especially in games. But, at the end of the day, the most important thing when making a game is to make it fun. What's the point of a game if it's not fun? Even if it has beautiful harmonies and striking visuals? Look at all of the modern AAA games. Forsaken? Is that good? Destiny 2? Modern Assasin Creed games? All of these games have stunning graphics but they all have one thing in common: boring gameplay.
The only reason that I stuck with this idea and did not abandon it--like the others--is because I was having fun while I was prototyping it. If I had worried about the graphics, the audio, and the menus I would have not stuck with with it. Even if the prototyping phase takes months to finish, I'll still get to the other side with a good base and a half-complete game. Worrying about what technologies to use, the size of the sprites, the sounds to play, or the fonts to use will not make a game enjoyable. Testing different game ideas and trying to get the feel of the game right even with arbitrary primitive shapes and no sounds at all will make you understand your game more and, most importantly, make the marketing of the game easier since the game is way more defined than just a shallow 2D shooter or whatever.
The most important thing in prototyping that I found is to get the ideas out there quickly. Don't let something stall you or take away your focus from shaping the gameplay. Find the right tools to make the prototyping phase fast and efficient. You don't want to be testing only one thing, but multiple. You want the movement to be just the way you want it, the enemies should act just like you imagined, and the camera should be smooth just the way you like it. Even if you're stuck with some primitive shapes or shitty sprites for weeks or even months, you should still prototype as much as you can. Once you get the feel of the game right, you can move to the next stage and start to apply all of the striking visuals and orgasm-inducing music.
Keep testing ideas. If you don't like them, scrap them and add new ones. See what sticks and go with it. That's how I got the idea for making the game medieval. I got the idea, implemented it in the prototype, and absolutely loved it. I would have never done that with a fully-fledged game that had sprites and music already made for it. I would have either scraped the idea or scraped the entire game that I was working on for god knows how long.
And for the sake of being fast and efficient, I decided to use C99 with the Raylib game framework.
Why C99?
Before you ask why I'm making a game from scratch and not using a game engine, I would instruct you to read the first article I ever wrote. Go read it and then come back... or don't. You just need to know that I don't use game engines. Ok? Great. Let's move on.
Just a disclaimer, I will not write the whole game in C99 and Raylib. Instead, I'm going to use C++ with SDL2. But there are mainly two reasons why I'll use C99 for now. The first reason is for the sake of prototyping and iterating over ideas in an efficient manner. Why, you may ask. Well, simply, C compiles much, much faster than C++. And, as said before, with prototyping you need to iterate over ideas fast. Sometimes you have to tweak values with small increments or decrements in order to get just the right feeling out of a specific feature. With that in mind, if I had to tweak a value, compile the project, decide that the value needs to be tweaked again, exit, tweak, compile, and so on I would go insane. C++'s compile time is not the worst out there but compared to C it's abysmal. With C I can get the project to compile in a blink of an eye, while in C++ I have to wait for seconds or even minutes for the project to compile. Now, you might think that seconds is not that much time, which is true, in all other situations. However, with prototyping, it's not. Tweaking a value and getting just the right amount to be satisfied with it can take multiple compilations of a project. Seconds suddenly become horribly long.
The second reason for using C is the simplicity. With prototyping, I don't have to worry about the code architecture, the memory management, or the performance... all I care about is getting a demo up and running and nothing else. C provides just the right tools for that. At least it does for me. That doesn't mean C is a language purely for the sake of prototyping and nothing else, far from it. However, the way I intend to use it currently is for that reason. Until I have the guts to write a full game in C, prototyping in the language is all I'm going to use it for.
Current Progress and Plans
If I had to write a devlog about this from the beginning this would probably be devlog number 10. There are a lot of things that happened since the inception of the idea till now. I had to fight with my inner thoughts about a lot of things. I added and scraped features all the time. There were many experiments with this project that will probably never see the light of day. But what made me write a devlog now? Why not from the beginning? Well, simply, I didn't know if I would stick with the idea or not. I was determined and I loved the idea. However, the urge to get rid of it as soon as there was a bump in the road was strong as always. I wanted a green light to ensure that I was going to follow through with the project and not abandon it just like the hundreds of others.
Nonetheless, the prototyping phase of this game is steadily coming to an end. I just need to get a couple of things done and then it's on to writing the underlying engine that I will be interacting with throughout the development of this game. I will be writing devlogs every step of the way, of course. Not now, however. The next devlog after this will probably be about collision detection, which I absolutely LOVE... I hate it. I absolutely hate it.
On the other hand, when it comes to the plans I have a lot of small ones and not many big ones. The biggest goal is to get the game out of the oven. But there is a lot of overhead to that. There are a lot of things that need to be done before that goal can be reached. As for the smaller plans, there are plenty. Mainly, I want to get the engine up and going as quickly as possible since that is the most important part. But that won't be hard since I've done this kind of engine a hundred times before. There are, of course, some features that I've never implemented before such as an in-game shop, an equipping system, a heavy particle system, and so on. However, that is not a problem as these things are all technical and I'm pretty confident in my technical skills. They might take some time, as all technical things do, but they are doable, nonetheless.
And, as for the assets, I'm not worried about the music at all. I have a fondness for making sound effects and music of my own. And the game would have a fairly 16-bit feel to it. Essentially, making and getting the audio for this game won't be hard at all. However, the hard part (and the part I'm dreading the most) is the art. I have a very specific image of what the game would look like and I don't know if I would have to sacrifice that image or not. It's not the tiles that I'm worried about, it's just the sprites. The zombies, the player, the buildings... all of that jazz. These things I'll worry about later, though. I'm sure it's an issue that will come up in later posts... but for the time being I'll just focus on the gameplay and technical things.
Thanks for reading and huzzah!
Top comments (2)
I don't know how you're compiling C++, but it's certainly not as bad as you claim. That aside, why C99? The C language has moved on. C17 is the current standard.
It's just what I am familiar with. I used when I didn't know better and that's what I stuck with. But, as I said, I'll just use C++ moving. C was just for the prototyping phase. By the way, I use Clang for both C and C++ compilation.