Archive for the ‘Design’ Category

Sprite Builder Preview Update

March 29, 2012

I was going to go to bed, but I still had the project open so I made some Quick Changes:

What I did:

– Added a direction circle, divided by the ranges. The purple slice is the currently seleced range.
– Zoomed the sprite sheet and simulated the selection box for the frame.
– Added buttons for the States and Frames lists.
– Added file menu.

What I forgot:

– Need buttons for loading/reloading of the sprite sheet.

In short, nothing to see here, please keep moving.

Still Alive

March 29, 2012

It’s been two and a half weeks since my last post, and I spent alot of that time recovering from a flu I caught. While that stopped me in my tracks, it also gave me time to think about what I had been working on and what I want to accomplish right now.

The main thing is that my Framework proved to be overengineered. I was trying to wrap Everything into classes that you would inherit from and use – it was ugly and I had alot of trouble coming up with a decent way to render Everything. I was trying to do too much.

Framework Restart

Instead I decided to put all of that aside and start building a Framework that would only deal with things I’ve seen before, until I have One Of Everything I’ve Already Done.

Over the last couple of days I built a few Sprite classes with varying functions: Animation, Multidirectional, and States. While I haven’t added any of the error-checking, when you use them correctly, they work as I expect them to. Although I’m using the Sprite classes in 2D right now, the transition to 3D will involve only a wrapping interface class.

I shouldn’t ever have to build another Sprite class for XNA again. Yay!

Before I move on to a reusable Tilemap class, I’m building a Sprite Builder application so that you can create sprites in a more visual way, rather than having to punch all of the numbers manually into a file. Here’s what my first version looks like:

There are some things I want to change, but as it is right now it will do everything I want it to. I’ll start adding the code so that it can actually do things rather than just LOOK like it can do things. I’ll likely post a zip/rar somewhere once I have it working and documented enough.

Once I have some tools built, I’ll get back to Ano Sekai. Look forward to it!

Infinitely sized worlds’ Design

March 6, 2012

Feeling good enough to do some design today!

The gist

As you saw in the video, the game world was limited to just what was on the screen, and anything that left that area would immediately be destroyed. That isn’t how things should be. Instead, the world should technically be able to go in all 4 directions infinitely. I still want to have worlds that wrap around, so I’ll take care of that as well.

One method I’ve seen to provide that “infinite” feel is to divide the world into loadable chunks. The idea behind this is fairly simple: For any chunk of the world that hasn’t yet been seen, it should be generated by the in-game chunk generator. For any chunk of the world that HAS been seen, load it from disk.

RAM limitations

If we had an infinite amount of ram, then we would be able to keep every chunk in a great big array. I’m developing and playing my game on what would be considered a low-end machine, and that means my resources are limited. I need to build around those limitations. I suspect that even the highest-end machines don’t have infinite ram either.

Since ram is limited, I have to consider a way that will use a limited amount of ram but still have it seem like the world is endless. In order to do this, I only want a certain number of chunks around the player to be active at any given time. When the player has moved in such a way as to make any chunks inactive (they’re out of the player’s view radius) then they are saved to disk and unloaded. At the same time, when the player should be able to see new chunks, they either have to be created (not yet seen the chunk) or loaded from disk (have seen and has already been saved).

When and how to create/load and unload

I’m going to divide the world into even-sized box shapes, each frame I can check to see if the player is in a different chunk than he was in the last frame. If so, we would move all chunks that are now outside of the new viewable area into a “cleanup chunks” list, and then add new empty chunks to a “new chunks” list.

Each frame afterward, we would save one chunk from the “cleanup chunks” list, and load or create one chunk in the “new chunks” list.

When the game is quit, all active chunks would be saved to file before we exit.

Dealing with wraparound

I like the idea of an infinite amount of play space, but it really isn’t needed. I have tried to go to The End Of The World in Minecraft, and I gave up long before I got close. There’s just no need to have that much space. I’m not going to be doing that.

An entire world will be a large rectangular map. Right now, I’m generating chaotically random worlds – there’s no rhyme or reason to the placement of anything, Anywhere Is Fine. I don’t have to deal with the placement of things yet, but I do have to deal with world wraparound. Since the world has a set size, chunks at X= 0 and 255 will share an edge, and objects will have to be able to see each other from one side to the other.

I plan on setting it up so that when the player reaches the new chunk, he will be suspended in space and the chunk under him will be replaced with the one that he’s moving into, and then he’ll be shoved back the entire width of the chunk. This will keep him in the 0..chunk_width play space – and he will never actually leave it. When he has “left” it, everything moves in such a way as to keep him within it. Chunks at the world’s edge are treated as a relatively positioned chunk, the same way as non-bordered chunks are. This saves me the trouble of having to deal with tricky math at the seams, since everything is positioned relative to the player rather than in absolute world coordinates.

Looking forward, I’m going to eventually be restricting placement of resources to a grid, and afterward I’ll be making the world into a 2d blockmap. Once these systems are in place, I’ll be once again looking at libnoise to generate ‘pretty’ worlds, and I’ll have to deal with world-edge seams. I’ll deal with that when I get there.

Wrapping up

It seems pretty straightforward now that I’ve written it all out. After a break, I’m gonna get started on the code.

Item creation Interface Design

March 1, 2012

Since I’m writing it all out anyways, I may as well write it out as a post.

First up, I know I don’t want to have to arrange items on a surface, like in Minecraft. Terraria’s item creation sets up a list of things you can make with what you have, and you scroll through that list and pick the one you want. That will work for now.

