silenttowergames

[silenttowergames]

Tribulations of Engine Development: Part 1

It’s been a little while since there’s been a blog post here. A year and a half, actually. But given the title of this particular post... I’m sure you understand why.

A few releases have happened since the last blog post: 8-bit survival horror Retro Slasher, the subject of all of my previous posts; tile-based puzzle game Graveyard Ghoul!, in which you navigate a maze-like graveyard; and holiday slasher Krampusnacht, in which you fight off the titular goat devil who seeks to punish you for your misdeeds. (All of these are currently free if you claim them before August!) There’s also been a couple of free browser games, and some game jam projects.

However, most of my time spent on gamedev since then has been wrestling with the angels (demons?) of engine development. By now, my metaphorical hip has been broken. But daylight is breaking.

See, each release, whether a browser game or a Windows application, has been made with the intention of relying on outside software as little as possible. The browser games, like arcade shooter / meme cash-in Hog Assault, or satirical working class visual novel Job Application Simulator, have made minimal use of outside libraries, mostly just for basic web design stuff or playing sounds, while the game loop was completely custom. Other games have used Monogame for playing sounds & drawing graphics. One jam game used the Monogame-based Nez engine.

I finally intend, in this blog post, to acknowledge the elephant in the room here:

Why?!

Why make a custom game engine?

It is a completely unanswerable question.

And the answer is: control.

First, controlling the features & workflow. Many of the features I need (probably all) exist in most mainstream engines. However, engines all have unique strengths & weaknesses, as well as unique priorities.

For one thing, the most high-level programming language I’d like to use is C#, and I could see myself going as low-level as C. This narrows it down a lot already. Many engines, particularly ones that prioritize 2D, tend to use high-level scripting languages. This is a great thing, and the only reason you wouldn’t want this is if you’re developing a very complex game, or just don’t prefer scripting languages. But, I fall into that second category.

Also, with a custom engine, as I come up with new ways to improve my workflow, it can be made a reality as easily as taking a couple hours & making the functionality myself. Over the last year, I went from hand-typing animation data & tilemaps into my code, to using Tiled & ASEprite to export complete level maps & animated sprite sheets. If I wanted to keep this same freedom, I would need an engine that offered everything I currently need out of the box, or one that's easy to write plugins for (or ideally, both).

Secondly, financial control. This is probably a lot more important.

I can think of some engines that meet the above criteria very well, but either cost a lot of money out of pocket, or eventually cost royalties. If you’re a big & successful studio, these costs probably make sense. But when your budget is nearly $0, it simply can’t be done.

But you might be thinking, that doesn’t rule out every engine! Some are completely free and open-source, while others have ridiculously high thresholds before royalties start to kick in. So, I must finally concede the real reason, if there is one at all:

I enjoy engine development! It’s honestly one of my favorite parts of gamedev. I think it’s incredible that every game I make is created almost entirely out of words that I typed. Monogame itself is an open-source library, so if I wanted to change anything about it, or contribute to its development, I could. Even the tools I use, like Tiled and ASEprite, export XML or JSON code files that could’ve been hand-typed with enough patience.

Games are made of code. For many people, code isn’t so much the main event (and many of them are much better game developers than I will ever be, to be certain). But that’s just the way I’ve grown to look at it.

So, have I gotten anywhere with my engine?

Yes!

I have a finished, perfectly usable game engine right now. And I’ve successfully avoided many of the pitfalls I fell into last time.

But this post is way longer than I intended it to be, so I’ll write more about that in Part 2.

- Swan

@SilentTowerGame on Twitter

Silent Tower Games on itch.io

Silent Tower Games website

[silenttowergames]

On Restarts & Reanalyzing Scope

Retro Slasher has been in development for quite a while. It was officially announced on December 2nd, 2017. A lot has changed since then; it’s undergone aesthetic overhauls, engine re-writes, major design changes, etc. But now I’m officially announcing a release date of Tuesday, October 30th, 2018. Mark your calendar!

