• Fill the level with dirt.
• Based on weights for each block type choose one. Then find a random square shaped-area in the level. This varies the tiles in the level creating deposits of coal, gold, water, and etc. Do this a few times.
  • For each tile in the square area, change the dirt tile to the chosen block based on a specified chance (if I remember correctly, blocks had a 30% chance to dirt). This ensures we don’t have square areas of tiles.
• Find a random square-shaped area and change all the tiles to floor tiles, which creates (boring) caves. Do this a few times.

Resulting levels were “unique” each time but not very interesting because they lacked defining features or fun caves to explore. In Caved In 2 I’ve decided to take a different route. Instead of randomly generating the level, I broke it into four 12×12 tile “rooms”. The rooms are designed by hand in Ogmo by laying out dirt tiles to define caves and placing object spawns (such as loot, power ups, and etc).

A bare room designed in Ogmo.

The rooms are then compiled into a XML “room database” using a script I wrote in AutoHotKey. When the level is generated, it randomly chooses rooms and stitches them together to form the entire level. The dirt tiles in the rooms are then replaced with other tiles using a similar algorithm found in the original Caved In, although it’s been refined to provide a better spread of block types.

Same room from above in-game…although some gravel caved in above where I dug in.

In the end, levels are still randomly generated but provides me with a bit more control to help give the levels a more personal touch. In the coming weeks I’m going to be churning out loads of more rooms as I get closer to release along with more props and decorations. Stay tuned!

“I think I’m lost”

The player starts out in pitch black with only a small diamond of the level visible. As the player explores, they uncover the level although areas not within the diamond radius are slightly obscured again. While it was my goal to not hold the player’s hand and let them explore, it proved difficult to determine where the ladder would be each level. It was simply a matter of randomly digging around until the ladder was found. I later added a compass that (sort of) pointed towards the general direction of the ladder, but it was a lousy remedy. Yet it did produce a pretty awesome comment from a player: “Good thing this cave has highly magnetic ladders built into it.”

One of the major goals in the sequel was to find a better solution to this problem and make exploration more rewarding. I tried a handful of different methods, but I eventually came up with the brilliant idea of glowing mushrooms.

“DIAMOND!”

Mushrooms are placed in caves and there are usually two or three visible on screen at any given time. They give off a dim light that illuminates the tiles around it, even when the player is not in the immediate vicinity and act as landmarks. Since they only spawn in open spaces, the player begins to realize that digging towards mushrooms means they’ll find a cave once they get there and caves contain loot, damsels, and most importantly – the ladder.

Up next: rescuing damsels while trying not to have the cave come crumbling down on top of your head.

I’d also like to mention that I haven’t put much work into Caved In 2 since the last post, mostly just been on and off work on the medal system. However I’m planning on getting at a good solid chunk of work done tomorrow. My current plan is to work on the game during my spring break, which happens to fall during the last week of April.

I’ve also been thinking about the rogue-like that I was planning on doing next, but I don’t think I’m going to go through with it. Such a big project is likely to keep me hung up for quite a long time and I’d much rather work on smaller, more manageable projects. I’m currently working on a space-dog-fighting-arcade game for one of my classes that I think I’ll continue with after Caved In.

So apparently I first mentioned Caved In 2 back in November and now its almost the end of March, which makes this almost a five month project. Oops…I meant to get this out the door in under a month! Oh well, at least the game is coming along nicely. Here, take a look at the new font and one of the four tile sets:

I’m currently working the game over screen that awards you medals based on statistics from your last session. I’d post a screenie, but the UI is a mess at the moment. Basically, if you mine X blocks or do something X times you get an award with a cool name. Nothing too special but many people often like looking at stats to gauge how well they did and what they accomplished.

After stats and awards, I’ve been thinking about adding traps and a few new powerups but have been having trouble thinking of things that would actually add to the gameplay rather than just being there.

Anyway, almost complete! Hopefully I’ll get it out before the end of March, but I’m not entirely sure with my current workload from school and contracts.

Fun Fact: Planning on doing an ASCII rogue-like next!

• Not die during the apocalypse
• Finish GRIDNET and many other games
• Move out
• Get serious enough with TF2 to reach competitive level
• Socialize more and meet new people
• Excel in classes
• Get a part-time job

