Archive for the ‘Gameplay Mechanics’ Category

Almost done Item Creation

March 2, 2012

I shot my screen:

What you see above is my glorious Item Creation Interface, as described in the previous post. Well, almost. I said I was going to make failing recipes show up in red, but the way I have the string output stuff set up, it took less time for me to just write the name covered with xxxx instead.

It gets the point across. “Hmmm, I wonder what this xxxxx is that I don’t have enough copper bars for? I better make a couple more of them then.” I mean the thing is made out of 10 of them, so it’s gonna be good, right?!

While you can move the cursor on the workbench/forge/whatever panel, you can’t actually create anything with the A button yet. I haven’t coded in that part. I’ll do it tomorrow, it shouldn’t take any time.

A follow-up screenie:

Here, the forge is being ‘used’, and it has a different list of things it can create. It isn’t very long yet, though. I’ll finish this stuff up tomorrow and start the player with next to no items!

I want to take the weekend off from coding/designing/posting, but who knows. I’m thinking about making a video, but I still don’t think I have enough to show off yet. Maybe I will anyways. Whatever.


Inventory Interface Complete

March 1, 2012

I’m on Candid Camera?!:

Here I’ve dropped a bunch of items from inventory, moved some items into the chest, and split a stack of (99) into three. You can drop items from the other inventory too, in the case that it’s faster to steal that way. You actually need to move the cursor to an {empty} spot and select it in order to get the item into your inventory. It’s a little faster to pop things out and walk into them.

I’ve also added PlayerEntity::OnUse() so that you can move things around in your own inventory outside of the item swapping interface. You can’t move stuff while you’re not in the inventory interface because then you won’t be able to do anything while you’re looking at yourself. It is a little confusing having two cursors in your inventory, though. I might drop the > < one and use only the [ ] and screw it if you can’t do anything while you’re in there.

I lost a bunch of time to code cleanup today, since I’m not looking very far ahead of where I am at any given time. I’m not familiar with regular practices, so I can’t plan for them yet.

I’m probably going to code in 2D inventories soon. Obviously I won’t be using text-based inventories in the actual game, but it’s faster to get things in if I do it this way for now.

I’m done the stuff I wanted to do, so now I can start the item creation interface. I haven’t actually planned this part out yet, so I’ve got some designing to do. It won’t be like Minecraft, I can tell you that much. It might be like Terraria’s, just to get it in, but iunno yet.

Inventory Swapping working

February 29, 2012

Super screenshot deluxe:

There’s still lots of adjusting to do and rebuilding of sections, but I have a very basic item swapping interface partially working now. The way I have it set up is that you can use it in realtime, or pause the game to do what you wanted. Here I moved a few items to the a chest, and I’m about to move the forge.

  • The > < indicates the item you have for use – so you can defend yourself in realtime as you go through your box.
  • The [ ] marks where you are in inventory, and the * * shows what you want to swap with.

I have it set for you to quickly exit out of any inventory you entered by hitting the right shoulder button again while still selecting the object with your cursor.

You can inspect or swap with inventories of any Creature right now – including the Monsters. I’ll remove this later, but then add it back in as a steal ability for theives. There will be a time limit for viewing/swapping that will be rolled based on your stats and the monster’s stats. Some monsters won’t let you even peek, though. ┐(  ̄ー ̄)┌

Not complete is the item dropping and stack splitting. I’m tired, so I might not get to it tonight.

After I finish this, I’m going to move right into the item creation interface.

Moving in the right direction

February 29, 2012

Two screenshots this post, here’s the first:

Points of note:

  • Gamepad input tips in upper right
  • Certain things can be “used”; in the above screenshot the NPC is shown to be useable
  • Monsters can no longer pick up collectables, they’re shown pushing the ones above
  • Once an inventory is full, no new items can be added, and you will push items around like the monsters do

Second screenshot:

Notes of point:

  • 3 new useable blocks: Workbench, Chest, and Forge
  • Inventory “empty” slots