In other news: it has a revamped aesthetic, and a lot of the rogue-lite elements ended up being scrapped.

If you’d like to hear more about the journey, keep reading below.

Retro Slasher has been restarted several times in its development process.

Most recently, it was restarted in September, just last month.

A lot of design work was done, but the engine I made for it had bad bugs, and it wasn’t very flexible. The code was turning into a garbled mess, and despite my efforts to clean it up, it still felt more like digging through trash than engineering a solution.

It seems every restart has the same story: start, codebase turns bad, quit. The same few problems always seem to show up to complicate the code, as well. I struggled with what direction to take the gameplay in, in more than one way. From reconsidering the entire gameplay loop, to reconsidering how much of a rogue-like I wanted the game to be.

But now I’ve got an almost-complete game, and a set release date! It happened slower and more painfully than I anticipated, but it is the first release from Silent Tower Games (not counting game jams).

How is the game different from the original vision?

Today, Retro Slasher looks something like this:

But nearly a year ago, it looked like this:

I’m really confident in the changes that I made to the visual aesthetic.

First, I revamped almost all of the pixel art in some way. Cabins now have sides that make them look more like they’re made of logs; the trees look like thickets instead of arbitrary borders; paths look gravely; there’s more decoration in general.

Second, there’s a somewhat subtle post-effect that stretches the screen horizontally. I did this to imitate the subtle stretching that you would see in early 80s console and PC games. I thought it might look kind of bad, but now that I’ve done it I have a hard time looking back at the old screenshots!

Third, I added a transition to night time. I received the criticism that the game just doesn’t look scary. I agree, it doesn’t. So I wrote a shader that turns everything either dark blue, dark red, or black. Everything you need to see -- buildings, trees, paths -- is dark blue; grass, floors, and other things you don’t need to see are black; and to blood & the killer stand out as danger signals, I made them dark red. If you have the lantern item, you can see everything clearly within a certain radius.

How light is rogue-lite?

For this game, the answer turned out to be: very. According to the Berlin Interpretation, there are high-value and low-value factors that can determine whether or not your game is a rogue-like. Here are the high-value factors:

Random Environment Generation

Permadeath

Turn-based

Grid-based

Non-modal

Complexity

Resource Management

Hack ‘n Slash

Exploration & Discovery

Does Retro Slasher fit these points? Well, some of them.

You play in runs, so there is permadeath. The game is grid-based, being comprised of a grid of 8x8 tiles, though many objects in the game are more than one tile in size. It is non-modal, in that all of the gameplay happens in a single mode. The combat is more or less hack ‘n slash, though there’s only one enemy to be killed. Exploration & discovery are almost necessary to surviving.

I am hesitant though, as there are some other points that aren’t being fulfilled, at least strictly. Random environment generation is the factor most strongly associated with the genre, but while it was planned to be in the game, it has been almost entirely scaled back. There will be some randomly-placed items and obstacles, but the camp map will remain mostly the same from run to run. It isn’t turn-based; gamplay flows in real-time. I suppose you could say there’s an amount of complexity as defined here since there are multiple items with different capabilities, but I wouldn’t say it’s as elaborate as in a typical rogue-like. Resource management exists in that there are limited health packs and etc, but I feel like they probably mean something a little more elaborate than that.

So my conclusion on the matter is that Retro Slasher probably isn’t very rogue-like, so from here on out I’m retiring the term “rogue-lite” as a descriptor.

tl;dr

Retro Slasher has been entirely revamped with a much nicer-looking aesthetic; it’s not really a rogue-lite anymore; and it’s coming out Tuesday, October 30th, 2018!

- Swan Developer, Silent Tower Games

[silenttowergames]

Super Platformer RPG Postmortem (LD41)

Play Now | Ludum Dare page | Website | Source Code

Ludum Dare 41: Combine Two Incompatible Genres

On the night of April 20th, 2018, I did some work on my current game Retro Slasher for a few hours, and then went to bed. I was scrolling through Twitter on my phone before I went to sleep, when I saw a tweet about Ludum Dare. It had started about two hours before.

