A Mind for Madness

Musings on art, philosophy, mathematics, and physics

Leave a comment

7DRL Dev Log Day 5

Today turned out well. I didn’t get trapped trying to fix some problematic C# syntax like in the past two days. The main improvements were to draw the final boss, get him animated, program his AI, and get the final room set up (which has different design structure than the rest of the labyrinth).

I did some balancing with the boss to figure out how much HP seemed reasonable for what level I thought an average person would be at. I also drew, animated, and designed an AI for a new NPC that will make an appearance later in the game. They are pretty tricky, so I imagine a bunch of deaths for people who dare to make an attempt at them.

The game feels reasonably complete at this point. There is a nice progression leading up to the final boss, and you win the game if you kill it. I made a push to get it to this point before today, because it turns out that tomorrow I’ll have almost no time to work on it at all.

I have two more significant additions I want to make, and then tons of polishing I can do (tons of extra animations, sound, balancing, bug finding and fixing, etc). Overall, I’m finding the game a bit too easy, but my alpha tester hasn’t beaten it yet, so who knows. If you know all the enemy patterns (like I do), then I think it is beatable pretty much every time with caution. I never came across an impossible situation today.

Tomorrow I’ll give a download of the most up-to-date version in case any readers want to volunteer a few playthroughs to give some feedback before the end of the last day.

Leave a comment

7DRL Dev Log Day 4

Today I’ve put in some more details, but I still haven’t gotten around to programming the final fight, so the game technically goes on forever right now. I plan to do that first thing tomorrow.

I added another weapon and a bunch more items, which will be one of the main things that keep repeated plays interesting. The weapon was a spear (technically a bident) which can damage enemies at range.

I’ll keep the items a mystery, but I will say that items all have positive effects. This choice came from two places. The first is that in a “one HP” roguelike, you cannot have much by way of negative effects without causing an unfair death.

The second is that I really want everything identifiable on sight, because part of the strategy is to make hard choices about what to use and what to keep. You have a weapon slot and a spacebar item slot (in my head these correspond to what you hold in your two hands).

Since the maze has no backtracking, you can’t bring two really good items with you. Items are fairly sparse, which I like. The game should be beatable without any, so finding something will make the run more enjoyable and safer.

I also implemented the dragon I drew last time into the game. Again, today’s changes were mostly behind the scenes, so there isn’t really a screenshot that helps you see what has happened. Instead, I’ll post a video with sample gameplay.

Don’t watch if you want to experience it yourself. I’ve gotten a lot of standard movement patterns down after playing it a bunch, so I might spoil how to handle lots of situations.

Leave a comment

7DRL Dev Log Day 3

Yesterday I got through the hardest coding section of the game. I separated out the zone logic into it’s own class, so I could make repeat calls and chain together the zones to make a large labyrinth.

I also implemented experience points, level up, more of the GUI, and fixed many of the bugs I had from day one like spawining in an instant death situation, enemies occupying the same square, and a permanent stun effect.

Also, there is an annoying bug where the game crashes if I put sound in it on some machines (maybe it is just Windows 7?). I may end up not doing sound and music to be safe.

Most of these changes were under the hood, so it doesn’t look much different right now:


Today I got hung up on a few technicalities with C#. I guess I should have practiced some basics more before this week to avoid wasting time. Apparently, when you iterate through a list, you can only read the objects you iterate over (you can’t set them to new values). This caused lots of confusion for a bit while I tried to work out what was wrong.

I had a pretty good day. I realized lots of stuff was hard to see/read with the fancy vector swept background. I’m not sure I like what I’ve switched to, but it is certainly better from a readability standpoint, and makes the various sprites pop a lot more:


Other than that, I did a lot of art again. I added some items and a new weapon. This meant drawing the various places the item could be, and then redoing the main character sprite with the new weapon in its various positions. The weapon has a pretty cool mechanic attached: it is a damage multiplier, so super over-powered, but it is heavy, so it costs a turn to turn around while holding it. This drawback may make it too risky to be worth it putting in an interesting choice.

I also completed a new enemy, a dragon. It is the best thing I’ve ever made with pixel art (I only started learning a few weeks ago):


I animated him by just bobbing up and down and breathing fire so that I wouldn’t have to deal with the intricacies of moving the wings. It’s coming together and finally feels like a real game.

1 Comment

7DRL Dev Log Day 1

Today the 7DRL began (for me at least)!

