Conflicted Gamer

Thoughts on my Pac-Man prototype

2012-01-04T23:49:00.000-08:00

I put some thought into my Pac-Man-esque dungeon crawler and pondered ways that I could streamline it and make it more fun without giving up the elements I really wanted in it. In short: I like turn-based combat systems with a variety of characters to choose from, but the current battle system itself to be integrated into the overall dungeon instead of being its own separate system.

So I'm leaning towards showing a party list on the left side of the screen and a more zoomed in view of the dungeon while showing the party leader as the character traversing the halls. You can click on any member on the list to make them the current leader instantly without having to switch their order. If you come in contact with an enemy, you need only press an arrow key to have the leader attack the enemy with whatever spell or item is currently equipped. And, if the enemy is too powerful, you can disengage and run off in another direction.

Of course, this also means that the enemy could potentially gang up on the team, surrounding them on all four sides...heheh.

Using queued functions in ActionScript

2011-12-30T23:32:00.000-08:00

[I apologize in advance if the formatting on any code examples looks wonky... I have to do it all by hand since, as far as I know, Blogger doesn't offer any way to show formatted code]

Back when I was working on an aquarium simulation game for Facebook (the game was unfortunately killed off in July), I kept running into issues where I'd have to do a series of actions that needed to be executed in a specific order and then return the game to a specific state. For example, if the player wanted to purchase an item from the in-game shop, you might have to:

Send a request to the server to have the player purchase a particular item
Lock the screen so that the player couldn't click on any buttons while the game waited for a response
Show a loading animation so that the player knew that the game didn't pause or break
Process the response
Remove the loading animation and relay the result of said response back to the player

But THEN different items required different actions. If an item was to be immediately placed in the world, you'd have to:

Remove the store UI and clean up any event listeners
Unlock the screen
Place the item at the player's cursor
Go into placement mode

But what if the item was placed directly in the player's inventory instead and you didn't want to close the store in case they want to continue shopping? Then you'd:

Show a confirmation window with a message
Upon reading the response, the player clicks on a button stating what to do next
Unlock the screen (if reasonable)

My favorite series of actions? Visiting another friend's aquarium.

Lock the screen
Show a loading animation
If the game is waiting for the server to respond to the last save request, wait for the response
If there are other actions to be saved, save AGAIN and wait for the response
Once everything checks out, request the data for the friend the player is trying to visit, wait for the response
Fade the screen out
Clear the game world
Repopulate with the new aquarium data
Wait for all the assets to load
Fade the screen in
Hide the loader animation
Disable any UI that's not necessary when viewing a friend's aquarium
Unlock the screen

For a long time, this proved to be a nightmare whenever we wanted to add another sequence of actions, especially once that had to get information from the server. I used a lot of different URL loaders and game state variables to keep the functionality specific.

After while my brain got smart and I searched for an easier way to try and make this as painless as possible. And, after much digging around on Google, I came up with a pretty simple solution.*

It turns out that each function is an object in ActionScript that also has its own set of functions! Two very useful ones are "call" and "apply". Both are similar in nature; the difference is that "call" lets you specify the function parameters as "rest" while "apply" wants the parameters stored in an array.

Using them is easy. Lets say we have a function called add that looks like this:

public function add(a:int, b:int):int { return (a+b);}

If we want to call the function later to add 5 and 2, we can do this:

var func:Function = add;
var params:Array = [5,2];
[...other code here...]
var answer:int = func.apply(null, params);

Or, if you want to use the call method:

var answer:int = func.call(null, 5, 2);

Please note that the first parameter in "call" and "apply" is simply a desired reference to the object calling the function. In both cases, you can get away with passing in null.

With that in mind, I created a queuing class that I can push pretty much any series of actions into using only a few grouped lines of code. This has come in handy especially when I'm trying to do some fast prototyping for my games. Best of all, since most (if not all) of the commands to handle the sequence can be dished out one line after the other, it's easy to make changes to the sequence and you don't have to keep track of as many variables.

I strive (present tense: I'm still working on it) to make the queuing as flexible as possible. There are a variety of different actions that it can perform, so there's a function for each type of action:

Queue.call(func, ...params) - call a function only once
Queue.query(func, ...params) - call a function once each frame cycle until the function returns "true"
Queue.pause(time, useFrames) - pause the queue for the specified number of milliseconds (or for a certain number of frames if useFrames is set to "true")
Queue.repeat(time, useFrames, func, ...params) - I literally added this one today; calls a function repeatedly for the specified amount of time. You could technically merge this and the pause function and simply default the func param to null, but I like to keep them separate.

You can add several different types of actions to put into the queue depending on your needs--in other versions I created at work, I added in functions to load data and media from URLs using specific event listeners.

In my code, each action that goes into the queue is attached to an instance of a class called QueuedAction, which is then pushed into an array. When it comes time to execute the action, I do this:

var finished:Boolean = _currentQueuedAction.execute();

And execute function does this:

public function execute():Boolean {
if ( !_isExpired ) {
switch( _type ) {
case FUNCTION:
_func.apply( null, _params );
   _isExpired = true;
   break;
case QUERY:
  _isExpired = _func.apply( null, _params );
  break;
  [...other case statements here...]
}
}
return _isExpired;
}

The Queue holds on to the current QueuedAction outside of the array and will call it once per frame cycle until the current QueuedAction returns "true". Then, it nullifies it and grabs the next QueuedAction in the array if there is one. You can update the queue manually through a single "update" function if you want to maintain full control, or you can add an "autoStart" flag like I did to have the queue run automatically as long as there are actions to be executed.

Why have a reference to the current QueuedAction outside of the array? It would be faster to just reference the first QueuedAction in the array directly.

The reason being that I have the Queue class set to push actions to the back of the sequence AND to the front as well. If I decide I need to execute another set of instructions immediately after the current one, I can push them onto the front of the array without fear of losing my current action. I have a separate set of functions for this that are nearly identical to the ones above called Queue.nextCall, Queue.nextQuery, etc.

Okay, example time: let's say I'm working on a game prototype with turn-based combat (my favorite!) and I want to whip together a quick sequence to show an attack animation.

I'll use my queuing system (and an open source Tweener class) to make it easier:

q = new Queue(); // our queue
var attacker:Actor; // our lead guy
var target:Actor; // our bad guy and future victim
// The Actor class is pretty much a sprite. Has x and y coordinates.
// first use the tweener to quickly move the attacker to his target
q.call( Tweener.addTween, attacker, { x: target.x, time: 0.05, transition:"linear" } );
// check if the actor is done tweening
// NOTE: the isDoneTweening function is a function I added to the Tweener class
q.query( Tweener.isDoneTweening, attacker );
// show the attack animation and wait for it to finish
q.query( attacker.attackAnim )
// call the function to deal damage.
q.call( attacker.dealDamageTo, target );
// play the impact animation
q.query( target.impactAnim );
// pause the queue for 200 milliseconds
q.pause( 200 );
// move the attacker back to its original position
q.call( Tweener.addTween, attacker, { x: attacker.originX, time: 0.1 } );
// wait for the animation to finish, then continue
q.query( Tweener.isDoneTweening, attacker );
// We're done! Next turn
q.call( nextTurn );

It's pretty simple! And if I want to change the order of anything, everything I need to mess with is in one section of code.

Some may ask why it's not a static class (i.e. my former coworker Philip :P ) and the reason being that sometimes it's useful to have multiple queues going on at once. For example, after I created the Queue class I worked on a ranch themed game that allowed the user to queue up multiple actions at once. Each action would show a progress bar count up from 1 to 100 and then remove the progress bar and process the request. Originally, all actions were pushed into a single queue and executed in order and it was relatively easy to keep track of just one progress bar. I used my Queue class to take care of it relatively easily.

However, the game designers decided that this took too long and hindered gameplay. They came to me and asked that I make certain actions (but not all of them) act independently. Specifically, any actions dealing with plants (harvesting, plowing, planting) would go into one sequence. Anything outside of that (feeding a cow, tending to a machine) would have its own separate queue. This also means keeping track of multiple progress bars on the screen.

So I set it up so that animals and machines had their own queue. This allowed for much faster progress and multiple progress bars to be displayed at once without having to keep a reference to all of them in the controlling class.

There was, however, a downside: we later implemented a kind of automated functionality for animals and machines, meaning the player didn't have to interact with them in order for them to work. Very useful if you had a large ranch with a lot of stuff in it. But that also meant there were a LOT of functions getting called and progress bars flying up onto the screen at once. On slower computers, the game really started to chug!

With that in mind, I mainly use the Queue class a lot to get prototypes done rather quickly if it can easily be applied. But for final applications, it's a good idea to see if it's really necessary first. Obviously, since your calling a function in the Queue to update a function in the QueuedAction to call the function of a function object, you're pushing and popping onto the Flash call stack A LOT. If you're super anal about performance, there may be other options to seek.

But that aside, it can get really solve some major problems and potentially produce cleaner code in the process.

One last thing to note: similar functionality can be called in other programming languages. For example, in Python, you can call a function like so:

def add(a,b):
return a+b
func = add
params = [5,2]
func(*params)

And based on some quick Googling, it's also possible to do this in Java (though there are significantly more hoops to jump through since you can just grab a reference to a function like in ActionScript and Python).

Alright, we're pretty much done here. Hopefully, this will be of some use to you. If you have any questions or comments, feel free to leave them here!

*I came up with the solution on my own. Doesn't mean I invented it!

Still at it

2011-12-28T23:35:00.000-08:00

Holy cow, it's been an entire year since I last updated O_O A lot has happened since then and I like to think that I'm a little wiser. Of course, we all like to hold on to our delusions, don't we?

In any case, I've been coding various prototypes of different systems to see how well they work. Not many of them have lived up to my expectations, but I've gotten a few gems out of a couple of them.

One was my Collapse-esque clone that I made a while back. I've been stuck on how to iterate it further, but some ideas came to me recently (literally last week) that I think are probably worth pursuing. You can play the latest version here. I really want to work on this one some more, maybe make it into a full game.

My most recent prototype is based on an older idea, a dungeon crawler in the same vane as Pac Man- try to collect the dots and steer clear of enemies or battle ensues. So far, I've determine that a separate battle system actually destroys the flow of the game. I probably won't work on this game much more for the time being, but there is something there I think is worth poking around with every now and then.

I realize I should be more vocal about my prototyping so that I can learn what people like and don't like about my ideas. I hope to update this blog more as time goes on and I make more interesting discoveries.

It's been a while

2010-12-24T10:57:00.001-08:00

It's been over 5 months since my last post. Not because I didn't want to. Quite the opposite, really. I'd think of something, want to post about it, and then realize I didn't really have something to say.

A few weeks ago, I went to bed on a Saturday and conjured up a small hybrid of a game, a cross between a simple dungeon crawl and a match-3 game. I woke up the next morning and spent the entire day writing code for the game. The entire time I was writing the game, I was thinking "man, this is really weird putting these two things together. I wonder if anyone will actually get this..."

I posted a link to it for a few of my friends to play. To my surprise, a few people played it and found it fun.

Since then, I've been making various iterations of the game, trying to find a good ground between simplicity and strategy for it.

Even if the game doesn't make sense contextually, I'm having fun with it. It's been a long time since I've enjoyed writing code like this.

I'm currently in the middle of another iteration. Hopefully I'll be able to post the results here soon.

Results so far

2010-07-05T11:02:00.000-07:00

Okay, so let's review what's happened so far:

I'm going with a different gameplay and story. There was nothing wrong with the digging game I conceived several weeks ago, but because I want to use the same world as my RPG, I'm working on a different concept.

Tinkered with the Processing environment and didn't like it, so I had to setup NotePad++ as my editor. Spent a good two hours defining Processing as a new programming language for NotePad++ and setting the colors and folding for syntax. Time well spent, in my opinion.

Then I tarted doing some programming. I've learned interesting things about the different render modes (Java2D, P2D, P3D and OpenGL) and applying clipping and transformations. The game doesn't use any real 3D graphics, but I'm going to see about using the OpenGL render mode as that seems to yield the best results on my computer. However, I am aware that the OpenGL drivers on many PCs are often flawed and I'm willing to drop it if it proves to be a hindrance on other PCs.

Still trying to figure out how I want to set up the classes and how they talk to each other. Nothing interactive yet, but hopefully soon.

On programming languages...

2010-07-01T18:32:00.000-07:00

I've been thinking about the actual development process of the game lately. Specifically, which language/application would be best suited for the development.

For the record, I'm more for getting the game up and running as quickly as possible; I'm not partial to spending my time trying to set up a window in DirectX or wondering why a texture isn't displaying properly.

For this reason, I've decided to use Processing. It's a small program geared towards quickly making graphical applications in the blink of an eye. It compiles the programs to Java (and can package that in an executable) which, while bulky, is considered to be the fastest interpreted language today. On top of that, the core API is relatively small and well documented.

It is a bit of a departure for me considering that, when I am programming, I spend 99% of my time in ActionScript. In fact, I would prefer to use ActionScript as my language of choice for the game, but the inability to save files to a harddrive (even when running locally) pretty much put a damper on its usage. I could compile it as an Adobe AIR application to solve the problem, but I'd rather not make people install a program just to run a game.

So with any luck, I'll dive headlong into this over my long holiday weekend and hopefully pull something together that's playable and, god willing, fun.

Merging of ideas

2010-06-20T22:32:00.000-07:00

So I've been traveling these past few days. Went to see my dad before he goes off to take care of orphans in Africa for the rest of his life. Also went to see my girlfriend's parents for Father's Day in Bakersfield. Traveling provides opportunities for people to experience new places and things and (apparently) have fun. However, the act of getting from point A to point B, be it by car, train, plain or snail, is often regarded by many as a boring activity.

I usually use the time to get a lot of design done on comics and game stuff.

And since I have a separate blog about the comic stuff, guess what I'm posting about here?

While I do not plan on actively developing my RPG, I was delving into it's design and mechanics a bit and, on the side, the story. I really like the premise so far even if the story itself isn't completely ironed out.

I also think the idea for my other, smaller game has a lot to it given how (seemingly) simple I want it to be in comparison.

I was thinking about the stories for these two games and I want to really strive to create something very interesting and meaningful. I'm doing my best to avoid "save the world" as being the driving idea behind them. In fact, I really want these to very personal and selfish stories.

The RPG already has a fictional world that it is set in (or, rather, fictional country) with it's own backstory and tense atmosphere. But the newer game was going to have to have another story of it's own, which would take quite a bit of time to complete.

And, well, throw in the fact that I've been reading my girlfriend's copies of Sandman, and it didn't take long for me to consider setting both games in the same world to save me a bit of time and energy.

Yes, the two do have completely different designs and gameplay, but (assuming both are ever made) I think I can play up some parallels between the two rather well. And I can technically work on two games at once.

Yay!

Story (and character), anyone?

2010-04-23T22:43:00.001-07:00

In the last post, I talked about how the player would potentially have to piece together events that happened in the past as part of a game I am designing.

As a gamer, I typically I tend to value gameplay over story. I've played many games that have had interesting mechanics and have managed to enjoy them despite their absolutely terrible stories (Wild Arms 4 and Future Tactics are prime examples).

Now, I'm not looking to make the great narrative epic (in fact, I don't think I'm capable of making an epic game right now), but I am thinking of something that could help incentivize trying to get all the pieces of the story.

Obviously, the player will control a character, I'm not totally sure, but I do think that she should not be human. Nor should she have any real emotion at the start. She should be really tiny, maybe as small as a mouse.

She lives in a colony with similar creatures that don't really think about what they're doing. They just do what they do to survive. And maybe one day, while digging, she finds an artifact that tells a story.

Now, being the little hoarder she is, she just takes it back to the den, throws it on the "potentially food" pile and goes back to digging. Over time, she finds more and more inedible artifacts that seem to have a pattern to them. And, perhaps, as she begins to piece the pattern together, she becomes confused, and then astounded, at what the events that these artifacts depict. Who would make such a thing? Why? Is what these things say true? Slowly, she becomes aware of what it means to be someone. To be loved. To be feared. To be alive. After so many artifacts are found and so many stories are read, she becomes so emotionally involved that develops a quirk.

After a while, it spreads. Her small colony has taken a notice in her change of pace, of her enjoying life, of her quirks and her behavior. They start to behave differently as well. They aren't always looking for food now. They take time out to enjoy a sunset or maybe discover that it feels good to be covered in mud and even better to clean yourself up and then jump back in the mud again.

Maybe one day, the small creature brings back an artifact that tells something funny. And her colony learns to laugh.

Then, one day, the small creature brings back an artifact that tells a sad story. And the creatures learn what it means to be disappointed.

The next day, she brings back a story about someone who dies and is grieved. The creatures have experienced death before, but not really knowing what it was, simply left whoever died for three days just to make sure they weren't getting up anymore. Afterward, they'd simply eat the body and toss the bones without a second thought. But they didn't know that death meant going into uncertainty for all eternity. What comes after it? Is there anything after it? Does it just stop? That's horrible. That's unthinkable.

That's scary.

Now the creatures are afraid. They don't want to die. They become cautious of everything they do. They buddy up when they go out foraging, second guess going down the darkest burrows, some of them even begin to jump at sounds they would have usually ignored.

And then, one day, maybe the oldest goes missing.

The creatures are tearing the borrows apart searching for him. He's nowhere to be found. They call for him with the usual warning calls. They make special warning calls just for him that express a kind of love, longing and sadness. It had no meaning before they used it, but now they associate this new sound with him.

He's the first of his colony to be given a name.

Not that he ever finds out.

After days of searching, the creatures find the elder's body in one of the deepest burrows.

He's dead.

The colony is hurt. But not the physical kind of hurt, an emotional kind of hurt. They don't eat the body.

They don't know what to do with it now that they know what it means to die.

So that's my idea; start off with a character that isn't even aware of what they are or that they really exist. Give them a singular mechanic for the player to use.

Introduce an emotional catalyst. Make that the motivation for the game.

And watch as the character's world comes crumbling down.

Story, anyone?

2010-04-20T21:33:00.000-07:00

So if it wasn't obvious, I'm not at a point where I can tackle the full blown game epic-ness that I want to make. Life is just too stressful as it is right now with the job and traffic and trying to be a decent boyfriend and good roommate and surviving and all that jazz. I've thought about trying to put together a team and managing the design online, but that actually requires me to be online when I get home (which doesn't happen as much these days).

With that in mind, I've put the game on the back burner and I'm letting it simmer for a while. I'm extremely happy with the design and the story and I really want to make it. But I suppose it will have to wait.

In the mean time, I decided to visit a design for a smaller game idea that I want to flesh out. It's pretty much a game I thought of several months ago. In theory, it'd be a really simple thing to pull off and ramp up difficulty for over time. I was spending a lot of time thinking about the reasons for playing and possibly replaying such a game and thought one of the more interesting ideas would be uncovering physical artifacts that could be used to piece together some sort of tragic story. Not necessarily a story that the player's character had a part in, but something that happened several years prior where the motivations and actions of those involved are primarily unknown and there's a sort of nebulous situation that has to be sorted out by the player. And just because the pieces are retrieved doesn't mean the story is in order; rather, it would have to be put into proper order and becomes a game in itself.

Overall, I think it will work as a small, single player game.

Of course, given that I work at a company that makes Facebook games, my mind instantly started to wonder how such a game would fair in a social environment. Why would the player player want to keep at it other than boasting how they pimped out their avatar and their virtual room and all that kind of superfluous business?

And then I wondered; how would slowly uncovering a story as a collective stand in the social environment? What if you had to work with your friends on Facebook to uncover and exchange pieces of a particularly gut wrenching tale of some sort? Looking beyond the monetary aspects (I'd suck at monetizing anything) and purely focusing on the viral and emotional aspect, I really wonder how this game would hold up in such an environment.

Now, I'm not saying that I want to go ahead and do this...

But maybe... just maybe...

...This would be a good reason for me to learn php.

What what??

2010-03-13T14:19:00.000-08:00

I'll make this quick. As usual, there was another change in the design. It happened because I put an interesting twist in the way the story develops and, somehow, it caused several of my old design ideas to come collide with one another and make some sort of glorious mutation. I've managed to get almost all of the mechanics in as well as some other interesting additions and make them work together rather well. I've even managed to almost incorporate my entire board game into the mix.

Unfortunately I have to stay hush-hush about it because, probably for the first time ever, I feel that this idea is worth protecting. A bit unusual for me. Hopefully, I can set aside enough time in the coming months to actually produce something interactive if not playable.

But I will say that this is the most excited I've ever been when designing this game. There are all sorts of possibilities I can see now thanks to these developments. And I want to make sure that it does come to life.

Observations

2010-01-18T22:28:00.000-08:00

It's been a while sense I've complained--er, I mean, spoken-- about the dungeon design. Truth be told, I've been fiddling with various mechanics again, seeing which one fits and is just interesting enough to carry my fancy.

After spending too much time thinking over a lot of over complicated mechanics for dungeons, it seems I'll most likely be settling for the good ol' fashion Rogue-like design; randomly generated dungeons with lots of fierce enemies every so often. I've got some ideas for how to not make it as blisteringly difficult as a Rogue-type, though.

Firstly, all the encounters will be controlled so that it's only one-on-one combat (instead of having multiple enemies ganging up on the enemies).

Second, I plan on using a grid-based design that uses illuminated unit spaces to indicate where the player has been. When the player moves, the unit they move on to becomes fully illuminated and remains illuminated after they move. Units adjacent to it will be partially illuminated and will stay that way until the player actually moves onto them. This way, the player will be able to see where they have been (fully illuminated units) and haven't been (partially illuminated units). This will prevent the player from getting completely lost.

While I plan on keeping the game graphics simple, I do need to think of a means of adding some interesting and unique visual elements for each level. And maybe some other forms of level interaction other than just running through the dungeon.

But one step at a time, I suppose. For now, it's off to bed with me.

Later.

Second Playtest of Karmic!

2010-01-01T19:05:00.000-08:00

My roommate organized a potluck today. It was glorious.

After we played a round of Simpson's Scene It, I asked the guests if they wanted to play a round of my board game Karmic. As you'll recall, the last time I playtested Karmic was with my girlfriend's college friends. Again, I got some really good feedback.

Here are some changes that have been requested followed by my ideas on how to fix them:
-Text is too small (I will put the primary abilities on one side of the card and the secondary on the other. This will allow for more room in writing the card description. Once the primary is played, it's flipped to show the secondary.)
-Need a way to tell what abilities execute first (I'll set this to clockwise. This might add a bit more strategy)
-Need a way to keep track of your buffs/debuffs (hmm... each player has a card with the buffs/debuffs and visual markers to put on the card?)
-Need symbols to quickly identify if a card is offensive, defensive, etc (can do)
-Better graphic design (uhmmmmm I'll try?)

So when I get some time, I'll make the changes and make a new set of cards.
-Need's some graphic design

Might and Magic: Clash of Heroes

2009-12-30T19:54:00.001-08:00

I spoiled myself before Christmas came around this year; I went out and bought Might and Magic: Clash of Heroes for my Nintendo DS. The game was developed by Capy Studios (formerly known as Capybara Studios) and published by Ubisoft.

Capy is mostly known for its interesting (and somewhat disturbing) puzzle game Critter Crunch. In Critter Crunch, you move and match different colored critters on a board in different rows and columns. You can only move the lowest critter in each column, so you have to plan out where to move them in a timely manner.

Interestingly enough, Capy translated this mechanic over to Clash of Heroes very well. Both the player and their opponent have a set of colored units to move and match on their respective screens. Matching three units of the same color horizontally creates an offensive group that attacks in a certain number of turns while matching them vertically creates a defensive barrier. There are also way of making each attacker or barrier stronger. The objective, of course, is to maximize your actions in as few turns as possible. The player is given more turns if they make a single move that results in multiple groups being formed. As a result, the strategy in each battle is deep, especially when you take into account each character's special ability and the abilities of various items that can be equipped. On top of that, several bosses in the game have specific behaviors and patterns to follow that make you think differently about how you want to approach them.

In my opinion, the gameplay is much more rewarding than Puzzle Quest and paced better as well. There are some times where it gets rather difficult to win any battles (Godrick's story arc in particular leaves you screaming for a fight with someone who isn't higher level than you), but once you get past the torture, you find something that's incredibly fun and addicting.

If you've got $30, I highly recommend it.

Smarter code

2009-12-30T19:21:00.000-08:00

One of the joys of being a programmer as a profession is learning new ways to solve interesting problems.

With my recent project, I ran into a problem where there were several things the game had to do over and over for several seemingly simple actions, but sometimes these things were in a different order or had conditionals attached to them. It became a nightmare to try to think of all the possibilities and conditionals around this and in many cases the necessary actions would execute but other actions would hang around and leave the game unplayable until it was reset. Numerous bugs popped up and it only became worse when the designers asked for changes to be made to one thing because the changes would interfere with other actions as well.

To solve the problem, I wrote a queuing system that uses numerical IDs for each action. I'd pop them into a queue and they would execute in the order I wanted. Each ID corresponded to a function that would move on to the next action once it was finished. This not only simplified the process of listing the order of the actions with fewer conditional statements, but made for significantly easier to manage code. Now whenever the designers ask for changes to be made, I can usually do it by adding or altering only a few lines of code (sometimes only one line!)

Obviously, I'm glossing over a LOT of intricate details (it would be rather boring to describe all. Also, there's the issue about revealing code that technically belongs to the company...) but the morale of the story is that practice makes perfect. It's one thing to write code that works. It's another thing to set your code to be incredibly flexible when you know you're going to be making a lot of changes.

Visuals

2009-11-13T23:45:00.000-08:00

So I've actually managed to not end up hating my last idea after a few days. In fact, I realized where the inspiration for this design probably originated from: an XBox 360 game called Culdcept Saga. However, the gameplay in Culdcept Saga is more about competition than it is survival, so I'm confident that my game can stand on its own. This is very promising.

However, I am encountering issues of another manner now: visual design.

Firstly, there is the issue of using colors to discern between different types of energy to collect. But using just colors is a bad idea because some gamers may be partially or completely color blind. With that in mind, it's necessary to work patterns and/or designs into the tiles that make up the board.

In addition to this, we have to make sure the board is big enough so that the tiles can be seen easily, even with objects placed on top of them, but not too big that the player can't see what's happening on other parts of the board. I would really like to avoid implementing a way for the player to adjust the view of the game just to see everything.

I took some time and tried writing a simple random board generator to make irregularly shaped game boards, but the process has proven more challenging than I thought. The results were boards that weren't as elegantly varied in shape as I had hoped for them to be. It may be easier to simply map out a couple dozen templates and go from there.

On top of all this is a desire for the game to be presented from an isometric view point. While I think it will make it more visually appealing, it'll also be harder to work towards many of the goals above.

So right now this crazy battle over visual aesthetics is waging in my head. I'll have to see which one comes out the victor.

Nasty geometry and colors

2009-11-11T06:08:00.000-08:00

I was talking to my former roommate Al the other day and he suggested trying to use a system like D&D Miniature for the game. After he explained the system to me, I told him I was trying to go for something simpler (and less likely to kill me in production).

That did make me think about board games in general when I realized... I COMPLETELY neglected to blog about the results of my own board game being beta tested.

Back in Savannah, I made a board game that pitted players against each other on a really wonky grid. Players drew abilities and took turns attacking each other until only one remained. While it was fun, there were obvious flaws; no one really liked all the stat keeping and there wasn't much you could do once you were eliminated.

So I changed it from being "eliminate opponents" to "race to the finish" to keep everyone in the game until the end. The battle mechanics remained (the abilities changed obviously) and I set it so that each square was one of four colors. Players could attack another person on their turn as long as

The person was in the square in front of them
The person was in the square behind them
The person was in the same square as them
The person was standing on a square of the same color

There was also no HP involved; instead, if an attack was successful, the defending player had to move back a few spaces.

My incredibly awesome girlfriend convinced some friends at her college to participate in the beta test of the game. The results were good (still needs some tweaking) and I walked away rather happy.

So last night, I decided to revisit that idea and managed to take the elements from the board game and create a pretty stellar dungeon design.

Basically, the player is on a gridded pathway that encompasses an area. The pathway can be dynamically created each time and would be made to look like a rather nasty piece of geometry with be a lot of corner pieces. Each space has a random color assigned to it (haven't decided the number of colors yet), but all the corner pieces are white. Each space contains energy specific to the color.

The player has to collect a certain amount of each kind of energy in order to exit the dungeon. When the player moves they automatically draw some energy from the space they land on. If the player lands on a corner piece, they regain HP instead of drawing energy. However, landing on a corner also forces some spaces to change their color, so the field doesn't stay the same for long. A player advances by means of an in-game dice system and moves forward however much they roll for.

Monsters randomly spawn on colored spaces every now and then. The player battles any monster they cross paths with while moving. If defeated, the monster is removed from the board.

Every so often, a monster will randomly teleport to another square of the same color, so the player will have to be mindful of what color squares are around them if they want to avoid encounters.

That's the basics of the game. I do have some other ideas that add more strategy to moving, but I'll hold off on listing them for now.

Another design

2009-11-08T22:00:00.000-08:00

Here's yet another dungeon design I thought of.

Like previous designs, this one borrows from the match-three type puzzle games (such as Bejeweled).

The player has to match so many like tiles on the board before they can exit a dungeon. They can only move one tile per turn, so they have to strategize and try their best to make combos with the tiles they have available in that one turn. As you level up, you gain more points for each match you make, allowing you to progress through dungeons faster. You don't have to make a match each turn like in Bejeweled and there's no immediate penalty for not making matches.

There are a number of enemy units present in the dungeon. You can see each enemy before you encounter them and they have to march along a meter before they can get to you. Enemy units come closer to you with each turn that passes, so a turn wasted in moving a tile is more time for the enemy to advance. If one gets close enough, it will instigate one-on-one turn-based combat. You can't match any tiles while in combat and there is a chance that the enemy could consume some of the points you've accumulated and leave you with even less than what you had prior to entering the battle.

When matching tiles, you not only gain points but there is a chance that it could stop an enemy from advancing for a few turns or even deal damage to them. I'm considering other options for making the gameplay more challenging and rewarding, but that's what I have right now.

I had an idea similar to this a few months back, but the overall experience was different: the matching of the tiles was timed and it was more about getting as much as you could before the clock ran out or an enemy unit attacked. Enemies didn't wait for turns, they just came running down the meter at you at whatever speed they were set at. This made the transition from matching tiles and going into battle a much rockier experience. Suffice to say, there wasn't much strategy to this dungeon design.

Here, there's an increased emphasis on taking time to analyze the board and the enemies and making the single move that is the most beneficial to the player. It also doesn't feel quite so tacked-on as its predecessor, which pleases me. I do think this one is better, though it would have to be balanced differently to make sure the gameplay sessions don't drag on for too long.

The benefit to this design is that I can focus on adding in interesting challenges like ways of limiting player actions and randomizing board layouts without spending an exhausting amount of time on the level design.

However, I am at the disadvantage of trying to make the player understand and ACCEPT the implied relationship between the match-three design and the battle system. Puzzle Quest gets around this because the puzzle aspect is the battle system and enemy encounters are much simpler affairs (you actually can't do anything to avoid battles in PQ). This design works in the exact opposite way.

I'm half way tempted to say "f*ck it" and go with this design anyways, seeing as I've wasted so much time trying to think of dungeon designs over the past few months.

Caravaneer

2009-11-08T17:03:00.000-08:00

I searched around NewGrounds for interesting RPG games and came across Caravaneer. In a way, this game is what I'm aiming for- it has inventory management, traveling between towns and even battles. Though I don't want to get as heavy handed as this game, I think I've found what to model mine off of.

Last Remnant

2009-11-07T22:24:00.000-08:00

So while I was out looking for a new notebook, I stopped by GameStop and picked up the PC version of Square Enix's The Last Remnant. I'd heard mixed reviews about the XBox 360 version, but was curious to see how it handled on PC. I was also curious to see how my PC could handle the Unreal Engine.

The story seems to unravel very quickly. It does mean that you get to fight your first battle almost from the get-go, but there isn't a whole lot of time to get to know the characters compared to a Final Fantasy game.

Combat can seem confusing at times. I understand the idea of "deadlock", "raidlock", "interference" and "interception", but knowing exactly who what units are fighting is difficult sometimes. The camera frequently cuts from one character's actions to another and the characters' positions seem to switch all the time. Given that a lot of enemies look the same, it's not easy to tell where they stand in relation to some units on the battlefield. Perhaps this could have been addressed properly if the developers had opted for using an overhead camera.

The PC controls are also a bit confusing even though they have the controls documented in the manual. The game assumes you are playing on an XBox 360 USB controller hooked up to your PC. If not, it's still possible to play the game with the mouse and keyboard. However, while the WASD keys (used for running) have different functionality than the arrow keys (used for camera movement), they can both be used to navigate menus in the same way. With this in mind, I thought they could both be used to issue critical attacks in battle. However, that seems to be exclusively tied to the arrow keys. It took me several tries to figure this out and I can't say that I'm too pleased with the decision.

I've only played through two missions so far, both of which were very brief (and I do mean VERY brief by JRPG standards). I'm only three hours into the game, so I'm holding out for a more promising experience as I progress.

Inventory management and gameplay

2009-11-06T23:10:00.000-08:00

Inventory management is something I can't say I like very much in many RPGs. Simply because in most games, the items only have value up until a certain point. Especially equipment--it's only useful until you get a stronger sword/shield/armor. I can't say I'm a fan of this kind of inventory management.

For that reason, I was purposely avoiding much of it with my game design. My original plan was to make any items the player picked up consumable and that was that.

Obviously, over the past few months, I've been struggling with trying to think of a good, low-maintenance dungeon design for the game. Most of what I came up with was very conflicting with my overall goals-- they were either too much for one person to tackle or were too much of their own kind of game and did not work out well with the battle system I conceived.

I want the game to be very story driven, and I convinced myself that the overall experience should be about the journey (and, of course, well-paced battles with ugly monsters. We can't forget that). So I got to thinking of streamlining the "journeying" aspect as much as possible... as in, what happens when you remove a lot of the interactive elements and have just a bare-bones system for getting from one place to another? I figured the lowest level of interaction would be to have the player's character simply auto-run through a level in a single direction. You can't get lost. Enemies would not have to move because the character would be running at them and encounter them anyways.

Then I thought about how to make that more challenging... First I thought of a time limit, but that would be silly. So then I thought of extended gameplay affecting the character's health, just like in Persona 3, Dark Cloud and Shiren: The Wanderer. The longer you're in a dungeon, the more it drains your energy which, in turn, slows down how fast your character progresses.

Now, how to make it so that the player can interact with this system and affect the outcome?

Inventory management.

So now my idea is quests are on an auto-journey mechanic where the character progresses as fast as they can through a dungeon. As they continue forward, their energy decreases. Once their energy is gone, it starts to drain their health and they risk expiring even outside of battles. This can be mitigated by resting in a dungeon (which risks monsters entering and leaving) or feeding the character an item from the inventory. This also allows me to have better paced battles and implement random events.

Other factors I'm considering are the implied terrain, traps and a weather.

If I go with this design, the game will actually become even more of an RPG. It's much more straight forward than the other ideas I've had and easier to implement as well.

Just hope something good comes out of this one.

Back again

2009-10-22T17:51:00.000-07:00

So after all the designing I've done, I found that I was still lamenting over the controls for my Pac-man like prototype not working the way I wanted. Eventually, all this angst subsided and I eventually worked myself back into an intelligible state and asked myself:

"How do other Pac-man clones do it?"

So I did a quick search for Pac-Man clones made in Flash and came up with some promising results. The best of which seems to use auto-movement with cuing the change in direction instead of actually providing tight controls for turning corners.

After about half an hour of fooling around with my code, I managed to implement this in my own prototype. The results are spot on for the most part.

So for now, I'm pleased. We'll see how I feel about it tomorrow.

Still working on it

2009-10-20T21:33:00.000-07:00

Again, not content with the last design, I've been hammering away at the dungeon set up over the past few days. Each design that comes to me has unique pluses and several damning minuses. Revisiting old designs and approaching them from new directions has helped some. Currently, I'm not siding with anything in particular, even if the concept seems promising. I'll go to sleep thinking about it and then find some flaw with it in the morning.

Designing with self-imposed limitations has certainly caused me a headache, but has also been a bit of a learning experience. I also can't help but think about how professional designers have the luxury of a dedicated development team and how much easier that must be for them to prototype and build upon more complex designs. I haven't sought out a team because of my past experiences; it's easy to tell people they should work on your game because it'll be a fun experience, but it's hard to live up to the promise. Often times, it becomes aware to the team members that the idea is not thought out in its entirety or that the scope of the game is beyond their current ability or takes too much dedication. It's like leading people through the desert with the promise that there's water.

I've decided that if I'm going to suffer with designing this game, it's best not to have others suffer along side me.

I have yet another design written down in my sketchbook. By the morning, I expect to burn it :)

Toodles.

Designing in my sleep

2009-10-12T06:31:00.000-07:00

While I was tossing and turning in bed last night, I was going over the various designs for the dungeons in my head. I thought back to the Pac-Man design and what was wrong with the prototype. Specifically, that it was hard to maneuver. I also still wanted to implement an auto-run as opposed to a completely player controlled run. The best way I had gotten around this so far was making the movement completely turn-based like a Rogue-type, moving one unit at a time.

Then, a solution came to me.

The movement partially turn-based instead. So the player would not move from unit to unit, but would instead move from one intersection to another. Then, all characters would stop while the player decides if they want to keep going forward or turn in a different direction. Since they can only decide where to go when they come to an intersection, it adds a bit of strategy to make sure they don't run into enemies that may be on the same path as them.

Adding to this, enemies could move at different speeds (something that would have been crippled greatly with complete turn-based movement).

So it seems that my weekend full of game design concluded on a pretty high note around 1AM this morning. This makes me extremely happy.

What a weekend

2009-10-11T11:56:00.000-07:00

Because of Canabalt, I've been flying through dungeon design ideas and honing them into something that seems really interesting. As I predicted, I didn't stick with the running mechanic, but playing the game over and over (and over) has helped me discover issues with older designs and find out ways to make them better.

I'm currently making screen mockups for one of the designs. I think it has quite a bit of potential and is easier to deal with. The problem so far is that the layout is outright fugly at the moment. So I need to find a way to make it look more aesthetically pleasing and less cluttered.

Canabalt

2009-10-09T21:39:00.000-07:00

So I've been doing a lot of pondering lately. A lot of it has yielded some interesting gameplay designs, but nothing that really sticks and promotes the idea of getting into battles. They all either competed with the battling gameplay or operated as an outside system that didn't really mesh all that well with what I had in store.

I've been looking at trailers for other games to try and listening to a lot of music to try and get inspired. Again, interesting results, but nothing I'm sold on.

Then, tonight, I followed a link to an interesting Flash version of an iPhone game called Canabalt. It's a very simple game: run as far as you can, click to jump, and try not to die.

It's quite addicting. I've been playing it a lot, but I can only get to 2700 meters.

After I managed to pull myself away (I will undoubtedly go back for more punishment in the future), I thought about using a similar mechanic.

Have the player character auto run in a direction. Run back and forth and jump to avoid or encounter enemies. Different enemies move in different ways, so you'd have to be careful with controlling your character.

I've only thought about it for the past hour or so, but the design seems to have quite a bit of potential to me. It'd be easy to implement, the art assets could be made quickly, and I can expand upon the challenges and goals easily. Obviously you wouldn't run as fast as you do in Canabalt or say Sonic the Hedgehog, but there could be some speed increases as well. It manages to encompass a lot of what I want in the design: tension, avoidance and a bit of skill even. And the context can be applied to many different situations and environments.

No doubt I'll be thinking this one over a lot this weekend. I hope something good comes of it, even if I don't use the design fully.

New design

2009-09-26T23:19:00.000-07:00

So after the utter failure of my dungeon prototype, I took a day to mull over dungeon design a bit for the game. My goals were still simple-- Having a design that promoted encounters and gave a feeling of tension but remained simple enough in mechanics that it did not overshadow battles.

After some thinking, I looked back at a previous design I hadn't taken the time to formally document other than doing a rough sketch for. Instead of taking cues from match-3 puzzle games or Pac-Man, this one borrows from Namco's Dig Dug. Therefore, if I go with this design, it will have to have digging as the premise. I lose some flexibility in the story, but it may provide a solid foundation for this game to stand on. It would also be a turn-based action to move around the environment, so there would not be a lot of frustration with keyboard or mouse input.

On top of that, it also greatly cuts down on the number of animations I would have otherwise had to make for the game and allows me to increase the resolution of the sprites I would use and create more elaborate backgrounds.

While I'm still exploring other possibilities, this is the design I'm leaning towards now. I'm fiddling around with one or two additional features, but I'm liking where it's going so far.

Prototype round 2

2009-09-25T22:13:00.000-07:00

Since I was planning on my levels on being like Pac-Man, I wanted to try and see what would be an appropriate size for the game. So I popped open FlashDevelop and did a quick and dirty prototype.

Here's a screenshot of what I had:

Well, the size of the level was fine for me... but I've discovered a new problem.

I wanted to avoid Pac-Man's auto moving and instead have the characer (that red circle) move only when the user pressed a key. I quickly found out the more control I gave the player over the character, the more difficult it was to move around the level. This is because I wanted the character to stay locked to the center of the cleared paths. It made it very easy to overshoot a turn and then become unable to turn because you weren't aligned properly to do so.

I've found that this is solved if I make it more like a Rogue-like. That is, when you press the key, it moves your character a certain distance before pausing and checking for key-presses again. But using turn-based movement destroys some design ideas that I had.

Hmm... looks like this might take longer than I thought.

[UPDATE]
Bit the bullet and tested out more Pac-Man like controls. Very agitating when playing on a keyboard. Will have to think this through some more.

Story ideas

2009-09-15T19:05:00.000-07:00

I'm throwing around a couple of story ideas for the game.

I did write one up and show it to a few friends. It dealt with being a tax collector and they thought the idea was interesting.

But I'm wondering if I should make the story more personal for the main character. Being a tax collector is a job and I can't really think of a good way for her to "grow" as a character in that position. She needs to have more personal interest in what she's doing.

Given the game mechanics, what would make a good none-save-the-world story about a person willingly braving a dungeon and collecting the spoils?

I'm thinking tuition for college...

Render tests successful

2009-09-11T19:54:00.001-07:00

Dug around a bit in my render code and managed to get some transformation effects working!

Take a look:

This makes me immensely happy :) Now, have to put it on hold a bit and get some other stuff done. Ah, priorities....

Quick code test

2009-09-10T17:46:00.001-07:00

One of my greatest annoyances is having to dig through other people's code to try and find out how something works. It's not that the code isn't well documented or poorly written... it's just trying to piece everything together and, considering that I've not been a part of a large project involving lots of code (or at least one that was publicly released...), I'm not too well versed in different kinds of code architecture. Having to track down various functions over several classes (and files) is not really my idea of a good time.

However, I bit the bullet and took some time this week to look through the Ren'Py source code to see if I what I could do with getting moving, rotating, and scaling characters inside of a Ren'Py render.

Moving them around was pretty easy. Rotating and scaling was a bit more of a challenge and I had to drop a line on the forum to get the answer (thanks, PyTom!)

Now, because I know that I can do nearly everything I need with it, I'm pretty confident that Ren'Py will be the platform I use for the game. Which is awesome because I love that I can create a Mac and PC executable without changing the code at all :)

The next step (possibly some time later this month, as I have more pressing matters to attend to) is getting an entity manager together to control characters on the screen.

Dungeons and Story

2009-09-08T12:30:00.000-07:00

So I spent a good part of this weekend thinking about the level designs.

...While at Disney Land.

...I'm surprised my girlfriend puts up with me with these things >.>

Anyway, I'm leaning more towards a Pac-Man like design now; the player runs around a level and collects various things while monsters are trying to stop them. While combat will still be turn-based, the dungeon running will be real time. Enemies will also have spawn points and number caps so that the player can't eliminate all enemies and there can never be an excessive number of enemies present at once. I've also managed to make a list of various challenges to introduce over the course of the dungeon crawling. Though this again puts me in a difficult position from a technical and development standpoint because:
1) I'm weighing the advantages/disadvantages of using Ren'Py or Processing,
2) I have to design all levels,
3) I have to plan for each monster to have walking animations in four different directions, and
4) Path finding (but not A*, thank god)...

