Games I Created
I've been making video games for what feels like a really long time! Sometimes I make games in a few hours, and sometimes I make them over a few years.
Websites I Designed
Articles I scribbled
Centuries after a mysterious cataclysm tore the world apart, humans have taken to the skies - ferrying their kin in airships, searching the remains for artifacts and survivors. Explorer Névoa ventures out across uncharted islands, left floating in the sky. Alone and armed only with a shovel, she is determined to carve her own path.
A hardcore platformer game I created with Matt Thorson in 4 days with PICO-8.
A game I made with a bunch of awesome people for Ludum Dare!
Kiki and the Monster
A game created in 48 hours with Amora and Pedro of Miniboss doing art, and Alec doing music. Thanks to Matt for design help. FullIndie Jam, 2013. Inspired by the SNES games Pocky and Rocky.
If you have 2 xbox controllers, definitely give co-op a try!
You will need the XNA redistributable installed to play.
A game I created for Adult Swim Games, about a Drunken Assassin who has to hunt down Aliens. It's pretty ridiculous, and was fun to make.
Alec Holowka wrote all the rad music!
Created with my friend Connor Ullmann, Prism Panic is a platformer about overlapping worlds with holes between them. Each world has different mirrored traits, creating some interesting puzzles and platforming. Was a lot of fun to make. The music was done by Liam Berry, with a single boss battle theme by Alec Holowka
Broken Robot Love
Broken Robot Love is a game I started creating at a game jam in Winnipeg, about a little robot that is seeking his human companion. It's a crazy puzzle platformer revolving around a block-placing, time-warping, mechanic. Adult Swim describes it as "One brave robot is determined to return to his ungrateful human owner. Scale lava pits, leap across cliffs, and manipulate lasers in this heartfelt robotic journey."
So yeah, check it out and tell me what you think!
A game I created alongside awesome indie developer Chevy Ray at the FullIndie game jam in Vancouver. We made the game in 48 hours. It’s like some kind of crazy 9-games-in-one retro arcade game. Or something. You sort of just have to play it. The game is pretty trippy, so if you don’t like flashing lights, you probably should not play this.
The music is all by the awesome band RYMDKRAFT. You should definitely go buy the album.
Sound effects were by Kevin Regamey, and he did a totally amazing job with 'em.
A game created in 48 hours for Ludum Dare 22, about a cloned astronaut stuck alone on a space station, trying to escape. Very simplistic game at this point, but I fully intend to develop it further over time and add more levels and mechanics.
The game ended up getting 2nd Place out of over 700 games in the competition.
This is a game I created along with Alec Holowka, Paul Veer, and Tavit Geudelekian. We created this game for Incubus when they released their latest album. They were looking for a game to go along with the release, so we were hired by KillScreen to make it.
It was a pretty awesome experience, and the game turned out pretty well for the very short time span we had (just under a month).
Copyright 2011 Sony Music Entertainment.
Reach For It
A game I created for the Ludum Dare 21 competition. A 48 hour competition, where the goal is to make a game by yourself in just 2 days. Was really fun, and the first time I was actually able to complete the compeition!
A quick game I made in a day - mostly just porting my older game, The Plunge, to flash. However, I did make a few changes here and there.
Leap 4 Blue
Pixel Runner 2
Pixel Runner 2 is a remake of one of my older games, Pixel Runner (which you can see on the games page). Pixel Runner 2 is being created in Flash using the Flash Punk Library, Flash Develop, and AS3. The general idea of the game is stay alive for as long as you can without being hit by all of the enemies and objects that fly/move around you.
The Plunge is a small arcade game I made in a few days. The goal of the game is to go as deep into an endless tunnel, collecting as many gold stones as you can, while avoiding rocks and the tunnel walls.
Pixel Switch is a small game with 12 levels I created in 2 days. The thing about the game is that you can't jump. Instead you are able to flip the gravity 180 degrees at any time by pressing X.
Coincidentally, this game is pretty similar to Terry Cavanagh's VVVVVV (which is way better and you should all go check out if you haven't)
Red n Blue
Red 'N Blue is a platform puzzle game, where you control two players, but only one at a time. You must get both Red and Blue to the Green exit door, avoiding traps, hazards, etc. The game has a bit of a twist, to make the game a little more challenging. Red cannot touch anything Blue, other than Blue himself, and Blue cannot touch anything Red, other than Red herself.
Agoss is a simplistic abstract shooter in which you control a little ball, out to shoot all the crazy shapes that are flying towards it. The game contains 4 different types of enemies (although they all basically look the same), and weird art
My brother, Liam and I made this game over about 3 or 4 months for a Game Maker competition. At the time it was by far the most polished game we had made. Pretty proud of it at the time. I think we were 13 and 15 when we made it. Liam made all the art and music, and I programemed it. Fun times.
Zymo is a little game where you type commands in to make the player do varous things. It was a fun experiment. One of my earlier games.
Pixel Runner was originally created for a 3 hour competition, meaning the game was created in just 3 hours. You basically run around and try to dodge the different objects and hazards that come running at you. I got some great responses to this simplistic game, and I was quite proud of it when I first created it in 2008.
- 256 x 224 px screen size. Technically 256 x 240, but the top and bottom 8px are cropped
- Composed of 2 layers: Background Tiles and Sprites
- Access to 2 sets of 256, 8 x 8 tiles (so 2 textures of 128 x 128px). Usually one is used for Background Tiles, and one is used for Sprites.
- Refresh rate of 60 Hz
Palettes / Colors
- The NES has access to 64 different colors that can be used throughout the game
- A total of 8 palettes can be used at once
- 4 palettes are used for the Background Tiles. Each palette is composed of 3 colors, plus a common single background color shared between all 4 palettes
- 4 palettes are used for the Sprites. Each palette is composed of 3 colors, plus transparency
- Total Colors onscreen: 25 (4 palettes x 3 colors = 12 for sprites, 4 palettes x 3 colors = 12 for background tiles, 1 for background)
- Palettes can be swapped on the fly (many games use this for cool fade in/out effects, etc)
- 8 x 8 pixels in size
- Snapped to an 8 x 8 grid (can't move freely, basically)
- Every tile can only use 1 palette
- Every block of 2 x 2 tiles must use the same palette.
For example, tiles (0,0), (1, 0), (0, 1), (1, 1) must share the same palette
- The NES has access to 256 individual tiles at a time
(think of a texture that is 128 x 128, split into 8 x 8 tiles)
- Background tiles can not be flipped, rotated, or scaled
- Sprites can move around and are not snapped to the grid
- There are 2 Sprite Modes: 8 x 8 or 8 x 16. Your game may only use 1 mode.
- The game has access to 256 sprites (think of a texture that is 128 x 128, split into 8 x 8 tiles)
- Note on 8 x 16 Mode
In 8 x 16 Sprite mode, the game only has access to 128 sprites (the size of the sprite texture does not change). Every second tile in the texture is used along with the first one, 8px below it. For example, if you draw Sprite, it will draw Sprite and also draw Sprite 8 pixels below it. You MUST only draw even sprites (so Sprite+Sprite, never Sprite+Sprite)=========================================================
- Each sprite can only use 1 palette (but you can overlap multiple sprites with transparency, ex. Megaman)
- You can only have 64 sprites on the screen at once
- You can only have 8 sprites per scaleline at once. What this means is that if more than 8 sprites are drawn on a horizontal line of pixels across the screen (a scanline), only 8 can be visible. Transparent pixels count.
- Sprites can be flipped horizontally and/or vertically, but can not be rotated or scaled
Things this doesn't cover
- Memory. The NES has relatively limited memory and how things moved, saved, etc were heavily influenced by that.
- "Hacks" that programmers could do, like swapping pixels mid-render
- Probably a bunch of other small stuff
- PPU: The Picture Processing Unit used in the NES
- Way Of the Pixel: A good forum post containing basically all the same stuff, just not in point-form
- Way Of the Pixel: Another good post by the same author regarding background tiles
- NES Palette
- NES palette generator
If I missed anything (or something is wrong) let me know!
Procedural Generation - The Dungeons
THE RUNDOWNThe goal of this generation (as seen above) is to create a bunch of interconnecting rooms that the player can traverse. All the rooms are either a pre-designed level, or simply a rectangle of a random size. The placing of the rooms is completely random, and the tunnels are then dug between each room in a circular fasion, trying to stay on already-existing paths.
Step 1: The Map
The very first thing to do is create your map, and fill it up with Wall tiles. In my case, there are 3 types of tiles: Floor, Wall, Stone. Each of these will be explained later, but basically each one should be an integer value of some cost (I had Floor = 1, Wall = 4, Stone = 20). My Map is then a 2D integer array of these.
Step 2: Place Random Rooms
Okay, next we choose some number of rooms to place. This generally depends on the size of your map, and the min / max size of the rooms you can place. Once you’ve decided how many rooms to place, and how big and small they can be, you can begin placing rooms. Attempting to place a room essentially means you’re checking to make sure the random area you selected does not contain any floor tiles already. To do that, you simply check the area that you’re going to be placing the room (a rectangle) in your 2D map array and make sure it doesn’t contain any floor tiles (in this case, positions in your array containing a 1). I also had template rooms, that were pre-designed rooms. Whenever attempting to place a room, the generator would decide to either place a normal rectangle room or a predesigned room.
Note that each rectangular area of the room is stored in an array of rectangles, for later use (just so we know where the rooms are).
Once you’ve found a clean area of Walls to place your room, you dig it out with floor tiles. Now, here’s where things get a bit interesting. I decided to place a border of Stone Tiles around the room once it’s placed. If you noticed before, Stone has a higher integer value than both Floors and Walls. The reason I do this is because I want to make it so when tunnels dig themselves they avoid going directly through a room as much as possible, to keep the general shape of the room. However, I do leave a few gaps in the stone to act as “doors”, or easy places for the tunnels to go through. Here’s what a general room looks like:
Okay, cool! Now, after all the rooms are placed, we should have something like this (note: some rooms look a bit odd because I have some template rooms that get randomly placed, too)
So, we have a bunch of rooms sitting around and things are feeling pretty good, right? Well, let’s toss some tunnels in there. There’s a bunch of ways to do this. You could make little miners that move from one room to the next, and just avoid Stone tiles as much as possible, or something. But, in my case, I decided to use A* pathfinding, using the costs I described above. I’m not going to get into the details of A*, so here’s a really great explanation that I used to learn it.
Specifically, tunnels are dug from the center of one room, to the center of the next. Once a path has been found, the given tiles in the path are turned into floor. Note, that the tunnel is dug out from the map BEFORE we do the next pathfind. This way, other tunnels will often follow the path of already existing tunnels, instead of doing their own thing.
Also note, that in my actual code, once a path is found, I will choose a random SIZE for the tunnel. The size in this case is only 1 or 2 tiles, but basically it digs out the tunnel larger than the actual original path (adding some random variance and makes things look more organic).
The order the tunnels are dug just starts from the first room in the rooms array (referenced in the note in step 2) to the next room in the array, and so on, until every room is connected.
Step 4: Placing stuff
Okay, so now there’s a bunch of rooms and tunnels connecting all of them. For placing stuff, we have a lot of options. You could just randomly place stuff all over the place (searching for tiles that aren’t walls or stones). But what I tend to do is loop through every room in our rooms array, and place a set amount of enemies in each one. You’ll still want to probably make sure whatever position you select in a room is actually a floor (in case you create template rooms). Things like treasure could pick a random room and then a random position in it.
I haven’t decided how to pick the start / end position yet, but I think the best thing to do would be to select the first room in the rooms array and place the player there, and then find the room furthest from that one and place the end around there.
THE CODEThis is going to be a bit messy, and I’m not sure how useful you’ll find this, but here’s the C# code I used to generate the maps in my games. There’s some parts that are pretty gross (my A* pathfinding code is kind of ugly and could really use a clean rewrite). But it gives you a basic idea of what’s going on.
Along with that, here’s an example template room. The template room was created using Ogmo Editor
CONCLUSIONThaaaat’s pretty much it, hopefully it was somewhat useful or informative or something. Leave a comment if you have any questions and I’ll try to get back to you!
(2012) Years of Game Development Adventures
THE GAME-MAKER BEGINNINGS
Before I begin I should explain some of my history creating video games. I didn’t start making any “commercial” games for several years. It took a lot of hard work beforehand.
I first started making games in Game Maker, a tool that I loved to use for about 4 years. My dad introduced me to Game Maker when I was 11 or 12 but it wasn’t until I was 13 that I could actually handle the program. At which point, I became obsessed with the tool. It soon became my daily activity; the thing that I would go do when there was nothing else to do. I remember in grade 9 (first year of Highschool in Canada) I would wake up at about 5am, work on my games for several hours before school, and then come back from school around 4:00pm and work on games until I fell asleep. It’s all I did, and all I really wanted to do at the time. Jump ahead several years, and I’ve now completed several games, though nothing of which I would call very high quality. However, I’m 15 and anything considered remotely playable was a huge success and milestone. I was contacted by a teacher at a local school who wanted to build this Math game for some of his students, and I eagerly agree to make the game for $250. It was a small prototype and took a few weeks to make, but for a 15 year old kid I was going crazy. I’d somehow made money from the activity I spent all my free time on. From this point onwards, I knew I wanted to make games, and I knew that some people were willing to pay for me to do so (no matter how small an amount they were interested in paying).
AS3 AND LEAP 4 BLUE
When I was 17 I started getting into AS3 with help from friend and awesome independent developer Chevy Ray. He had just created the FlashPunk library and I eagerly downloaded it the day it came out. I was utterly confused, and it took several months for me to sort through it and build something that anyone could consider a game. With lots of help from other developers, I eventually finished my first Flash game. At the time I didn’t understand Flash sponsorships and did not go seeking any money for it. Money wasn’t really on my mind at this point, either. Though I knew Flash games could go commercial, I didn’t think I had the skill involved to sell anything I made. A few months later, I went to my first Game Jam, and met independent game developers in-person for the first time ever. This is where I met Alec Holowka, who has since become a really good friend and collaborator.
I want to make something VERY clear here. If you’re an aspiring game developer, like I was and continue to be, my largest suggestion for you is to go meet other developers. Save up money and go to GDC or a GameJam close to you. I doubt I’d still even be making games to the extent I do if I hadn’t made an effort to make it out to this first jam. At this game jam, with tons of help from Chevy, I created a prototype called Leap 4 Blue (named by internet friend, Jack). Due to the game jam and meeting other flash developers, I was introduced to the idea of Flash sponsorship.
This is where I realized that other developers who actually made a living from games thought my little projects had value, and I should try for Sponsorship. So that’s what I did with Leap 4 Blue. It took several months to complete, and was released in September/October of 2010. All told, I made a few thousand dollars from this game (by the time I paid off Flash Game License, my musician Liam Berry, and the $100 I donated to FlashPunk). Looking back, I think I was extremely lucky with the amount I was paid. I feel like the game probably wasn’t worth what I got, but in this case I happened to be lucky and things worked out the best for me. For a first commercial flash game, don’t expect this much. Andy Moore has a great blog post on this.
THE DOWN-TIME AND THE WINNITRON
At this point, I knew I could make money from games and I had a solid idea as to how to do it. I knew people would pay for Flash games, and I realized I had the potential to make games people felt had value. This did not help with my development. Before, I would just make games that I enjoyed making. Suddenly I felt pressured to make something good and every idea I had I would throw out because I felt no one would buy it. That’s a bad mindset to have, especially for a young developer just trying to make games.
The next 8 months I tried making more flash games, and learned a LOT on the way, but never got anything that I really liked. I went through dozens of prototypes and tried lots of things, but nothing really stuck. Throughout this time I also worked on the Winnitron arcade cabinet, so although I didn’t have any new work to show, I felt like I was at least helping a really cool project along.
It’s a weird feeling when you’re not getting anything “done”. I know looking back that I learned a lot in those months, but at the time I felt pretty bad about not finishing anything. I knew I could. I had done it before. But I just couldn’t get anything that felt right. Which sucked, and it was a bit depressing.
I went to GDC for the first time in 2011 with my fellow Winnitron crew, and was super inspired by what I saw. I met tons of developers and was blown away with what everyone was working on. I really wanted to get a new game done after going to this. I’m not going into a lot of details about my experience at GDC, but basically what I want to say is that if you can make it, GO. It’s given me the most inspiration ever, and I’ve met a lot of good friends and collaborators there. Shortly after GDC, I was offered to work on a game called Incubattle for Killscreen alongside Alec Holowka and Paul Veer. This came about in a pretty weird way. I was in a skype chat with several other developers, and Paul Veer came online stating that he was looking for some programmers for a job he’d been offered. Alec said he’d be up for it, and suggested that maybe I could program it along with him. I took that up, and we started. We only had a month to make the game, and it came about pretty suddenly, so all told it was very rushed. Alec and I went crazy the first few days and got well ahead of the deadline, and then we worked on other things for about 2 weeks. We then realized we only had just over a week left to finish the game and spent some crazy hours getting it all done. But we finished it, and it was released. The game, all told, made me less than Leap 4 Blue, however I felt pretty good about finally getting something done after so many months of having nothing to show.
ANOTHER 8 MONTHS
I then spent the next 8 or so months working on little prototypes and trying to get my next flash game off the ground. But again I was in that low of never finding anything I really liked. At the start of September of 2011, I also started University, which left me with less time to work on games. By the time December rolled around, however, I was learning how to better manage my time between game dev. and University activities. I decided to enter Ludum Dare, alongside a friend of mine who had never made a game before. I worked on the game in AS3 while he made his first game ever in Game Maker. I ended up placing 2nd overall, and he placed 129th. It was a really awesome experience. But I was still feeling pretty low about not getting anything done. By January 2012 I hadn’t made anything in about 7 months that I actually finished, and I wanted to get something out there again. I’m impatient, and 7 months feels like a really long time to me.
THE START OF BROKEN ROBOT LOVE
At the beginning of February, 2012 (at this point I’m now 19) I went to the third game jam in Winnipeg, and started what was Broken Robot Love (at the time called “Sync” for lack of a better name). My idea here was to take Leap 4 Blue, now verging on being 2 years old, and recreating it as if I made it in the current time, with all my new experience, instead of back then. And that’s what this became. I spent a few weeks working on it, and after I had 10 levels done I realized I wanted to finish it and get it sponsored. At this point I stopped working on the game (weird, right?) and sent it off to sponsors. Instead of continueing to work on the game while I waited for a response, I started screwing around with other projects. Looking back, I should have just kept working on it (and maybe it’d be done sooner). It took nearly a month to get a sponsor sorted out, and this was the first time I was going to make a considerable amount from a game. At this point, it was just finishing up the game, which took longer than I had expected. As of writing, I’m finishing up the final bug after sending the “finished” version about 2 weeks ago. I can’t actually talk about who sponsored it or the process in doing so, but once it’s released in September I can go into more details… But I’ll talk about what I learned from this process below.
SUMMARY – STUFF I LEARNED (OR THE TL;DR)
So now that I’ve explained all of my projects for the last several years, I figured I should talk about what I feel like I’ve learned.
- Make Connections – Go to game jams. Meet people. Become involved in whatever local scene you may have. People often think I’m really lucky for having such a “huge” game developer scene here in Winnipeg, but I don’t. There are a small group of maybe 4 to 6 of us that meet up and talk about games regularily. We just make an effort to get together and talk, and travel to other places (GDC, OrcaJam, etc) to meet other developers.
- Makes games you want to make – I spent several months (multiple times) trying to build games I thought would sell and never got anywhere. When I make games I really enjoy making, that’s when I have something successful. Sure, I keep in mind that I will try to make it commercial when it’s done (to make sure it’s polished up) but I don’t worry about what I think will sell or not until it’s completed.
- Unfinished projects are still learning experiences – I spent some time feeling pretty down about not getting anything “done”. But later on, as I built games that did come to a completion, I realized how much I actually learned from these unfinished projects. I have countless unfinished projects – probably about 10 for every 1 finished game. And I’m totally okay with that. The more I learn, the more capable I am of finishing projects as well. It’s all part of the learning experience
- Collaborate – To be honest, I’ve never finished very many of my collaborative projects. But I learned a lot, and had a lot of fun (and made some awesome friends along the way). It’s sort of a different experience when you collaborate with someone (especially if it’s in-person) and in my opinion, helps you learn a lot more, a lot faster. You can sort of help each other out learning stuff, since one person will know how to do X better, while the other person can do Y better.
- Be patient with Flash Sponsorships – This one is actually more recent, but I made a game along with Chevy at a game jam called Chunkadelic. It took us 2 days to make the game, and we decided to e-mail a few sponsors we thought may be interested. We didn’t hear back for a few days, and decided to just say “fuck it, let’s just release this thing and get it out there”. The very day we released it we heard back that someone was actually interested in sponsoring it. It would have paid for my trip to the jam in the first place! So, wait a bit. See what people have to say. There’s no harm in being patient.
- Communicate with Flash Sponsors – Before you go to something like Flash Game License to sell your game, try e-mailing individual sponsors first. Most of them will not reply, some of them will say no, but a few may actually be interested in talking. The worst that comes of this, is that you need to head to Flash Game License and try over there later on. And if you’re lucky, you may have made connections that will put up a starting bid on your game to get things rolling. When e-mailing a sponsor, I’d be pretty direct but also as friendly as possible. Sell your game, but don’t go over the top. Personally, I’ve had the best time when both you and the sponsor are really friendly and open minded about different possibilities.
- For those just learning programming – Don’t get discouraged. When I decided to learn AS3 after Game Maker, it took several months of getting no where before I had anything to show. And I already had a basic understanding of programming and object orientation at the time. You just need to keep screwing around with it and asking questions. My best suggestion is to AIM for a small game to make, and then ask question whenever you run into a problem, until the little game is made.
- Learn more languages! – I didn’t mention this anywhere throughout the post, but I’ve spent a considerable amount of time in-between projects learning C#, PHP, HTML5, and a tiny bit of C++. So far I haven’t finished any games in any of these languages (granted the PHP/HTML5 helps with web design a ton), but it’s a great way to keep learning. Learning other languages has helped me get a better grasp of the languages (AS3) I already know.
Procedural Generation - The Caves
Over the last week, I’ve been doing more procedural generation for a game that my brother, Liam, and I are creating. It’s going to be a rather simplistic and casual game when done, but one of the most exciting things about it is that every level is completely generated from scratch, creating rich, varying, environments every time you play. You can check out what’s been done so far (as of this post) here. Since posting that, I asked if people were interested in me writing up the process that my generation takes to create the maps seen in the demo above. I got enough interest that this definitely seemed worth while, so here it is!
PART ONE: THE BASICSBefore I explain anything, make sure you’ve actually seen how the generation looks in-game. If you missed the link above, see it here. The idea for this game was to create a vast cave with interesting tunnels, pockets, and enclosures. I started off with a number of different methods that ended in very interesting shapes but nothing quite like how I wanted. I searched around a bit for different methods and ran into Chevy Ray’s example that he
CREATE THE MAP
The first thing that my generation code does is create a 2D vector (array), containing ID’s (integers) of the different types of cells. To start, I create a 400×300 size grid, all with the value “1″. In my case, ID=1 stood for walls, and ID=0 stood for empty space (titled floors, even though they’re not, really). Later on I add Water, which is ID=3, but that’s not important right now.
Once the map is created, I then create a “miner”. In my case this is actually just called a “Cell”, but it makes more sense if you consider it to be a miner. The miner is created in the center of the map (200×150) and is labeled as “active”. When generating the map, I create a loop that goes through every active miner, and runs their “dig” function. When the miner “digs”, it picks a random cell around it, that is not yet an empty space (ID=0) and digs it out, moving itself in that direction.
For example, if the miner was at 5×4, and decided to move UP, it would dig out the cell 5×3, and move itself there. Whenever a miner digs, it also has a small chance of spawning a new miner in a random direction. In my generation code, the chance is about 8% that a new miner is added.
If a miner has no walls surrounding it (ID=1) then it unactivates itself, and stops digging. If this miner happens to be the last miner alive, then it just moves around until it finds a new wall to start digging.
CALL OFF THE DIG
Depending on how you want your maps to look, there are a number of different ways and times you can stop the miners from digging. You can stop the digging when there is only 1 active miner left, which is what I was originally doing. The problem with this though, is sometimes you’ll have gigantic maps, and sometimes your maps will be 4 cells big. It’s too random for me. Instead, what I decided to do was say that once 400 miners had been added, STOP digging. 400 is just a random number I chose, after experimenting with higher and lower values, and this size seemed to represent a good amount of miners for the size of level I wanted.
WHAT WE’VE GOT
At this point, my levels were generally looking like this:
The general shape is awesome (in my opinion) but it’s cluttered with horrible little bits of dirt everywhere! Which is why we needed ….
PART TWO: CLEAN UP!So, as you can see from the image above, the map definitely needs some cleaning up. If we were to stick a player and run around in that it would feel horribly awkward and cluttered. This had me stumped for a little bit, because I was trying to think of ways to alter the original generation to remove these oddities. In the end though, I decided it would be much easier to simply run through my map one more time, and remove anything I found unfitting. So, I ran through every cell in the map, checking the following with each cell:
These cells were walls sitting all by themselves with no one around. If I found any walls that had no adjacent walls (up/down/left/right) I would remove them.
These cells only had 2 adjacent walls, in most cases creating long strands of walls. These looked really awkward and just took up space, so I removed all of these as well. This also gave the map edges a more rounded look.
These cells were a group of 4 cells. I removed these as well. This might sound like I over do it, but ultimately the end results are a lot cleaner:
PART THREE: WATER(FALLS)This is by far the easiest part of the entire thing. I had a few people think that the water actually may be part of the generation, but, it definitely isn’t. Water is added in at the very end, after we have the result above.
The pools at the bottom of the map are really simple. No, they aren’t generated by waterfalls, and no, there isn’t some magic algorithm that makes them. All I do is grab the lowest empty cell (ID = 0) in the map, and fill every cell 20 cells high from that point up, with water. That’s it.
The waterfalls are also really simple. I grab 4 random points that are adjacent to a wall (above it) and create that point as the start of the waterfall. Then, the water just automatically keeps moving down until it finds a wall below it, at which point it moves left/right until it either can’t anymore, or it can move down again. Once the water can no longer move down, it stops, renders out the waterfall (to a tilemap) and removes itself (well, the thing that generates the water fall does – obviously the graphics for the water doesn’t).