The Artstyle

Not every developer has this problem, but I know a lot do: The inability to make good-looking art. Well, I have this same problem too.
A lot of times, I'll find myself getting stuck on making art for my game projects and getting burnt out through trying too hard to force myself to make good-looking art.

So, this time around, what I did instead of doing that all over again, I just decided to go with simple art instead. For example, as you can see, all the tiles in the world only have 8x8 pixels, and all of them follow a really simple pattern: The top and left side are slightly darker, giving the world a really tiled feel and making the levels seem like they were made with actual building bricks. As well as that, the character movement animations are really simple.

Both of those aren't even real animations per se, because what they really are is just the player's static texture rotating around a sin wave that is centered on the player's feet. It looks cute, though.

The Inner Workings

Whenever I write code, I tend to try to overoptimize it a lot. What I mean by that is that I think about systems that I want to implement too intricately sometimes. For instance, if I want to make a tile-based game, I obviously set up some data structures around tiles and how they're going to be ordered and stored on the map. But then, I'll also go and write a bunch of utility methods, conversion functions, figure out a really in-depth coordinate system for dynamic objects, and so on. And, honestly, for projects that aren't too big, all of that isn't really necessary.

What I did for this game instead is just kind of... let the code take me where it wants to. That may sound a bit ridiculous and performance-intensive, but it honestly works pretty well if you know what you're doing with the framework you're using. A lot of the code in this game is put together somewhat hackily. A lot of hard references to certain items and tile types (like how bombs can only turn grass into dirt and nothing else), a lot of messy utility functions all bunched together into a single class, very little documentation and abstract methods, hub interfaces for things that do similar things, and so on. But that's fine, because this isn't a huge project and I don't plan on adding complicated systems like a modding API or anything like that, so it'd be unnecessary to waste my time on doing something overly fancy.

For example, the map parsing system is really simple: It consists of an XML file, which stores all the important information about a map like its name and the positions that players spawn in, and a png file.

Each pixel in the file determines which tile will be put at its location. In this instance, black is deep water, blue is shallow water, yellow is sand and green is grass. And the cool thing is that this is really easy to deal with (reading pixels is a simple thing that's present in almost every game framework), because changing something on the map just takes an image editing program, no custom map editor needed.

The Gameplay

For some of the other games I've worked on, I've always had huge plans to start with. I had this one plan to make a big Animal Crossing-style game with real time progression, tons of NPCs, a lot of complicated gameplay mechanics. I'd worked on a game for over two years that was an open world sandbox, and it was supposed to have a huge story with optional, skippable elements, and... honestly, it's hard to actually make all that happen, at least for me. At some point, I just start looking at it from a different perspective and thinking to myself "Why did I take on such a huge project? This is impossible." and that makes me lose motivation.

So for Foe Frenzy, I went with a really simple concept that consists of a small amount of clearly definable main points:

Up to four players on a local computer, controlled by keyboard and gamepads
Predefined maps that the players can choose
Item spawners that spawn random items to battle or protect yourself with, where each of the items only lasts for a short time, so you have to keep going back and getting new ones
Kill all the other players to win

Because I had this clear plan in mind before starting the game, and because it's really not that much to do (I've been working on the game for a month, and all that's left to do is add more maps and more items to battle with), it's been easy to stay on track and stay focused rather than burning out because of responsibility overload.

So yea...

that's what I've been doing for the last month, and that's why my other projects have been suffering a little bit. But it's been really fun, and I might even have something to actually release as a real, finished game some time in the near-ish future. It's also been making me feel accomplished, because I've already been able to have my friends test the game out, and they say it's been fun which means that I already accomplished a big part of what I wanted to accomplish with this game.

Keep updated about the game on my Discord as well as my Twitter, and I hope you enjoyed reading about the game and my development process so far.

To finish off, here are some more pictures of the game for your enjoyment.

A cave being lit up by torches and lava. This is where a rubber hammer can spawn that you can use to knock the other players into the lava.

The map selection screen, where each player can choose the map that they'd like to play most.

The favorite item I've added so far: The flamethrower.

Killing the last person alive and winning

6.8 KiB Raw Blame History

The Artstyle

The Inner Workings

The Gameplay

So yea...

6.8 KiB

Raw Blame History