Overall, though, I'm happier with this approach because it facilitates the tension that I was seeking from the beginning and has actually managed to streamline much of my designs in terms of user interface and controller input.

From the beginning, though, I've been considering stories that are reinforced by the play mechanics. When I had the puzzle-dungeon design, I had a rather serious story in mind that dealt with mastering magic and getting revenge. Now, I think the new dungeon mechanics allow for something more whimsical and light hearted, but while still allowing for all sorts of monster bashing action.

...Like moving up the corporate ladder :)

Late night thinking

2009-09-04T08:51:00.001-07:00

Last night, I took the time to think about the level design issues I was having with my game (well, while I was trying to avoid being tickled by my girlfriend. Multitasking isn't my strong suit when it comes to things like this...)

There was something that wasn't clicking about the game and I was struggling to figure out what it was.

Here's what I came up with:
Originally, when I started thinking about designing a game years ago, it was because I didn't like how combat was handled in a lot of RPGs. If you stumbled into a place where the enemy was very strong, it was up to the computer to decide results and you were pretty much assured a quick death if you didn't get the hell out as fast as you could.

Combat is what I find the most interesting in most RPGs, especially of the turn-based variety. That's why I designed the combat system first and... well... everything else second.

And that's what the problem has been.

In game design, they say it's good to focus on the core gameplay and find things that support it.

I originally started out with this in mind a lot better in the beginning as I strove to make a strategy RPG. Strategy RPGs are combat intense. But they are also very drawn out and exhausting and I wanted something where combat would be quick and more exciting. So I turned to a more traditional JRPG design.

But then another problem arose... in my opinion, while combat plays a key role in most JRPGs, it is not the main focus. There is a lot to be found in exploration, NPC interaction, inventory management and character building as well.

But I've learned that I don't really care about those things. I want to focus on the tension caused between the player's character and the enemy. Yet I was trying to create dungeons that promoted other aspects that were gravely lacking or not fully contributing to the game that I was trying to design.

My previous dungeon designs were trying to find something for the player to do while not engaged in combat (i.e. waiting for enemies to encounter) and still drive story progression. But I wanted them to be simple enough so that I could avoid things that made me angry about dungeon designs (like getting lost or stuck). Hence, the puzzle game dungeon design. I decided I wanted something more engaging that stimulated finding objects and treasures and moved on from that, which is what I was hinting at with last night's post. Perhaps, I thought, exploration would have more of a draw.

But after much thought (and suffering from much of the aforementioned tickling), I see that I really should stick to what supports my core--combat.

So now, once again, it is back to the drawing board. I'm looking at more games that facilitate tension between the player, the enemy, and the environment. Encounters should be quick, dangerous, and have a bit of strategy.

There are two games I've found so far that do this pretty well.

The (obviously) older of the two is the original Pac Man.
The other one, quite well designed and fun to play, is Knight Fall 2.

Where will these games take me and what will they inspire? I dunno yet. But I'll be sure to keep documenting my thoughts on the subject when more things come to light.

Rough waters

2009-09-03T18:52:00.000-07:00

The puzzle-as-dungeon design is officially toast. The reasons were that I wanted a better way of integrating enemies into the level as well as better immersion (i.e. being able to see the character on the level as opposed to just a portrait).

I'm still incredibly fixated on MineSweeper and I think that I've managed to come up with a dungeon design that mimic's MineSweeper's tension a lot better than the previous design. Still working out the kinks as I only thought of it today.

More details as the design evolves.

Design progression

2009-08-20T20:54:00.000-07:00

Ah, dear, dear blog. I have neglected you.

Between work and Lumia's Kingdom and outings and my girlfriend, I've found little time to document my progress on the game. Well, here's a little something to hold on to for now.

I've simplified the design of the magic casting and energy gathering for the game. Instead of having MP that scales with the level, the player has charges similar to Final Fantasy 3. When a player casts a spell or uses a special ability, at least one charge is used. Depending on the spell/ability, multiple charges may be used. No matter what level they are at, the player will have a maximum of either 6 or 7 charges (I haven't decided which one yet).