I had heard of Ludum Dare, but never participated. I was interested.

The theme also caught my eye: “combine two incompatible genres”. I had an idea! A platformer / turn-based RPG game had been rolling around in my head for a while, and I thought it fit pretty well. It could combine the best of both worlds, while also having a quirky oil-and-water separation between the two.

So I jumped out of bed and immediately got to work.

I decided to enter the competition rather than the jam. Its requirements are more strict: You get 48 hours rather than 72, you must be a solo dev, you must create all of the content new for the event, and you must release all your source code. I’m a solo developer, and since I’m trying to make it in indie games, I wanted to put myself to this test.

HTML5 + vanilla JavaScript

I decided to program the game in pure HTML5. I usually work with C# + MonoGame, but I don’t have a rapid-development engine available yet. I have experience with pure HTML5, however, and knew it would be much faster to get things going. Also, having your game playable in-browser makes it much more accessible.

For the record, I used howler.js for audio, since it makes everything much simpler. Outside of that, there were no libraries used.

Assets

I probably made the art in about 10 minutes. I am not a pixel artist, so I couldn’t have made anything much more complicated. I recently played the beautifully-simple Downwell, so I was feeling inspired by its 1-bit art style. (Despite the similarities between this game’s page and Downwell’s, I’ve never seen their site until this moment haha).

My game ended up being the 11th most-rated (note: most, not highest) compo entry this time around (peaking at 4th!). I think the pixel art was probably the reason why so many people played it. I got several compliments for it, and it was my second highest-rated category (next to humor).

In the audio department, there was no music. The sound effects all came from the incredibly helpful sfxr program.

Coverage

I watched a few streamers play my game in the days following the compo. There was even a Twitch meme made out of it! Possibly my proudest moment yet as a developer.

My game was also included in videos by Jupiter_Hadley and Ian Hinck of Easy Allies.

Major Criticisms

Between watching the streams and videos, and reading the comments, I discovered that there were a few major issues with the game:

The platforming is too difficult

The RPG elements aren’t very clear

The game is made up of two distinct genre sections, and both of them have glaring flaws!

The platforming not only requires lots of precision in your jumps, but the jump goes too fast to feel comfortable. I tried to prevent it from feeling spacey, but I went too far in the other direction. Then, there are the sections where the player goes off the top of the screen when you make certain jumps, so you can’t tell where you’re going to land sometimes.

To quote user Deprecat’s comment:

Players that enjoy hardcore platforming tend to prefer forgiving controls but brutal level designs.

I had it backwards. The level design was kind of hard, but it was really the harsh game physics that got you killed most of the time.

I experienced a wake-up call while watching streamers play:

What I found was that they didn’t finish the game. It’s a 5-minute game at most, but people kept dying at the same spots over and over because my jumps were just too harsh, so they quit. This is a fatal flaw.

As for the RPG elements, there was no in-game explanation for how things worked. Different options told you how much AP they had, and whether or not they had a cooldown, and that’s it. Most people thought the Psychic move would be some sort of magic attack, or after using it didn’t think it did anything at all. It actually reveals the enemy’s health bar at the cost of a turn, but clearly that wasn’t obvious beforehand, nor was it apparent to some players that the enemy health bar even showed up.

I put these things on the game page’s description, and Psychic showed that it had 0 AP, but this was not enough. If I could do things over, I would probably include a description box that tells you what each move does, and some sort of animation that shows the enemy’s health bar appearing.

Lesser Criticisms

Considering that I made the game in less than 48 hours, I’m proud of it. It’s a short proof-of-concept, so the following issues don’t ruin your 5-minute flash-in-the-pan experience as much as they would an hours-long investment. But if I move on with the project, these issues must be ironed out:

The game doesn’t advertise its controls to you. Heck, the description doesn’t either. I should’ve added some indication of the controls in the GUI. For the record, it’s arrow keys to move/jump and space bar to select attacks. Most people figured this out, so it’s alright, but that was a huge oversight on my part.