I want to recode a bunch of the code to make use of a new Item::OnUse() function. I’ll also be adding some Creature::OnUse() and Chest::OnUse() overrides, and then I’ll build the item swapping interface. Then I’ll add the Forge::OnUse() and Player::OnUse() and build the item crafting interface.

Collectables now In and Collectable

February 27, 2012

I’m tired so I’ll try to not go on too much in this post.

The little circles are the collectables. They’re just a small version of the thing that they represent. The copper sword is a yellow circle with a sword symbol in it. The copper sword collectable is a small yellow circle with a sword symbol in it.

I broke some of the rocks with my pickaxe and picked up the collectables they turned into. You can see that I’ve got some different kinds of ores, and some stone. I have an extra heal spell because when the NPCs die, they drop their inventory. I picked up a heal spell by mistake.

You’ll notice that some items are stackable and some are not. The heal spell did not stack with the other when I picked it up, but the ores did. Right now all stackable items have a maximum stack size of 99, but it’s easy to change the max for any new items I might add.

You might not have noticed that the creature I’m viewing, a monster, has picked up a stone and a dead NPC’s sword and spell. Just as the player and NPCs can pick up collectables, so too can monsters. I don’t plan on letting all monsters pick stuff up, but it shows that I can easily make thief foes that grab stuff on the ground and run away with them.

There are various glitches I have to work out before I move on to the next step… but I need sleep now.

More and more Prototype progress

February 26, 2012


  • Randomly placed natural stone and ore blocks
  • Letters and graphics in object circles to help identify them
  • Item list for every entity

Next is item collectables. I wanna mine those ores!

More Prototype Progress

February 26, 2012

I’ve been working pretty much nonstop since that last post, with various successes and failures. Let’s start off with a screen, shall we?

A Healer heals a Warrior, while a Wanderer waits for an upgrade.

Noteable changes and additions:

  • Basic Item system
  • Basic Gambit system
  • New npc class: Healer
  • New item: Heal spell
  • New item: Pickaxe (used to remove blocks)


When NPCs enter the world, they start as wanderers. They follow you to the town. Once near enough to the town crystal, you can assign them a useful class – Warrior or Healer. The Warrior gets a melee weapon and extra HP, while the Healer gets a heal spell. The gambits on the NPCs define how they act.

You can use the upgrade items on any NPC, and have any number of either class.


Each NPC class has a default gambit setup that makes the class useful. The Warrior will “attack” “foe: nearest”, and if there are no foes in its range of sight, it “wander”s. The Healer will “heal” “ally: lowest hp” first, and if the target or action fail for some reason, it will “heal” “ally: hp < 100%”. If there’s nothing to heal, it wanders.

I tried to make each gambit target and action “smart”: There are certain conditions where it doesn’t make sense for a gambit to fire. For example, if some gambit’s action is “heal”, and its target is found to have all of its HP already, then the gambit fails and the game moves to the next gambit. It’s pointless to heal something that’s already full, right?

Both monsters and NPCs have gambit sets. This makes it easier to build new creatures, and check to see what might be failing in AI code. When I have a decent number of gambits to use, I’ll set it up so you can change the gambits around on NPCs in-game.


So far only the player has an inventory, but it’s pretty straightforward for me to add inventories to the NPCs and monsters. I’ll be doing this in the very near future. I’ll also be adding an inventory trading mechanism so it’ll be easy to give NPCs items and let you choose what they have equipped. I’ll probably set it up so they automatically equip any stronger items you give them.

While I’ve made all the above progress, I was kind of stupid yesterday. I spent most of the day trying to figure out how to set up scripting. There isn’t enough here to bother with that! I don’t know what I was thinking, I had it on my mind and then I tried my hand at it. I was even ready to try building a roguelike that would do everything out of scripts! Then I came to my senses. I may still go to a scripting language eventually, but I want to develop my game as quickly as I can.