When in battle, one charge is regenerated every 2 turns. I've not decided how charging works outside of battle.

The puzzle-as-exploration aspect of the game still stands, though I've argued with myself over it quite a bit. I'm striving to introduce obstacles that can temporarily prevent the player from generating energy to progress in a level/dungeon. I only have about 2 ideas (that can be implemented so that each has multiple obstruction patterns) and I'm hoping to generate more soon.

Development software of choice at the moment is still Ren'Py because of its simplicity and cross-platform nature. However, if I do decide to take a more hard-core approach to coding the game, I might try out Processing. It compiles to Java and even has an option to embed in an .exe file. I'm doing my best to use platforms that compile to an intermediate byte code on a per-file basis (such as Python or Java) instead of compiling into one large file (like C and ActionScript).

The story has also mutated a bit, as I'm attempting to try something outside of the norm for an RPG.

I hope to have free time soon to actually work on some coding aspect of the game. Hope is a very big word and, unfortunately, it's not looking too hopeful in the immediate future. Regardless, I will press on.

New DS game

2009-07-26T14:40:00.000-07:00

I got a new DS game on Thursday-- Puzzle Kingdoms. It's supposedly created by the makers of Puzzle Quest, but doesn't seem to have been developed by D3.

In any case, I did a few quick battle before embarking on a campaign. I noticed quite a few differences in the two games. Firstly, while there is a match-3 design implemented in both, Puzzle Quest takes it's rule set from Bejeweled--every move has to create a match. If there are no matches, the board is cleared. On top of that, matching tiles must be in a straight line in order for it to be a valid move. Tiles only fall from the top and you can't see what tiles are going to fall next.

