Friday, August 26, 2011

Perma-NPC's

 Making a game solo on a tiny time budget isn't easy.  It requires you to take a new path in almost every decision you make, because every moment spent building something that's already been done is essentially not good enough.  How could a single programmer compete directly with real developers?  Uniqueness is the only way.

Which makes it even harder for this game, because I want it to feel like a traditional RPG.  I will be adding twists as I go and trying to spend as little time as possible on things that have already been done.  Thats when I came across This Page.  A list of over 7,000 bad-ass fantasy names.


So they have now been loaded into a database for my game, and marked with a timestamp when they are used so not to use them multiple times.  Now when an NPC is generated in the game, it pulls a name from that list and assigns it a visual (and in the future, other stats).  This newly formed NPC is added to another database where other NPC's information sits.  When players play the game, they will interact with these generated NPCs.  When an NPC dies, it will not respawn- Instead, a new NPC will be generated to replace it.


So what does that do for the game?  Well, nothing yet.  But it could have some major implications for where the game heads from here, because now I am committed to this path.  Now I will be looking for ways to invest players into NPC's that might not always be around.  Here are some wild ideas:
  • NPC's have an opinion on you depending on your actions.  It takes hard work to get an NPC to like you, but you benefit in different ways from this.
  • When another NPC/player kills an NPC that likes you you can choose to carry that high opinion on to the NPCs friends/family by avenging the NPC's death
  • Bosses could still exist but would always be unique
  • Certain NPC's that are especially powerful, live in high player population areas and well liked by players would become targets for players to try and kill
The above are definitely not plans; they are just things I came up with as I am typing and will probably make a point to not look at them again.  But these are the possibilities and it is choices like this that makes an RPG stand out.  But for now I will be content with killing all of the NPC's that have dumb names, and leaving the ones with cool names and cool looking sprites to live.  That is simple, but in a strange way I am already feeling like this game is a true world where I have an impact.  What bigger impact is there than world permanence?  Isn't it ironic that NPC impermanence creates world permanence?

Thursday, August 18, 2011

Combat Decisions

Choosing a structure for combat is important because it builds the general feel of the game. For this game, I have opted for something that resembles the popular phone game zenonia. I would say that this is a mix between traditional RPGs and diablo.

I wanted fast-paced combat with a lot of visual cover-ups, because this is an online game and there are several different character avatars and I do not want to create sprites unique to every avatar performing every combat move. So there has to be a lot of explosions and visuals that will cover up the characters underneath. This probably means taking arcade style aim is out (because we want our characters to be difficult to see), which is good anyways because having to aim at enemies doesn't work well with online rpgs because of latency issues. Latency issues means we will need a targetting system like those seen in most RPGs. But the game will still feel like an arcade game because of the fast pacing, auto-targetting and over the top (character covering) visuals. I prefer my games to have an arcade, retro feel. I also like them to not require a mouse because two hands on the keyboard is more conducive to typing, and encourages chat.

Auto-Targetting
Our player tar

a red circle appears under the closest
enemy- the one you have selected.
gets NPCs and objects of interests using a simple check to see what object is cloest to our player. I quickly noticed that this causes problems because our target often ends up being behind the player while intuitively we would hope to be targetting an enemy that is standing in front of the player. So I added a modifier to my function that checks distances between things so that it considers a point 50 pixels in front of the player (depending on the direction the player faces). Also, dead NPCs are given less priority (their 'distance' is multiplied by 5).

Adding Depth

Classic games that are built on twitch (player skill at aiming) arguably do not need as much depth because the player can enjoy their improvement over time in their aim, etc. But since my game will feature targetting instead of manual aiming, it will need to capture depth that RPGs tend to have. Even more so, because unlike many RPGs this game will primarily use an auto-targetting system, so we will not have that added strategy in choosing targets that many RPGs have. In the future I may wish to add this functionality, but right now I am seeing it as an unnecessary complication.

RPG's Are Complicated For a Reason

That reason is that learning is fun. Players want to feel like they have achieved something and that they are doing so more efficiently than the normal player (or at least more efficiently than they did last time they played). Although an RPG is not twitch based, it is important that players still feel that they are improving at the game. Watching their characters improve is simply not enough, because then the game feels like a timesink that anyone could do. Which makes you feel better? Knowing that you spent X amount of time more in a game than a friend, or that you are X amount better at a game than a friend?