I got through everything I wanted to with time to spare. I mostly built the art today and got some stuff displayed. I settled on a 960×545 window (unchangeable, because I don’t want to deal with scaling at the moment) with each segment of the maze being a 40×20 grid of 64×64 tiles. Once you leave a segment, the previous part will change.

Today I drew the title screen, a “lose” screen, a “win” screen, the background, 3 wall tiles, 3 floor tiles, a fire elemental enemy, a raven enemy, and some of the GUI (health, weapon, and item get displayed).

Here’s two screen shots:



Both of the enemy types are fully animated, but the fire could use some work later if there is time. I’ve implemented movement patterns for the two enemies, and trigger win/lose conditions if you clear the area (not the real win condition, just testing!) or die.

Overall, this was a wildly successful day, but all of the hard coding is ahead of me, not to mention, I’ve only thought of one weapon and one item so far.

Leave a comment

Mistakes From My First Game

We’re headed into the #7DRL Challenge. Last post I described what I was going to make, how I was going to make it, and what I hoped to get out of it. Today I want to describe things that were done terribly in my first game that I hope to do better this time.

I’ve seen a few of these posts popping up. They mostly say things like, “I tried to do too much,” or “I tried to put non-essential things in before the core was done.” I don’t want to get into any of those vague issues. I actually want to get into some hardcore implementation errors I made.

I’m going to use the term “game engine,” so I want to make sure people understand what that means in this context. Roughly speaking a game is a finite state machine simulation that either live updates at a certain rate or updates upon user input. The engine refers to the main pieces that loop to make that machine continue.

To big game developers, there’s probably a lot more parts (like preprocessing the 3D animation pipeline, etc), but for my 7DRL it consists of initializing/loading the pixel art and starting statistics, an update loop, and a draw loop. The way the monogame engine works is that the draw loop will attempt to be called at a fixed fps (I’d guess 60 is default, but have never looked it up).

The update loop is always called at that base fps. User input is captured in a queue and then handled in the update loop. For example, if the player presses the up arrow, the update loop catches this by going through a bunch of if statements. One of those will be “if user presses up: increase the y-position by 1″ (actually decrease due to how the screen coordinates go, but let’s not get into that). Then since the draw is independently updated with the most current positions of everything, the avatar will move.