Puzzle Kingdoms doesn't adhere to this ruleset. Every move does not have to make a match (and the board doesn't clear when there are no apparent matches), the tiles don't have to be in a straight line to count, tiles can come from any of the four sides of the board, you can see what tiles will appear next.

Adding to these differences, you have troops in Puzzle Kingdoms. The troops are govered by a hero character. Each troop has a charge meter and matching certain color tiles charges their energy. Once their energy is charged, they can attack rival troops. The battle ends when one of the hero character has no more troops.

Every matching move gives energy to the hero character, adding to a meter they have beside their profile picture. Once the meter is full enough, the hero character can cast spells that can help their troops or affect tiles on the board.

In short, it's sort of like Puzzle Quest has been mixed with King's Bounty and the result is Puzzle Kingdoms. The result is (so far) is a pretty fun game that is pretty deep in strategy and holds a bit of RPG elements.

Of course, the feeling of aggravation is still there when you can't see a good move to make or you make a move and then it causes the computer to make a move that results in a devastating chain.

The only problem I've encountered so far is the menu for your kingdom. Several times, I clicked on one button in the menu and another button was activated. This is incredibly aggravating.

I've not put too much time into the game yet, so hopefully there's more to discover and add to the overall experience. Here's hoping.

Flash prototyping and board games