I have so many things I want to do, I don’t even know what to do next. I’m doing my best to stay focused on Keeping It Simple and driving my efforts to get One Of Everything in. The next goal right now should be to assign NPCs to/from the player’s party. After a bit of a break, I’ll try to start on that.

One of the guys that’s building Dwarf Fortress said that it’s not easy to balance the time put in to design and implementation. I’m starting to understand what he meant.

The Battle Begins!

February 21, 2012

So now the slime monsters will damage and kill the NPCs, and the player can kill the slimes. I now have something closer to a game than I had before. Here is the results of my first round of play:

I managed to corral 3 of the 8 NPCs that spawned so that none could get out and no Slimes could get in. The slimes got the others before I could save them.

It’s a bit of a pain to trap them though because they wander so aimlessly; it’s hard to know when to open the wall up for one to go inside. It was also a pain to get this shot because they kept going towards the camera and hiding behind the wall, when I was trying to get the screenshot. Camera-shy buggers.

Test Battle 1

All I really set up was collision detection between entities, and added a couple of responses. When an NPC collides with a monster, she reduces her hp and checks to see if she’s dead or not. When a monster collides with the player, the same thing happens. I set it up so that the monsters would die as soon as you touched them, but the NPCs could survive a bit of contact before they died.

I also set it up so that all 64 monsters and all 8 NPCs would spawn at once at the start, with no new spawns, so that I would have a challenge. I don’t want it to be this way in the final version, I just wanted to have a little fun. When I set the game back to having things spawn at a regular rate, you always have the chance to get all of the NPCs in your town, but it’s hard to corral them without the slimes getting in. The slime attacks are relentless; I’ll wind up turning the spawn rate waaaaay down so that I have a chance to breathe between attacks.

Next I want to be able to guide the NPCs to the town, and then upgrade them so that they can defend the town. This is the most important part of the town building section of the game – assigning classes to the NPCs.

Inter-Entity Interaction

February 19, 2012

For this post, I’m going to go over the first interactions between entities.

Monster and NPC contact

The first monster, the Slime, will do damage when its hitbox touches an NPC’s hitbox. When the NPC takes damage, it will enter a knockback state and won’t be able to be damaged again by that one monster for a period of time. Other monsters will be free to do damage, however, so monsters ganging up on one NPC will do damage much faster than one monster alone.

During knockback, the NPC will slide away from the last monster to cause damage. The NPC will also take damage on each hit, and will lose hitpoints until there are none left. At this point, the NPC will be killed.

Monster and Monster contact

All monsters, when in contact, will push themselves away from each other, so that there won’t be monsters inside of other monsters. I’ll have to be careful not to have them push each other into blocks, since I don’t want them to get stuck. I assume I’ll have to apply acceleration in opposite directions or something. I’m not really sure how I’m going to deal with physical collision response. I’ll figure something out.

I think that I’ll wind up having all entities push each other away from one another. I have only ever done this kind of thing in my ludumdare 10 entry. There were no boundaries to have to worry about, so I was free to push each colliding sprite completely outside of each other. I have a world to collide against so I’ll have to deal with that somehow. Maybe I’ll just do the push with the incremental movement function I already have.

When NPC takes damage

It would make the most sense for an NPC to run away when she gets hit, but that might get annoying. I’ll add a Flee state that will be active for a certain amount of time, or maybe a distance from the attacking target.

When Player takes damage

The player weill be knocked back just like the NPCs will be. The difference is that after the knockback, there will be a temporary invincibility period. The player will blink to show this visually, and the entity clipping will be turned off during this period. It will be possible for alot of monsters to hit you at once, or one monster to combo you with several quick hits, but I want to make sure you won’t be in stun lock forever. Allowing for that kind of thing is unfair and not fun.

Damage counters

Like in the last version of ActionRPG, I want to have damage counters pop out of whatever takes damage, so you can see visually that there was damage done and how much it was. I may not put this in right away, since it’s only a visual indicator. I want to focus on only the core code.

Letting the Player fight back