The RPG battle system has almost no balance. There were attempts: you level up, enemies get stronger, they roll a die to determine attack strength, your stronger attack has a cooldown, etc. But there’s no real strategy in selecting Jump until next turn when Hit is available. There’s no way to protect yourself from attacks, there’s no telling how powerful your enemy’s next attack is going to be -- it could be anywhere from 1 to 5 AP (or in some cases, even negative, thus giving you HP). And Psychic ended up being basically worthless, since missing even a single turn might cost you the battle.

Scores

After all this, how did I score? Well, I did... okay.

I did the math: my overall score is in about the top 40% (precisely, the top   39.379243453%). It isn’t a glamorous position, but it is better than most people in the compo did. 3.299 is above average, so I count myself lucky.

Surprisingly, Humor is my highest-rated category. There were a couple jokes in the dialogue, but I didn’t expect them to land very well. I guess it went over better than the gameplay did though, haha. (Also, nobody has yet pointed out a Star Fox reference in the dialogue, which makes me kind of disappointed).

I was really expecting the graphics to be my highest-rated category, considering that I got several compliments on that but not one on the humor, outside of one or two streamers mentioning it. No complaints here, though.

Conclusion

I put myself to the test, and I wouldn’t say I failed. I created a game in under 48 hours; a game which got me compliments in a few different areas. Realistically, it’s deeply flawed, but I’m aware and I’ll know not to make the same mistakes next time.

I’m looking forward to the next game jam! I think I’ll be able to make something even better.

Thanks for reading! Follow me on Tumblr for more dev blogs, visit the website, or on Twitter for regular updates on what I’m developing. Right now I’m working on Retro Slasher, an 8-bit rogue-lite survival horror. It also has its own Tumblr page and website.

[silenttowergames]

Retro Slasher’s Aesthetic

The concept for Retro Slasher is multi-part: it’s a rogue-lite action game where you must protect yourself and your fellow counselors from a mysterious killer; it’s based on campground slasher films of the 80s; and it looks and plays like a game from the early 80s would. In this post, I’ll be speaking to the third point.

First of all, why? While retro-style indie games are huge and have been for a long time, they’re usually done in the style of consoles from the third or fourth gaming generation (NES, Sega Genesis, etc). The second gaming generation -- Atari, Colecovision, Intellivision -- seems neglected. Which is a shame, since it brought us some of the most fundamental games in history.

Also, it fits the period. The most iconic campground slasher films are from the early 80s, so it would make sense for a campground slasher video game to be released on a second-gen console.

Secondly, we need rules. I’m obviously not following the original rules very strictly -- this game isn’t programmed in some decades-dead dialect of assembly, after all. So, what are the rules of this anachronistic aesthetic, and how did I arrive at them?

The priorities were simple:

Program it in whatever was comfortable and portable.

Use a 16:9 widescreen resolution. Most monitors these days are widescreen, and pretty much all TVs are. The in-game resolution can be any actual size, as long as it scales up to 1920x1080 comfortably.

Make the graphics look like they belong on an old console. They don’t need to follow the arbitrary hardware limitations of any particular console, but they do need to look like they belong at a glance.

Make it play like it belongs, too. Perhaps borrow & mutate some mechanics from some contemporary games.

With those priorities in mind, here’s the final ruleset for the aesthetic:

It’s programmed with C# and Monogame. C# is a lot faster and more powerful than something like GML, and generally easier to work with than C++. With Monogame, it’s portable to basically any PC, phone, or console. Also, it makes gamepad support easy! As a developer, I personally prefer working with my own code to learning an IDE like Game Maker or Unity. There’s nothing wrong with using either of those, it’s merely a preference thing.

The resolution I decided on was 240x135. In researching the resolutions of a few different contemporary consoles, I came up with widths of 160, 240, and 256. 160x90 would’ve just been too small; everything was crowded. 256x144 seemed just a little too large; too much free space. So I decided to settle in the middle with 240x135. It’s still possible to make some screens feel crowded, while others feel free and open.