2009-07-26T14:32:00.000-07:00

This weekend, I put in about 5 hours worth of work on a quick and dirty Flash prototype for the game to get a good feeling of how it the dungeons would work out. So far, the results have been pretty good. There's no battles involved yet, but the monsters do approach the player while they are working the puzzle aspect and a spell menu does pop up when you target a monster.

This also gave me an idea for later; I can upload the Flash prototype to my webhost and then link to it on help wanted posts when it comes time to recruit.

I'm also working on turning one of the systems into a card-based board game. I've got two more card types to go before I start executing this (which will hopefully be sometime next week).

For now, though, I've other things to catch up on.

...Wait a minnit!

2009-07-03T14:38:00.001-07:00

In the last post, I commented on how my prototype made me realize the flaw in my dungeon design because it splitting the player's attention. Then, I realized something; there might not be a flaw in my dungeon design, but my prototype design.

The prototype I was working on was technically for a project at work. And the design for it was not 100% reflective of what I wanted to make for my RPG. It had very similar elements, but there was a few major differences.

In both designs, you can see the enemy advancing towards you and can take proactive measures to build up your strength/resources and attack them before they reach you. However, the prototype was more of a strategy game than an RPG and, because it was a Flash game meant to be played in a web browser, it had a smaller resolution of 640 x 480. Also, there were more enemies advancing on you than what the RPG would have. Because of this, the field where the enemy spawned was larger than the viewing area and had to take time to look around to see where the enemy was coming from. This was what was diverting the player's attention. But in the actual dungeon design for the RPG, you can just glance over and see how close the enemy is. There is no need to stop what you're doing to see where the enemy is.