Finally, I want to give the player a weapon and let him do damage to the monsters. I’ll be building this pretty well exactly like I did in ActionRPG, with a horizontally arcing sword attack, but I also want to add a vertical arc and a thrusting attack. Eventually I’d like to set up the battling system to work like they do in the 3d Zelda games, with the z-targetting system.

When I have most of the above into the game, I’ll have satisfied the fighting system core requirement. I’ll start looking at either the Town levelling or more stuff with the NPCs. I want to get into the NPC class stuff soon so they can start doing something useful.

Monster AI Design

February 16, 2012

What’s next

My goal right now is to get Ano Sekai to a point where I can show off all of the core features. Right now I’m working on the Town Building game stage. Now that I have NPCs spawning around a Town Center block, I have several directions I can go in:

  • Monster spawning and interaction
  • Levelling up of town
  • Interacting with NPCs

The most interesting thing to do right now is clearly the Monsters. I didn’t really talk much about the monsters themselves yet, have I?


I was thinking about starting with the Minecraft method and working with that. The rules are easy: Every once in a while, try to spawn a monster at some distance from the player, in some random direction, but not too close. An additional rule will need to be that monsters should not be allowed to spawn within the Town Limit. (I’m letting NPCs spawn near the player, but I’ll be changing that.)

So the game has decided where it wants to spawn a monster, but what will it spawn? In this case the town level will be a big part of the decision. Each town level will have a set of monsters to choose from, where higher levels will have stronger and more difficult monsters to deal with. I won’t have to deal with that until I start working on the town levelling, though.

The actual number of monsters that will be allowed to spawn will have to be decided on during playtesting, as will the spawn distance and rate.

If you’re far from the town, the decision will have to be made differently, but that’s the next stage and I’ll leave that design for later as well.

Monster AI

Part of the task of building and maintaining a town is to defend it and its people from monsters. Some monsters will be more aggressive than others, some will be more dangerous than others, and some will try to literally destroy your town. You’ll want to build your town in such a way as to keep your NPCs and buildings safe from harm.

The first monster that will appear in the game is going to be the Blue Slime. If you’ve seen my actionRPG project, you’ll already know what it looks like. I’m going to be putting a little more work into the AI this time, though. In Ano Sekai, the slimes will act like the slimes in Terraria. I don’t know for sure, but they seem to have been based on Zelda II’s slimes, and that’s what I’ve always been looking at as the AI model for the slimes.

The Blue Slime will move around at random, but will only move in short 1/4 block high hops. It will take 2-4 small hops in one direction, and then stop for some amount of time. It will then pick a new direction at random and hop in that direction. If it runs into higher ground, it will hop up a full block but at half the forward move speed.

That will be its non-aggressive state. When it can see an NPC or the player and is close enough, it will become aggressive and chase whoever it has targeted. It will still do the same thing as before, the difference will be that it will always hop towards its target. When it can’t see its target anymore, or the target goes outside of its aggression range, it will return to its non-aggressive state and once again move in random directions.

Inter-Entity interactions

When two entities touch one another, something may or may not happen. There needs to be functionality to check for collisions between all entities, and functionality to cause a reaction in some of those cases. I bring it up here because I’m going to want to be able to tell when a slime is touching the player or an NPC, so that I can code a reaction to it.

I guess that ideally, if the slime touches any entity that isn’t also a slime, it should deal damage to it. There will be exceptions, such monsters made of stone or metal, or dragons. Taking damage will involve causing a knockback state, and reducing health by some amount.

I want to introduce health bars to the game at this time as well. Health bars will be shown over all entities as you would expect to see in an RTS, as a green bar perhaps with black or red to show how much health has been lost. Right now I’m thinking about FFXII because I’m replaying it off and on at the moment.

Once an NPC’s health has been reduced to zero, I want to kill it. At that point there won’t be any way to fight back other than to build. Once NPCs can be killed, it will be time for me to code in a way to fight back! The player will be given an arcing sword that will deal damage to the slimes and knock them back.

As I build things, I’ll be sure to post about them. Look forward to it!