The pixel art uses a small palette with each sprite being “one-bit”. As far as I know, the single-color-sprites rule isn’t an official rule of any contemporary console, but after looking at lots of Atari graphics, the games I most wanted to imitate seemed to have this as a de-facto rule. In Adventure, for instance, every object only consists of one color.

For dealing with the one-color limitation, objects use absence of color rather than another color. Characters’ eyes are transparent pixels; stray bits of hay can be seen hanging out of the bale because of empty spots; the definition in the lunch tables comes from empty space; etc.

Several core mechanics were inspired by contemporary or near-contemporary games. Rather than having a scrolling screen, walking to the edge of the screen moves the camera over a complete screen length, as seen in games like Adventure and The Legend of Zelda. You can only carry one item at a time, like in Adventure. Within seconds you can go from loading the game up to playing, like most games of that era.

In conclusion, the game’s aesthetic was made to feel like a second-gen console game, despite modern conveniences like release on modern platforms, a practical resolution, and support for keyboard and gamepad.

And it’s nearing completion! It’s been in development for a few months now, and the to-do list is getting smaller and smaller. No release date yet, but we’re coming up to that point soon. Follow the Retro Slasher twitter or the Silent Tower Games twitter for news regular updates.

Thanks for reading!

[silenttowergames]

Going Rogue(lite)

Retro Slasher is going to have rogue-like features! But what does that mean for this project?

For one, it means changing map layouts. Some of the important camp buildings -- cabins, the office, and the barn, for instance -- are going to be placed randomly each run. Important items can move, too.

For two, it means solidifying the “run” mechanic. The game’s original design was as a run-based, almost arcade-style horror game. The decision to include rogue-like features means we’re definitely going in that direction.

Other potential rogue-like mechanics you might see include changing AI traits, different items or buildings, etc.

Early in development, I was considering adding these features. I decided to write building placement in such a way that, if I did choose to implement them, I wouldn’t need to rewrite anything.

In the map creation code, I have a list of building objects, which accept a parameter for where on the map they should be placed. That parameter was originally hard-coded, but I took all of the values and put them in their own list, then wrote a function for removing and returning a random value from that list, and each building is now placed by calling that function.

It ended up only taking a few minutes to start placing the buildings randomly! There needed to be a few design touch-ups to make all of the spots fit all of the building types, but all in all it was fairly quick.

For more frequent news, check out the Retro Slasher twitter or the Silent Tower Games twitter.

[silenttowergames]

Framing Screens With Trees

So our game Retro Slasher takes place on a campground in the Great Outdoors. Trees surround the the map, and also frame many of the screens as well, helping guide the layout of the map.

This was also fun to code! It’s a tile map object you can place anywhere, with a modifier for each corner. You can set the number of trees in each corner to None, Some, or Lots. In the above screenshot, I have it placed over a screen that already has a partial tree border.

The above screen is a good demonstration: the top left has Some, the bottom left and top right corners have Lots, and the bottom right has None.

Building good tools is important! It saves so much time when adding one line of code can cut out a lot of repetitive work.

[silenttowergames]

You can collect items now!

So, we’ve been doing a lot of office renovations that have really tied up this project. But we’re now officially done! Here’s a GIF showing a working title screen, working buildings, and working item collection.

The game itself, titled Retro Slasher, is a survival horror of sorts, made to feel like a game from the early 80s. It’s based on the campground slasher theme that everybody knows and loves from the same era.

[silenttowergames]

Announcing: Retro Slasher

There’s a killer stalking the camp... do you have what it takes to survive?

Retro Slasher is an 8-bit horror game inspired by campground slasher films and video games from the second console generation.

You play as a counselor who has come to help set up camp, but plans are interrupted when a mysterious killer starts going on a rampage. You have to use the resources available to you to stop them before they kill you all!

The game is very early in development. Here are a few screenshots I have to offer so far.

As for technical details: it’s being developed in C# with MonoGame. Development is on Windows, with ports planned for Mac OS and Linux.

Follow for development news on Retro Slasher!