I (and many others) survived the apocalypse so my first bullet point was a success (yay!). However, I didn’t really hit the other ones so much. Early last year, I dropped development of Gridnet because I was spending far too long on such a behemoth idea. It got to the point where I was stressing about it and actually not looking forward to working on it each day. On the bright side after I shelved Gridnet, I released  two games Infested Space and soon-to-be-released Caved In 2 as well as two open-source projects StatSystem and  TileLighting! So while it wasn’t “many” games, I did at least do a few! As far as a job, I got quite a few interviews for game development positions, although many of them didn’t pan out. However, I did land a contract gig with BulletProofArcade as a game play programmer which has been pretty neat so far. The other bullets on that list were never met, to say the least.

Looking forward, I would like to go through with the #OneGameAMonth challenge for 2013. However I’m not quite sure how it will pan out because this is my final year in college and I’ll likely get quite busy. Nonetheless I’m still going to try because I really would like to have some more games under my belt. I already have an idea for my first game and a few vague plans for later months. I’m hoping to touch on genres that I haven’t before (like puzzle and strategy) and maybe even utilize Unity.

I’m also hoping to walk away from GDC this year with an internship or job. Last year, many of the employers wanted students who were graduating soon so I didn’t quite fit the bill with two years to go. This year however, I’m going to have my fingers crossed and my business cards ready!

Anyway, here’s the New Year’s resolutions list:

• Get a job or internship in the industry
• Finish more games (honestly, when will this ever not be on the list)
• Go through with #OneGameAMonth
• Meet some devs at GDC this year
• Finish school

Fun Fact: I finally got around to getting my driver’s license the day the world was supposed to end.

About two months ago I landed a contract gig with BulletProofArcade and I’ve been happily coding away. Coupled with school work, I’ve been quite busy especially since I’m now reaching the final year. However with the holidays here, I’ve been finding more and more free time (yay!) so I’ve picked up on my own projects once again.

I had been working on a Borderlands-inspired hunting game, but I put the project on hold to work on something smaller since I couldn’t find much time. So I’m currently working on a sequel to Caved In as I had been wanting to revisit the game for quite awhile now and it fit the bill in terms of my time budget. I don’t have anything worth screen shotting just yet, but hopefully I’ll get something ready for this #ScreenShotSaturday! I’m in the process of wrapping up world generation, so I should have something cool by then.

I’m also trying to get around to making some mods for the various games I own as well as some more open-source libraries. As a matter of fact, I have a few potentially useful libraries should be committed to github after some house keeping…

NOTE: I used Oryx’s free tile set for the tutorial.

Okay let’s get started! You’ll need to download the tutorial project zip as a starting point for this tutorial. The archive contains everything, but at this point you just want to turn your attention to the Ogmo project and level files found in the assets folder.

PRO TIP: As of this moment in time, there is a bug in Ogmo 2 where if you resize the window the tiles will disappear. In order to combat this, resize your editor window to the desired dimensions prior to loading a level. If you don’t heed this warning and you get invisible tiles, simply close the project and reopen it.

Above is the level file you will find in the archive. As you may have noticed, I have two tile layers – one for the bottom (or “floor”) tiles and the another for the top (or “detail”) tiles. This allows you to place other tiles on top of each other without the bottom one being over written. As you will see below, you just need to make second tile layer with the same properties to achieve this.

Okay, so how do you actually get the level into your project you ask? Well it’s quite simple really.

You’ll want to add a new class to your project that extends FlashPunk’s entity class:

public class Level extends Entity 
{
    private var xml:XML;
    private var tile_layer1:Tilemap;
    private var tile_layer2:Tilemap;
    private var grid:Grid;

    public function Level(rawData:Class) 
    {
        super(0, 0);

        // to check for level collisions
        type = "level"; 

        // FlashPunk function makes get all that data super easy!
        this.xml = FP.getXML(rawData);
    }
}

You’ll need a variable to hold the parsed XML data, one for each tileset, and one for the grid.

Many people who have seen Zach’s tutorial use a slightly more verbose method of getting the XML data. However, since that video a function in FP called FP.getXML() has been added that simplifies this process, which I’ve used my my constructor.

In this next block of code is the added() function of the entity, which will be loading up our tilesets:

