Connor and I were interviewed by Josh from IndieStatik while at GDC about our most recent project, Oblitus.
So there were these alien bugs. And some procedural generation. And some dude with a jetpack in a weird-gravity alien world. Yup. It’s happening.
It’s been a little while since I gave an update on Entity 37, so now is a good time.
I’ve been working on it pretty consistently, but overall progress has been a little slow. Feeling a little demotivated the last few days (for unknown reasons), but starting to get back into things again.
For the time, the video above explains what’s been going on pretty well. If you follow me on twitter or visit indiegames.com you’ve probably already seen this.
This is the first entry in a devlog that I plan to be updating on a weekly basis (or more frequently if I have more updates). We’ll see what happens, but I’m pretty excited about writing this devlog. Hopefully it will inspire me to keep working (and maybe anyone who reads this as well).
So the game is called Entity 37, and it’s about this pink creature, in the screenshot you see above. You escape into this space station and wreck havoc amongst the scientists and crew on board as you try to make your escape (which isn’t going to necessarily be a success). The game is completely mouse based, and you move around and can grab, pull, and throw enemies and other intractable objects around.
So today I was working on a new enemy, called the Crawler. It’s not totally done yet, but the basic idea is it’s this enemy that you need to grab and fling into the walls (or hazardous objects, like lasers) to damage it. Meanwhile, it’s trying to shoot you.
Here’s a gameplay video that should better describe the new enemy.
Aaaand that’s pretty much it. Hopefully will post another one of these in a few days with a bunch of new content to show!
I figured now would be a good time to post an update on the progress of my latest game, Broken Robot Love.
Where exactly is the game at?
The game, at this point, is basically complete. I’m still short a handful of levels, and I need to wrap up the final cutscene (the game has a few cutscenes), but besides that everything is pretty much completed. I’ve been setting bi-weekly milestones for the game, and have been able to keep up with them pretty well. I’m hoping to have the game completely done within a few days. This Thursday if all things go according to plan.
When will it be out?
Even though it’s very close to completion, I’m not entirely sure when it’s going to get released. Most likely it will still be a few weeks (or months) away.
Wasn’t this started like 5 months ago?
It was! The game began on February 3rd during a game jam in Winnipeg, and I worked on it for about 2 weeks into February. At that point, I stopped development for a time and didn’t pick it back up again until the beginning of April. So, all told, the game has been in development for 5 months, but I’ve only been actively working on it for around 3 months.
Wait. I’m not even sure what the game is about…
You can check out this gameplay video from a few months ago. It’s reasonably outdated now (and there’s tons more in the game) but it still gives a good feel as to how the game plays.
A little trailer for the game I started at PEGJAM 2012. Hoping to finish this up before I head out to San Francisco for GDC at the end of the week!
Last December I created a game for Ludum Dare, a competition in which you need to create a game in less than 48 hours. The results were posted yesterday, and it turns out my entry, Abandoned, won 2nd place out of over 700 games! Really exciting with the results, and ready to continue development on the game now that I have some more free time.
I intend to continue working on Abandoned and release the full game later in the year (hopefully in a few months from now?). I’m not entirely sure what I’ll be developing it in, but I’d love to eventually create an iOS version. Currently I’ve been learning Unity and slowly making progress on porting the game to that, but I’m also considering developing it in Flash first (what it’s currently made in) and then once it’s complete, porting the full game to iOS.
We shall see! Either way, I think it’s going to be awesome.
I’ve been spending the last several weeks working on this game called My Dark Delusion (WIP title). I’m not exactly sure what it is yet, but it will probably develop into a top down abstract shooter of some sort. We’ll see what happens. For now though, you can check out the main menu and the basic look of the game (select window + hit enter)
I don’t know yet. But maybe something? Thinking about procedurally generated levels for this (as always). “Hannigan the Green” name by Chevy Ray
I realized today that I haven’t actually posted any updates as to my current projects, and have really only posted small articles on procedural generation (which is just as cool), so I thought I would take a bit of time and update people on what I’m working on. A lot of the stuff I can’t go into much detail, but I can at the very least post some screenshots and say that I AM working on stuff.
The last several weeks have been spent working on a procedurally generated bug game, that I can’t talk too much about at the moment. I’m working on this with my Brother, Liam. He’s doing all the art and music, and I’m programming it. Our progress had slowed down for a bit as both of us were busy with other things in our life, but lately we’ve picked up progress again and are moving steadily ahead.
Though I’m not going to go into a lot of detail, I will post a screenshot. A few things to note is that a lot of this is still very much WIP, most obviously the player (he’s being recreated completely at some point).
The last few days I’ve also been working on a new prototype with Alec Holowka and Tom Rab, which is quickly taking shape and becoming interesting. I don’t want to talk about it too much either, but it’s generally going to be some form of a turn-based strategy platform game…. if it fleshes out.
Websites and Other
I’ve also been working on a bunch of websites over the last several weeks! The one I most recently finished was the brand new Flash Punk website, as the previous one was getting fairly outdated and desperately needed a fresh look.
Still a ways off
Liam and I are also starting to plan out a game we want to make later this summer – hopefully after our bug game is completed. I’ve posted a few things about this earlier, and we still fully intend to make this game a reality. We figure that this game is going to be one of our longer games to create (and play?), though obviously I have no good estimate as to how long it will take. I’m not even sure when it will get started.
One thing I can say for sure, though, is that the game is going to be made in Monocle Engine, a new open source and in-development C++ Game engine. Truly looking forward to working with that.
Over the last several months I have been researching and experimenting with different types of procedurally generated maps. I was working on a top down, zelda-like game that used procedural generation to create the dungeons throughout which the player would explore, encountering monsters and hidden treasures. Development never got to far on this game, but it was a great learning experience and I got my maps to a state I was really happy with.
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 BASICS
Before 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
posted here (edit: dead link). I never actually took a look at the code for this (not sure if it’s available or not?) but I liked the basic approach he was taking, along with his results. My end method is relatively similar to what he was doing, with some variations.
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).
PART FOUR: TILE PLACEMENT
That’s it! Hopefully it was an interesting read and helped you make your own maps. If you somehow missed the live example of this in action, you can find it here. Feel free to post any questions or comments, I appreciate them!
I realized that I posted this art for a game that my brother, Liam, and I have been working on, on a bunch of other sites, but not my own. So here it is!
This is for a game that Liam and I are making over the next few months. The art above was a collaboration between the both of us.
I recently posted a blog post about how I was generating quick levels with dynamically-placed tiles, and a fair amount of people I talked to asked if I could share an example/source for how this worked.
“An example of a level with automatically placed tiles”
So, today I threw together a quick example using FlashPunk for people to download and mess around with!
DOWNLOAD: Get it noooow
Try it out, and tell me whatcha think!
Over the last few weeks and months I’ve been having fun creating levels that don’t really use tilesets, for numerous different games. Instead, I’ve been using different level editors that produce shapes (by placing a bunch of points around) that are loaded into the game and used as the walls. You basically end up with levels that look something like this:
The walls are created from a bunch of nodes laid out in ogmo editor.
Last night, however, I decided it would be fun to try and place tilesets over these walls automatically, to create really dynamic and interesting levels. This way, I don’t have to painstakingly place each tile in every location as I flesh out vast levels. Instead, I can trace the shapes I want, save the level, and BAM the basic key tiles are automatically placed.
Looks pretty, right? Well, it’s just a single grass tile, and a single dirt tile, looped over and over again across the edges of the walls that would otherwise look like this:
So, I had a few people asking me how I got the grass tiles to loop like that. It was actually really easy. Basically, I would loop through all of the nodes that ogmo editor output for each wall, creating a bitmapdata (this is in Flash, AS3), drawing a line from one to the next. Then I would fill in the shape. After it looks like the image above, I would loop through all of the nodes again, except this time placing grass and dirt tiles (rendering them each to their own bitmapdata).
What would happen is that on each node, it would look back to the previous node and figure out the distance between the two. Then, it would divide this distance by the width of the grass tile, and place one at each interval between the two nodes, while at the same time figuring out the angle for each grass (which is just the angle from the last node to the current one).
Then my loop would go onto the next node and do the same thing all over again, until all the places between every node of the wall was filled with ever-so-lovely grass.
I think I’ll probably throw together a quick flash punk tutorial on how to do this in the next few days, for those that are interested on the exact details