Let’s assume the following simple recipes:


  • Workbench: Wood (5)


  • Copper Bar: Copper Ore (5)


  • Workbench: Wood (5)
  • Chest: Wood (5)
  • Copper Sword: Copper Bar (5)
  • Copper Armor: Copper Bar (10)
  • Copper Shield: Copper Bar (2), Wood (2)

(Nevermind the shield recipe, I just wanted to have a recipe with multiple materials so I’ll have an example to use for when I actually code things. I also purposefully have workbench in two different lists to force me to deal with overlap. The hellstone forge in Terraria, for instance, can create all of the items that the normal forge can, along with more..)

Now let’s say you’ve got a couple of stacks of wood and copper ores. When you ‘use’ a forge or workbench, all recipes available via that object should appear in a 2nd pane next to your item list. (Let’s see if I can get html tables to work in wordpress:)


>copper sword<
wood (99)
wood (99)
copper ore (99)
copper ore (99)
copper bar (8)


Workbench: Wood (5)
[Chest: Wood (5)]
Copper Sword: Copper Bar (5)
Copper Armor: Copper Bar (10)
Copper Shield: Copper Bar (2), Wood (2)

(Meh, that doesn’t look all that great, but it serves its purpose)

The workbench shows all things you can make using it, and those that you don’t have materials enough for will appear in red. The selection cursor will be locked to the righthand pane while you’re in the item creation interface, since you don’t have any reason to be choosing your own items.

Here I have the shield selected, and when I press A, it will make one and place it in the next available {empty} slot or add to the first similar stack (unless there’s no room!).

The only tricky part is how I’m going to define the recipes, because I don’t want it to be a chore to add new recipe sets to objects. I’m going to need 3 recipe lists, and I have to deal with overlaps.

Hopefully my next post will be a screenshot of a fully working interface.

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.

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!

SG’s Game Development Video Diary ep 8

February 16, 2012

I made a vid about the stuff I’ve updated since I started up the blog. As always, sorry about the sharp “S”es. I don’t have any way to soften those yet. Here it is:

NPC AI Design

February 14, 2012

The next two logical steps are to give the NPCs their wanderer AI, and to add monsters that will hunt them. I’ll get a basic wanderer AI in, and then I’ll tackle adding the first monsters.


Let’s go over the wanderer AI again. You place a Town Center block, and after some time passes an NPC will spawn some distance from it. The NPC will wander around randomly from that spot, with a tendency to go towards the Town Center. Once they reach a minimum distance from the Town Center, near enough to it to be considered “within the town”, they’ll wander completely randomly. The wanderer AI will keep them within that minimum radius: when they go outside the “town limits” they’ll once again tend to move towards the Town Center.


The NPC will spawn at a pretty far distance away from the Town Center, though I’ll have to play with the exact number during playtesting to find a good one. I think it will be fine to let the distance be a constant, since it will be a random direction from the Town Center and that should make for a decent spawn distribution.

In what cases should the spawning fail, and how should that be handled? I don’t think they should be able to spawn too close to the player – having anything suddenly popping into existence near me would startle me. The spawning should also fail if the NPC would wind up over water. I don’t think anyone’s going to be wandering in the sea. Another obvious case is if they spawn within a solid block.

If it’s determined that the spawning failed, then the game will wait until the next frame before it tries again. I don’t want to halt the system if you put the Town Center block in the middle of the ocean. I could try to come up with a way for the Town Center to build a list of valid spots and then spawn in one of those, but I wont bother for now. I’m more concerned with seeing results than making the game run perfectly.

When the Town Block is placed, after a period of time it will try to spawn an NPC. I would think that 1min or something would be reasonable but this is another value I’ll have to play with during playtesting. After that length of time has passed, the Town Block will try to spawn a new NPC. Once the NPC has successfully spawned the block will check the number of NPCs against the NPC count maximum. If there’s room for more, it will start the timer up again to spawn a new one. If there isn’t room it will enter an idling state, waiting until there’s room for a new NPC – whether an NPC dies or the town levels up.


The ‘wandering’ process will have two states: moving and idling. The NPC will idle for a time period and then will decide on a direction to move and how long/far to move. While the NPC is moving, they will need to deal with stepping up blocks, and I’ll have to allow them to jump. At the end of the moving period the NPC will choose the length of time to idle, and re-enter the idle state.

When the NPC is deciding on a direction. they’ll start by picking one completely at random. The speed and length of time to move will be consistent, only the direction will be chosen. If the NPC is outside of the town limit, a vector towards the Town Center block will be added to the chosen direction, and the resulting vector will be normalized and used.

I’ll need the NPC to figure out when they’ll need to jump. I was thinking that if they were trying to move forward but hadn’t moved from the spot they were in last frame, that they aught to try to jump. This will solve the simplest cases, but has problems if they’re walking into an L corner that was 2 blocks high, like this:

I’ll look at more complicated pathfinding at another time.

About the Town Center

The distance from the Town Center block to the “town limits” is going to be another value I’ll have to play around with. Within this distance, NPC wanderer AI will stop bothering to try to go towards the Town Center when they choose their wandering direction.

The game will need to keep track of where the Town Center block is at if it’s moved. The way I’ll deal with it for now is that whenever you place a Town Center block, it will change the location of it. I will be limiting the number of Town Center blocks to one in the entire world, and I’ll be dealing with the case when the Town Center block has been removed.