override public function added():void 
{
    super.added();

    // load tiles
    // bottom tile layer
    tile_layer1 = new Tilemap(Assets.SPR_TILES, xml.@width, xml.@height, 16, 16);
    tile_layer1.loadFromString(xml.tile_layer1);
    trace(xml.tile_layer1);

    // top tile layer (details)
    tile_layer2 = new Tilemap(Assets.SPR_TILES, xml.@width, xml.@height, 16, 16);
    tile_layer2.loadFromString(xml.tile_layer2);

    // set graphic to graphiclist of tilesets, order matters!
    graphic = new Graphiclist(tile_layer1, tile_layer2);
}

Here we want to initialize the tilemaps with the width and height values from the XML data of the Ogmo level. Then use the loadFromString function available in the tilemap class which loads tiles from a string, which is exactly how Ogmo formats it. How handy! Then we just have to construct a graphic list and assign it to our graphic.

PRO TIP: I’d like to take the time to point out that you use the “@” when you want to access a value within an XML tag. For example:

<data>
    <company name="Awesome Co">
        <employee id="1">John Doe</employee>
    </company>
</data>

To get the “name” value from the company node: “data.company.@name”. If you want to get value between XML tags, leave out the “@” and use the name of the root node. So to get the employee name: “data.company.employee”.

Next we’ll want to use the same principles to load the grid. Keep in mind this is still within the added() function of our Level class:

// load the collision grid
grid = new Grid(xml.@width, xml.@height, 16, 16);
grid.loadFromString(xml.grid, "");

// set the grid to the mask of this entity
mask = grid;

However, note that Ogmo doesn’t use the FP default comma (“,”)  for the column delimiter. You’ll need to pass in double quotes for the delimiter parameter so it is loaded correctly.

Finally, we need to add our entities. Typically, you have more than just one instance of any given entity, so we’ll want to loop through each one and add it to the game. We can do this by creating an XMLList and assigning a parent node to it. Then all we need to do is loop through the list and add each entity:

// load entities
var list:XMLList; // holds an xmllist
var element:XML; // a specific xml element

// for each player in the xml list
list = xml.entities.player;
for each (element in list) {
    // add it
    world.add(new Player(element.@x, element.@y));
}

// for each coin in the xml list
list = xml.entities.coin;
for each (element in list) {
    // add it
    world.add(new Coin(element.@x, element.@y));
}

You can also pass other XML values into the constructors of your entities if they have other properties. For example, let’s say our coin has a “pointWorth” value:

world.add(new Coin(element.@x, element.@y, element.@pointWorth))

Just make sure you define the property in your Ogmo project as well!

That concludes the tutorial! If you have any questions, please leave a comment, email me, or find me on the FlashPunk forums.

Controls
WASD: move
F: toggle flashlight
E: interact
Mouse: aim
Left-Click: fire
Esc (or P): pause
M: toggle audio

I’m mostly proud of the atmosphere, not so much the actual game play. I personally feel that its a little linear (and short) but then again I’ve been playing the damn thing over and over again for the past few months. Thus far, most people take about 20 minutes to finish it and have said it was moderately challenging so I’m happy. I’ll likely have to patch it in the coming week if the majority of people find the game to be too difficult, like most my games. I’m also very thankful that Chris Sinnott helped out me out once again with the audio. It really adds to the experience!

This game was also important to me because its the first project after I decided to shelf the monstrous project I had been working on for nearly a year – Gridnet. I’m not going to go into the reasons why except that my current plan is to work on much smaller, month-sized projects. I’m already prototyping a new game as we speak!

Anyway, Infested Space will be available once Mochi approves of the game. At that point, you can find the play link on it’s dedicated page or where ever else the game pops up (because I’m letting Mochi distribute it where ever it pleases).

Until next time…

As of version 2.1.0, StatSystem contains inventory and item management features! This tutorial was created to introduce these new features. As usual, when functions and properties are mentioned, they will be linked to their respective location in the documentation.

The new features summarized in one sentence: an Inventory is a collection of ItemStacks, each of which hold an amount of an Item.

The Item class contains three basic properties:

• name – the name of the item as a string
• type – the type of item (this can be anything e.g. weapon, consumable, potion, and etc)
• stack – the maximum stackable amount for this item in an ItemStack
• stats – the StatSystem for the item

To create a new Item simply pass the desired name, (optional) item type, and (optional) max stack of the item. Here I’ve created a new item called “Health Potion” that is a “potion” type item and stacks to the maximum of eight.

var itemdata:Item = new Item("Health Potion", "potion", 8);