So I think that my design for the prototype I was making was seriously flawed. But my design for the RPG might not be quite so flawed as I thought.

I feel a slight relief at this realization. Now I have time do focus on other aspects of the gameplay and progression.

Prototyping

2009-06-30T17:59:00.001-07:00

One of the advantages of working where I do is that I sometimes get to prototype my own ideas. So it's no surprise that I've been using this to my advantage for my RPG. It's given me some interesting insight to what works and what doesn't.

Today, I learned that my idea for a hybrid puzzle-based dungeon system is seriously flawed.

The way it was designed was that you matched colored tiles on a puzzle board while enemies advanced towards you. The colored tiles gave you power to force your way through a kind of gate. They also restored your magic points and allowed you to cast spells on enemies that were advancing towards you. If the enemy got to you, you entered a one on one battle.

How was it flawed? After playing the prototype several times myself, I found that splitting the player's attention with an advancing enemy and matching colored tiles was too much to handle, especially in an environment where two somewhat time sensitive activities are going on. In actuality, it would be better for me to use a much simpler system where the player only has to focus on one activity.

So it's back to the drawing board with the dungeon system. Hopefully, I can think of something relatively soon and have another chance to prototype it.

Story telling in games

2009-06-27T19:50:00.000-07:00

While playing a game, I just had an important lesson in story telling and making your world seem more believable. Often times, one can flesh out the story by having the main character taking part in some small side plot involving helping those who would normally be enemies.