All of this goes on forever unless something causes the big game engine loop to break (e.g. “if player health <= 0: break"). This brings me to my first error. I thought that because my game was turn-based, i.e. nothing on the screen would move or update until the player pressed a key, I didn't have to separate the update logic from the draw logic and I didn’t have to call either until the queue caught new user input.

This is a pretty big error. This meant that my entire engine stalled until the player pressed a key. It didn't cause any issues in the game per say, but it is very bad form. You need at least one moving part, some people would say two, at all times. What if you wanted to implement something that relied on real time and not just game time? What if you wanted to have a resting animation for the sprite? The ways in which this limits the creator are endless, and it is sort of hard to see until you make the mistake yourself and try to expand the game.

Also, keeping the draw and update loop separate is very important when graphics are involved. For example, if you have a lot of processing power needed to render your 3D animations, then you might need to drop frames to prevent lag. If the loops were tied together, then the game engine itself will experience lag and maybe even miss user input. If they are separate, the animation loop is free to lag without the rest of the engine lagging.

My next set of mistakes were object-oriented ones. My hierarchy of objects was poorly designed. Actually, there was no hierarchy. This caused excessive amounts of repeated code. The player had a position, health, attack damage, attack method, takeDamage method, and so on. The enemies did, too. I should have made a superclass with those attributes and methods from which both could inherit.

A related mistake was that I broke encapsulation … a lot. Because I had all these separate objects that needed to know about all the other objects and alter them, I kept passing all these raw values around and changing them. This is very bad, and caused many headaches when something went wrong. A few times I had trouble tracking down how a particular value changed in an incorrect way, because everything had permission to change everything.

I should have made a well-planned, clean hierarchy, and then let the main engine handle making all of the updates and changes that needed to happen.

The last thing I want to talk about is a little subtle. The object-oriented approach at first glance seems well suited for this type of finite state machine. You have a bunch of instances of enemies, each have a bunch of attributes, and the changing of these is essentially the game.

For a small scale project this is fine. What you will find as your game gets more and more diverse is that your hierarchies will get out of control. If you subclass every time there is a split, you will end up with insane code: new Character.Enemy.EnemiesThatFly.FireEnemy.NoMagicSkills….

I know you're thinking that these were just poorly chosen subclasses. It is an art to balance when to subclass. Many of these could be combined, and then leave an attribute null or unused when that particular enemy doesn't use the attribute. But remember, we're talking about a large scale game with lots of diversity.

It is a simple application of the pigeonhole principle that your unused attributes will also get out of control if you don’t subclass enough. This isn't good either. There is simply no way to create a set of well-balanced classes in a pure hierarchy once the attribute size gets large enough.

There is another way! It is called an Entity Component System (ECS). Instead of thinking in terms of objects, think in terms of the components. One component might be health. So you pull this out into a struct or class that has the health attributes and methods (not to mention, if you make your components structs of integers, you can work on the stack which will speed up CPU time rather than allocating on the heap with those classes).

Now everything in the entire game is an Entity, and you make an Entity Interface to interact with these components. Usually people will tag each Entity upon creation with a unique ID. This turns the game machine from updating a bunch of abstract, separate instances of classes to something more like updating a database.

Not only does this provide a cleaner approach from a coding standpoint, but it also makes many things easier. For example, in an RPG, maybe you have an ice spell that only affects flying enemies that are fire based (see subclass issues example above). It could be hard to find these if you've been instantiating them in the level at random and just have a big array of instances of enemies.

With the ECS framework you can query all Entities where the flying and fire based components are set to True. Or maybe you have a weapon which damages the wings of a flying enemy and it no longer possesses the special qualities of a flying enemy. Would you take the same enemy and create a whole new instance of a whole new class to do that? It would no longer be the "same" enemy in the code.

Again. This is really subtle, and probably is hard to tell why it works better from just thinking about it. You have to try the other way first to see what a pain it is to realize why the ECS framework simplifies this.

Since the 7DRL is under such tight time pressure, I'm not going to try a whole new coding framework for the first time during it. But I think I'll try to implement a hybrid OO/ECS approach whenever some obvious component jumps out at me.

Starting Saturday, you can expect this blog to turn into a Dev Log of the game. Hope to see you there.

1 Comment

7DRL Pre-Challenge Post

I’ll be blogging about my progress in the 7DRL Challenge, but I don’t want to waste time during that week posting all the stuff in this post which can be done now. If you don’t recall what a roguelike is why you should play them, see these posts: Why Play Roguelikes? and Thoughts on Permadeath. If you are interested in this challenge, there is still time to pull it together! The week is March 7-15.

Where I’m Starting:

Part of the rules of the 7DRL Challenge allows you to use generic pre-existing graphics/algorithms/game engines/etc. To be fair to the finished game, you should cite these sources. Here’s what I’m starting from (for why, see the sections below).

I’m building the game in C# through the XNA/Monogame framework and using a module called RogueSharp designed for making roguelikes in C#. The main use will be data storage and drawing of the level. For a generic template to start from, I’ve gone through this tutorial. My game will take this sample game and (radically) modify it.

See the section Core Idea for how I plan to build my own map generation if there is time. If there is not time, RogueSharp also has a built in algorithm I will use. As for graphics, I’ve spent some time playing with pixel art and learning to do animation in Monogame.

I will redo every one of these during the 7DRL week, but I needed some practice so that I wasn’t going in both learning to do pixel art and creating the sprites on top of programming the whole game. This seems fair, because anyone that has done any art for a previous game will go in with more experience than the couple weeks of practice I got from this.


My game will be a traditional grid based movement (only up, down, left, right) and turn based (the enemies don’t move until you do).

I’m choosing to make the game a variant on the “One HP Model.” A pure one HP mechanic says that everything in the game has one hit before they die. This includes you. This makes the game similar to a game of chess. If you move a piece to where another piece is, this “attacks” and the other piece dies.

This turns the game into one of strategic positioning. As more and more enemies appear with various movement patterns, you must figure out places to stand where you will not be killed and a good order to kill the enemies.

Each game will basically be a sequence of increasingly difficult, randomly generated puzzles to solve (so it is completely different every time). Part of the initial fun is that you must work out what the AI movement patterns are for each type of enemy.

I will use a variant on this model that allows certain items to increase your health which will allow you to take two hits (I probably won’t go above two though to keep the pressure on). Also, most enemies will have more than one HP, but various weapons will still let you kill them with one hit. The details have yet to be worked out.

Core Idea:

The core story idea is Theseus in the labyrinth who must find his way to the center to kill the Minotaur. I would like to implement a system where backtracking is impossible. In modern interpretations of the labyrinth, the surrounding area constantly changes. This seems like an interesting procedural generation problem and adds a layer of difficulty to the gameplay since you can’t just leave something laying around to go back for.

I want there to be a punishment for running instead of “solving the puzzle” and killing all the enemies, but I also want the game to be winnable if you do this a few times. This will be a delicate balance that may not get worked out in a week. One easy punishment is to have a basic leveling system.

If you don’t kill the enemies, you don’t get the experience to level up and get stronger. This means that maybe later you need to hit some enemy a few more times making the strategy more complicated. The labyrinth design will also help balance this by not allowing the player to skip something too hard until they are stronger to go back to it.

I also want there to be time pressure. The game would become too easy if you could indefinitely re-position until you get a line of enemies to take out one at a time. There will not be a “hunger clock,” but I won’t spoil how this will be done right now.

What I Hope to Get From 7DRL:

I made a 7DRL before (well, it wasn’t done during the 7DRL or over the course of 7 days, but it is similar in size and scope). I built all the algorithms, data management, procedural generation, game engine, and everything from scratch. I did this to learn how all these pieces worked and interacted together.

I’m proud of the end result, but it isn’t very pretty. I used standard ASCII characters for graphics and made lots of stuff way too slow and clunky. I used python and pygame to do it. This caused lots of distribution issues because of dependencies and python versions.

Because I’ve done the inner workings before, this time I want to focus on some other aspects. I have no problem relying on a pre-built engine (monogame plus the tutorial), pre-built algorithms (RogueSharp), and so on. I want to get graphics, animation, and sound into the game. These are all things that were wholly neglected last time.

Rough Plan:

Day 1: Get a level displayed, redraw some sprites and get those displayed. Best case scenario, I can move through the level and once I’ve cleared the enemies I trigger the win condition.

Day 2: Solve the labyrinth procedural generation problem (i.e. put in multiple “levels”).

Day 3: Items, armor, weapons.

Day 4: Put in the rest of the enemies and start tweaking movement patterns.

Day 5: Catch up on days 1-4. If there is time, make a start screen, win screen, lose screen. Play for balance issues.

Day 6: Sound + animation.

Day 7: Debug + balance.

Most days I’ll try to update progress on this blog. On Day 5, I’ll probably want other play testers if you are interested in giving feedback.

1 Comment

On Modern Censorship

I don’t want to wade into the heavy politics of things like GamerGate, MetalGate, and so on, but those movements certainly got me thinking about these issues a few months ago. A few days ago, I read a New York Times article about twitter shaming people out of their careers over basically nothing. This brought some clarity to my thoughts on the issue.

I’ll try to keep examples abstract, at the cost of readability, to not spur the wrath of either side. I haven’t done a post on ethics in a while, and this is an interesting and difficult subject.

First, let me say there are clear cases where censorship is good. For example, children should not be allowed to watch pornography (of course, there could be a dispute over the age where this becomes blurry, but everyone has an age where it is too young). There are also clear cases where censorship is bad. For example, a group of concerned Christian parents succeeds in a petition to ban Harry Potter from their children’s school.

Many arguments about censorship boil down to this question of societal harm. To start our thought experiment, let’s get rid of that complication and assume that whatever work is in question is fine. In other words, we will assume that censorship is bad in the sense that the marketplace of ideas should be free. If something offends you, then don’t engage with it. You shouldn’t go out of your way to make it so no one can engage with it.

In the recent controversies, there has been an underlying meta-dialogue that goes something like this:

Person A: If you don’t like the sexism/racism/homophobia/etc (SRHE) in this game/book/movie/etc (GBME), then don’t get the media. Stop trying to censor it so that I can’t engage with it. I happen to enjoy it.

Person B: I’m not trying to censor anything. I’m just raising social awareness as to the SRHE. It is through media that these types of things are perpetuated, and the first step to lessen this is to raise awareness.

What made this issue so difficult for me is that I understand both points of view. Person A is reiterating the idea that if you don’t like something, then don’t engage with it. There is no need to ruin it for everyone else. It is also hard to argue with Person B if they are sincere. Maybe they agree that censorship is bad, but they want to raise awareness as to why they don’t like the media in question.

The main point of this post is to present a thought experiment where Person B is clearly in the wrong. The reason to do this is that I think the discussion often misses a vital point: in our modern age of twitter storms and online petitions, Person B can commit what might be called “negligent censorship.” Just like in law, negligence is not an excuse that absolves you of the ethical consequences of censoring something.

Thought experiment: Small Company starts making its GBME. In order to fund the project, they get the support of Large Company that is well-known for its progressive values. In the age of the internet, news of this new GBME circulates early.

Person B happens to be a prominent blogger and notices some SRHE in the GBME. Note, for the purposes of this discussion, it doesn’t really matter whether the SRHE is real or imagined (though, full disclosure, I personally believe that people whose job it is to sniff out SRHE in media tend to exaggerate [possibly subconsciously] SRHE to find it where it maybe doesn’t really exist).

Let’s make this very clear cut. Person B knows that they can throw their weight around enough to get a big enough twitter storm to scare the Large Company backer out of funding the Small Company’s project. Person B does this, and sure enough, the project collapses and never gets finished or released.

This is clear censorship. Person B acted with the intent to squash the GBME. Sadly, Person B can still claim the nobler argument given earlier, and it is hard to argue against that. I think this is part of what infuriates Person A so much. You can’t prove their interior motivation was malicious.

But I think you don’t need to. Now let’s assume Person B does all of this with the good-natured intention of merely “raising awareness.” The same outcome occurs. Your intent shouldn’t matter, because your actions led to the censorship (and also hurt the livelihood of some people which has its own set of moral issues).

If you write something false about someone that leads to their harm, even if you didn’t realize it, you can still be charged with libel. Negligence is not an excuse. I’m not saying it is a crime to do what Person B did (for example, the SRHE may actually be there so the statements Person B made were true). I’m only making an analogy for thinking about negligence.

You can claim you only were trying to raise awareness, but I claim that you are ethically still responsible. This is especially true now that we’ve seen this happen in real life many times. If Person B is an adult, they should know writing such things often has this effect.

To summarize, if you find yourself on Person B’s side a lot, try to get inside the head of Small Company for a second. Whether intended or not, Person B caused their collapse. It is not an excuse to say Small Company should have been more sensitive to the SRHE in their GBME if they wanted to stay afloat.

This is blaming the victim. If Large Company said upfront they wouldn’t back the project if Small Company made their proposed GBME, it would be Small Company’s fault for taking the risk. If a group of people who don’t agree with the content of the GBME cause it to collapse, it is (possibly negligent) censorship.

Under our assumption that censorship is bad, I think Person B has serious ethical issues and Person A is clearly in the right. The problem is that in real life, Person B tries to absolve their wrong by implicitly appealing to a utilitarian argument.

A (non-malicious) Person B will truly believe that the short term harm of censoring is outbalanced by the long-term good of fighting SRHE. If the evidence was perfectly clear about the causation/correlation between SRHE in mass media and real life, Person B would have a pretty good ethical argument for their position.

What makes this such a contested issue is that we are in some middle ground. There is correlation, which may or may not be significant. But who knows about causation. Maybe it is the other way around. The SRHE in society is coming out in art, because it is present in society: not the other way around that Person B claims.

This is why, even though, with my progressive values, I am highly sympathetic to the arguments and sentiments of Person B, I have to side with Person A most of the time. Person B has a moral responsibility to make sure they raise awareness in a way that does not accidentally lead to censorship. This has become an almost impossible task with our scandal obsessed social media.

For the debates to calm down a bit, I think side B has to understand side A a bit better. I think most people on side A understand the concerns of side B, but they just don’t buy the argument. Many prominent speakers on side B dismiss side A as a bunch of immature white boys who don’t understand their media has SRHE in it. Side B needs to realize that there is a complicated ethical argument against their side, even if it rarely gets articulated.

I’m obviously not calling for self-censorship (which is always the catch-22 of speaking about these issues), but being a public figure comes with certain responsibilities. Here are the types of things I think a prominent writer on SRHE issues should think more critically about before writing:

1. Do I influence a lot of people’s opinion about SRHE topics? For example, having 200K twitter followers might count here.
2. Do my readers expect me to point out SRHE in GBME on a regular basis? If so, you might be biased towards finding it. Ask someone familiar with the GBME whether you are taking clips or quotes out of context to strengthen your claims before making a public accusation.
3. Are my words merely bringing awareness to an issue, or am I also making a call to action to censor the GBME?


Get every new post delivered to your Inbox.

Join 233 other followers