This translates to complex combat systems that play off of realistic/intuitive ideas such as: Killing enemy healers and nukers before tanks, conditions such as poison that drain life over time if not cured, positioning your player strategically, switching poses/stances to match the fight, complex skill trees, attributes, resists, etc.

Why Aren't there More Indie RPG Games?Well, I already answered my own question: RPG's are really complex! Anybody can program a hunting game where you have to quickly shoot ducks that pop out behind bushes, etc. And those games are easy to program and can be very rewarding to play. They work off of the players own progression of improvement of their hand/eye coordination to make the game fun. RPG's need a lot of depth to make up for this areas where it lacks.

So when you take on a RPG project you have to realize what you are getting in to. How can one add depth and complexity to an RPG's gameplay while minimizing the complexity of it's code? Well, I am not entirely sure yet myself. But I have 3 strategies that I am thinking of using right now:


  1. Replace traditional life/mana bars with a new system that is easy to program but will add complexity to the game. (my HAMS system) 
  2. Dumb down attributes, classes, skill trees, etc into a system that is both functional and easy to code. (my skillpoints system) 
  3. Lower the games expected audience age. A game like this will never reach the same realistic complexity that someone would expect from current MMORPGs or Dungeons & Dragons, and setting realistic goals is important. 
I will be going into more detail about points 1 and 2 when appropriate, but for now we need to think about programming those first few skills!

Thursday, August 11, 2011

Wandering NPCs

Click the link in the main text to play
There really isn't a game yet, so I suppose it depends on your definition of playable...  But I am going to post it anyways.  Try this example of the game, the first build ever of my new game.


Why So Many NPCs?
In this example, there are many many NPCs wandering around.  I had some fun increasing the amount of NPCs to see what the game can handle before it starts to slow down, and you should get a totally normal framerate with that many NPCs.  In fact, I was able to go up to 400 NPCs before I started seeing the framerate drop.  Once all the other elements of the game are added in (especially multiplayer networking) this won't be the case, but right now it was fun to see so many characters on the screen at once without lag.  Lag is a serious problem when you are coding a game with AS3, especially one that is online multiplayer with real time combat (as opposed to turn based combat).  I will definitely write another article about that in the future.


Class Structure & Pathfinding
So I started working on my client, obviously, and quickly flushed out a movement system for the character.  The character you control is of class 'Player' which is extended from class 'Character'.  Class 'NPC' also extends class 'Character'.  I can already tell that the class 'Character' is going to be one of my biggest, messiest classes that the game revolves around.


Because I want both NPCs and Players to be capable of pathfinding to a given spot on the map, all my movement and pathfinding has to be part of the Character class.  In fact, right now my player class is very very small.  It simply checks to see what keys the user is pressing, and passes that on to the Character class via an (x,y) point variable, p.  p.x=-1 is analogous to pressing the left arrow key, etc.  Theres only about 10 lines of functional code in class Player so far.


I was seriously considering spending a LOT of time on this and making sure the pathfinding algorithm was perfect.  To do that I would need 3rd party code, and I considered it a while.  I think in the future I will need to adopt 3rd party code and a better system.  Right now, the Character class can be told to go to a tile, but if there is an object blocking it's way it will fail to reach its intended target.  If I choose to make a quest system, cinematic system, or multiplayer content then this could be a serious problem.  Characters would constantly get stuck on things, and then I would have to put in some quick fix code to make the character jump to their intended location.  It would be buggy and messy looking.  So its something to keep in mind for the future.


Click for full size image.  This diagram shows real results
from use of my wander radius code
Wander Radius
So I have a basic NPC movement code that moves the NPC to their target location (part of the Character class).  I still needed to add in code to have the NPCs decide where to walk.  Thats when I did my wander radius thing that you can read about in the picture attached to the right.


The NPC wanders randomly around, and if they move too far from their origin point then they will only wander in directions towards that point.  A value I call wanderRadius controls how far away from that point they like to wander.  The code for this is about 50 lines long.


Physics
I am opting to use real physics like I usually do for this game.  So there is acceleration, velocity, and location variables for each object (players, NPCs, and moving spells) in the game.  But I have the friction coefficient up so high right now (0.5 per looping frame) and the acceleration so high (2) that you cannot tell.  I chose to use real physics because I know I might want to have some slippery ice floor or something of that sort in the future in the game.  :-)


Lss