I'm currently going through Final Fantasy XII again and exploring some areas and quests that I missed. Right now, I'm supposed to go fight the Garuda outside of the Nam-Yensa sand sea in the game. But I took a side quest. The denizens of the sand sea, called the Uratan Yensa, are quite violent bipedal creatures often armed with various bows and arrows and swords.

That's what made this next story so interesting.

At one point, a moogle tells you that he spoke with one of the Uratan Yensa. And that there's a beast called the Emeralditan roaming the area, guarding a "treasure". Maybe if we help the Uratan Yensa defeat the beast, we could claim the valuable treasure. So I go to fight the Emeralditan. It's surrounded by a bunch of Uratan Yensa and pretty much distracted by them, so defeating it is no problem. I come back to the moogle and he tells me the lone Uratan Yensa went off to find the treasure. I go searching for him and see him skitter back to the moogle. After a quick conversation, he runs off to talk to the Uratan Yensa queen.

The queen is, for lack of a better word, pissed that the single Uratan Yensa sought help from outsiders. She then executes him on the spot by causing him to disintegrate and fly into the wind.

Rarely do I get surprised by video game stories, even in the main plot. But this one had me wide eyed. Suddenly, the very creatures I was killing had a moment in the story that fleshed out their thoughts and feelings about outsiders and how the rules of their society were governed. I was a bit moved.