PRO TIP: If you set the max stack of an item to -1, there will be no limit. This happens to be the default value if you do not pass a value in the constructor.

To clarify the “type” property: In RPGs, there are often different types of items – weapons, shields, armor, consumables, food, and so on – each that have a different set of stats. If you are familiar with FlashPunk, you can think of it the same way the Entity’s “type” property.

Now back to our Health Potion! Let’s say all of our potions in our imaginary game have following stats – health, mana, and worth. Since this our Health Potion obviously affects health, we’ll give it a value of 20, mana a value of 0, and lets make it an expensive by setting the worth to 500:

itemdata.stats.addStat(new Stat("health", 20));
itemdata.stats.addStat(new Stat("mana", 0));
itemdata.stats.addStat(new Stat("worth", 500));

The reason we still add the “mana” stat to the health potion is because we want all “potion” type items to have the same stats (but they don’t have to have the same value!) so when we need to do something with it, we don’t need have have any special cases and use a “catch all” code block. For instance, take this code snippet for example:

// inside function that uses an item

if (itemdata.type == "potion") {
    player.stats.getStat("health").addValue(itemdata.getStat("health").value);
    player.stats.getStat("mana").addValue(itemdata.getStat("mana").value);
} else if (itemdata.type == "weapon") {
    // weapon-y stuff here
}

Other good examples are weapons in rouge-likes since they often have a multitude of different attributes:

//Sword of Fire
var itemdata:Item = new Item("Sword of Fire", "weapon", 1);

itemdata.stats.addStat("slashing", 3); // swords do slashing damage
itemdata.stats.addStat("crushing", 0);
itemdata.stats.addStat("piercing", 0); // I guess you could poke someone with a sword
itemdata.stats.addStat("fire", 10); // this isn't your normal kind of sword
itemdata.stats.addStat("water", 0);
itemdata.stats.addStat("earth", 0);

//Mace of Rocks
var itemdata:Item = new Item("Mace of Rocks", "weapon", 1);

itemdata.stats.addStat("slashing", 0);
itemdata.stats.addStat("crushing", 20); // smash them slimes!
itemdata.stats.addStat("piercing", 0);
itemdata.stats.addStat("fire", 0); 
itemdata.stats.addStat("water", 0);
itemdata.stats.addStat("earth", 5);

Now that we’re overflowing with cool items, you’ll likely want to store them all somewhere. This is where ItemStacks and Inventories come in handy!

First off, let me make it clear that an Inventory is a collection of ItemStacks, not Items. ItemStacks are stacks of identical items. If an item contains a property that changes over time (such as, charge, durability, etc) or can be changed by the player, you’ll want to set the max stack of the item to 1. For example, say you find a Steel Sword that has 10 points of durability left and you have a Steel Sword in your inventory that has full durability points. If the max stack isn’t set to 1, that almost broken Steel Sword will have max durability once you add it to your inventory since it will be added to a stack. Now here’s to actually use ItemStacks and Inventories.

An ItemStack has two properties : the item it contains and the amount of said item. So say we wanted to create a stack of Health Potions for a trip down into the dungeons:

var item:Item = new Item("Health Potion", "potion", 8);
var stack:ItemStack = new ItemStack(item, 8);

PRO TIP: It’s also worth mentioning that ItemStacks have three methods for altering the amount – add(), remove(), and setAmount() which should all be self explanatory.

Now we need to create an Inventory to hold the stack. Inventories have only one property – the maximum size. So let’s create a small inventory of size 5 and then add our stack of potions:

var inventory:Inventory = new Inventory(5);
inventory.addItemStack(stack);

PRO TIP: the size of an inventory is the number of slots, not the number of items it can contain.

Since our inventory was empty when we used addItemStack(), our stack of potions will take up the first slot. You can also add items via the addItem() method which takes an Item instead of an ItemStack and the amount of the Item to add.

To get our stack of items back from the inventory, we can use getBySlot() which returns an ItemStack at a specified slot in an inventory but doesn’t remove the ItemStack. Since our potions are in slot one, we’d pass “0″ into the parameters as the inventory slots are zero-based. To remove an ItemStack from a specified slot, use removeBySlot() by simply passing the slot and amount to remove in the parameters.

There will be other occasions where we won’t know where an item is in an inventory. This is where the removeByName() method comes in. The function takes a name and the amount to be removed.

This concludes the introduction to the item and inventory management features!