And that treasure, it turns out, was a rare flower that blooms in the desert. It holds a berry that is apparently hated by the Garuda, whom I have to face next. I picked the berry and I am now headed for the Garuda.

I've never felt sorry for the enemies I ever faced in a video game until just now.

On choosing game development software

2009-06-27T13:56:00.000-07:00

One of the most taxing tasks I've been having to deal with is choosing the right software to develop my game idea. There are a number of issues that factor into the decision:

Supported platforms
Interface usability
Data management

Running down this list:

I'd like software where the final product runs on both on Windows and Mac. I've seen awesome programs that run on one or the other, but not both.

The interface of the program also needs to be easy to use and navigate. In actuality, I would prefer to deal with something almost entirely text based. However, if there is a front-end GUI to navigate, it should really have its functionality integrated in a way that doesn't make me want to rip my eyeballs out.

Data management is a big factor. In other words, how is data about enemy and characters stored? Is it compiled? Encrypted? Or is it a simple text file that anyone can access and manipulate?

So far, the closest piece of software I have found that covers all these aspects has been Ren'Py. However, I'll need to code the actual playable aspects of the game myself in PyGame and get them running in Ren'Py. Adventure Game Studio is also fully featured, but does suffer from only running on Windows at the moment.

Either way, I'm still keeping my options open as I attempt to refine the design of the game. I'll eventually have to settle on something, even if that something doesn't have everything I want.

Design techniques

2009-06-09T20:02:00.000-07:00

I'm very big on turn-based role-playing games. Especially from the Japanese and preferably on consoles (mostly due to the fact that I'm not too good with keeping computer hardware up to date). The series I appreciate and play the most are Final Fantasy and Grandia, but I'm willing to play anything that has an interesting battle system. In fact, battle systems are what attract me to most RPGs.

Of course, RPGs are a source of frustration sometimes. The act of grinding and fetching things to get further in the game and the constant running into brick walls in the progress can often be quite a turn off.

As a result, a few years back, I decided to attempt to design a game with a turn-based battle system that had the elements in it that I enjoyed: a bit of player skill with an increased chance of winning as the character grew in levels.

When I look back at when I started years ago, I feel so stupid.

My "design" was so horrible and mismatched that it's a miracle I'm still pursuing the project.

I see now the problem stemmed from my design techniques. I was so focused on one thing (the battle system) that I didn't bother to properly design the other aspects of the game (NPC interaction, environment interaction, character progression). This was coupled with the need to scale the game down to a level where it could feasibly be completed (i.e. art had to be something that could be done relatively quickly and painlessly, the world couldn't be too big, etc.).

It was only about two years ago that I began to think about these in detail. And it was only early this year that I learned how to truly approach these designs.

First lesson learned: when trying to design an aspect of the game, make a list of everything you truly want to include in the game. This list shouldn't include items that are featured in other games because "it's the norm" or "it's expected". It should only include mechanics, concepts, and/or intended feelings you want in your game.

For example, I made a list of things I wanted to include in my dungeon design:

Make it nearly impossible to get lost.
Give the player a feeling of tension.
Let the player know what enemies are presently in the area.
Give the player a reason to revisit the dungeon later.
Make designing a dungeon a relatively painless task.

After I made this list, I looked at games that had at least one of these elements. After much contemplation, Puzzle Quest and Tower Defense games came to mind and have had a significant influence on how I've designed my dungeons now. I'm very satisfied with the results and don't anticipate having to change anything now.

But what really surprised me was one game that had nearly all of these aspects--even though it wasn't an RPG-- was MineSweeper.

Think about it; you can't get lost, the design is a grid that randomizes the position of the bombs (i.e. your enemies), there's always the tension of stumbling on a bomb, and if you don't stumble on one, you know how many bombs are in the area.

I actually looked at MineSweeper quite a bit when deciding on the dungeon design. However, I settled for a concept that was more abstract and active in terms of gameplay.

Still, as I press forward with my design, I plan to use this technique when I'm in a bind. Who knows what other games may come to my attention as a result?

First

2009-06-09T05:55:00.000-07:00

Welcome to Conflicted Gamer. My name is Tamar. By day, I make a living programming Flash games for a small company. By night, I'm hunched over the internet reading and posting webcomics, playing games and blogging.

Conflicted gamer is pretty much my thoughts on game design. It'll mostly be about my attempts to make a game, but will also feature observations about other games that I play as well.

I tend to favor playing Japanese RPGs and platformers when it comes to consoles. On my computer, I tend to venture out of the box more since there's a cornucopia of games one can download.

My goal is to one day design a role playing game. My sights are aimed a bit low in this arena; simple 2D graphics (most of which won't be animated), released for PC and preferably Mac and distributed for free over the internet.

My current game idea is still in the design stages, but I might post some concept art every now and then.

I'll end it here for now. I have a lot I want to talk about, but it will have to wait until I get home from work.