Wednesday, August 12, 2009

Building Character

There have been several recent discussions across a variety of the MMO blogs that I read which pertain to character development and which method is best. I can see each person's point of view and I have not, as of yet, made any kind of a final decision.





I do have a few ideas that I would like to try out...





First Lets look at some of the existing methods.

The largest example out there is a standard Leveling system, where once you pick a character class, you gain experience to gain levels, each level provides skill or improvements to existing skills, and everything is neat and tidy. Two 4Th level warriors, standing next to each other will have, barring equipment and actual Player skill, exactly the same skills. For character differentiation the Class/Level system relies on the same equipment and player experience that I mentioned as exceptions above. This is a well understood system that you can find, with variations, in a large number of games, including the classic Pen and Paper games that the MMO genre has spawned from.


Advantages: Easy to understand.; Moderately easy to balance.; Can aid in grouping with strangers because of easily recognised combinations defining general character capabilities (Looking For Group: 7Th Level Mage = LFG:M7 or whatever common notation develops within the community).


Disadvantages: Character development on rails, based on your initial pick at character creation, you really only have one choice, to level or not. If you don't like the character class you picked, then the choice is to re-roll a new character, or use some developer provided reset mechanism.; excludes character types. Say I really want to be an Explorer/Jack-of-all-trades-master-of-none. Unless the developers specifically created a Jack-of-all-trades class for me to pick, I have to pick something else; No sense of time, what is my character doing while I'm not logged in? sleeping? Leaning up against a wall? What? This system rewards those who have lots of time to spend in-game and actively leveling, and leaves other players who cannot devote as much time to the game without advancement. (Which is funny to me as a developer, I have a finite resource, My server and bandwidth. Why would I charge everyone the same price for admission, and reward those ho give me the least value with more capabilities?)





Next we have Skill Based character development. There are a variety of games which offer this method, but the one I am most familiar with is the Pre-CU version of Star Wars Galaxies. With Skill based development the player can select which specific skills are targeted for improvement rather than accepting the package of skills determined by a class/level combination.
Advantages: Greater control of character development by the player. The player is capable of mixing and matching skills that would normally not be all assigned to the same character class.; The player usually gets to experiment with different skills and thus different aspects of the game without re-rolling characters. Some players find this more palatable because the don't perceive a loss if they are still working with the same character.

Disadvantages: Very hard to balance.; Can be confusing when there is no 'optimal path' laid out in front of a player.; Often leads to 'Flavor of the month' builds as min-max players experiment to find the best mathematical builds and then the rest of the game population follows their success.

And Finally, an outlier, Time based skill progression. This is no a system in and of itself, but a method that can be applied to either of the above systems. EVE online and Progress Quest (arguably a joke that was taken too far), are examples of games where character development happens regardless of the player actually being logged in. In these games, once some selections are mad as to the direction of character advancement, there is nothing you can do to hurry it along. This does effectively eliminate grinding for character advancement.

Advantages: Offers some assistance to the casual player by disconnecting the amount of time online with the character's capabilities.; could possibly encourage sustained subscriptions because of the perceived value added just by having the account active and the player advancing.


Disadvantages: Can foster a sense of 'I can't catch up' for any player that starts later in the game.; Could contribute to boredom in game because the "what can I do now?" question would never be answered with "How about grinding out that nest skill/level".


As we can see here, each of these systems has advantages and disadvantages, and these are not the only systems that exist, but these are the systems that I am considering for Skies of Psyberia. Class/Level based progression is an easy out for the single developer, it is widely understood, has the best chance of one man being able to balance it, and is frankly assumed by most potential players... Home run, right?... well, no. There are some personal things that bother me about the advancement on rails feeling that a class/level system gives. Since you should always build something that you yourself would enjoy playing, I'll detail my current plan below.


Hmmm... This is getting a little long. I'll put my plans into the next post.

Later

Tuesday, August 11, 2009

Farming != Boring

My train of thought as of late is in the direction of providing content systems in Skies of Psyberia. Systems that can be set into motion, and provide gameplay without requiring developer or designer involvement for long periods of time. My thoughts bring me to casual games, the ones that are implemented in flash or as web games. Let's see.... Mob wars and all of the variants (which as a concept predates the web, Drug Wars is the earliest I can think of). These games are basically spreadsheets with timers... no matter which variant you pick, they all work basically the same. Any one of these would translate easily to a 3D MMORPG, but after the translation you would have... an MMORPG. They represent an equivalent of the core gameplay of the genre. So lets look at another popular game type. We have the farming sim, examples include FarmTown, FarmVille, etc... With these they would also translate well to a 3D MMORPG, but they could easily be a sub game within the main game... or to use another word, a 'System'.

Lets break down your basic farm sim. You need a plot of land that you own or rent. it must be of a measurable and restricted size. You need the ability to designate and plow fields. purchase and plant seeds. Wait for a prescribed period of time. Harvest items, which just happen to be crops.

Several games have included harvesting, the one I initially thought of was SWG with it's automated mining equipment for extracting materials from the ground, and one of the variations of that equipment gathered crop-like materials rather than steel or copper. At their core, these are just replacements for the crafting of items. Some regulated way of introducing either raw materials or completed items into the game world. I just don't think that anyone has allowed for formal cultivation in a MMORPG yet, just randomized harvesting. I'm sure that I have missed an example of this, possibly in 'A Tale in the Desert'.

What I have begun to implement in the game is a farming system. Players can rent or buy a piece of land, designate plots (which snap to a grid so that fields can be made), and plant crops. There are really an infinite number of things that can happen, for example, as I mentioned in a previous post, rats could invade a field and eat crops. This would cause players to police their plot to keep the rodents from harming the growing crops, or perhaps hire other players to do it for them. As long as a system for creating quests is built there are many things that can break out from the basic farming system. Here are some other examples:

Plow my fields for x per plot (i have lots of other things to worry about, and you cant harm anything)
Harvest My crops for me (as long as it is set up that the crops go into some kind of barn or silo automatically, there is no danger to the hiring player)
Kill vermin within my fields (pretty self explanatory, a small bounty for vermin that die within the designated area)

The end results are crops. These crops can be sold, or perhaps used in manufacturing of other products that can be sold for more.

The idea is by no means revolutionary, but I think it could be very fun.

I'm rambling on, but I think you can get the idea...

Wednesday, August 05, 2009

On gameplay and the possibilities of the post WOW MMO

Earlier today on Tobolds Blog, Tobold continued his series 'Why do we play?' series by talking about Gameplay. He defines gameplay as the repeating elements of the game. Examples would be combat, or crafting. I find this to be a very elegantly definition for what gameplay is and it gives some focus to how one should go about designing gameplay.

First, gameplay needs to be repeatable. No matter how much fun something may be, if a player can only do it once, then there is not much point to including it within an MMO.

Second, it needs to be fun. You would think that this should go without saying, but it needs to be said for one specific reason... not everyone defines 'Fun' in the same way. Some people are enthralled with competition against other live individuals, and no matter how good your AI is they will never have fun because there is no real person on the other end for them to best. Other people find collecting fun, it could be experience, gold, virtual window treatments, etc... but they desire an ever increasing pile of 'something' in order to have fun. still others might be a variation on the collector who only derives fun from completing collections, and thus will be frustrated if there is no end to the possible virtual window treatments.

Third, and this is personal qualification because I am a lone developer with limited time and resources, gameplay, in whatever form it takes, should be generated and not authored. to put it simply, I am but one man, and I cannot custom craft each and every experience that each and every player might want to experience. This, as a rule, is the same for every game developer, because no matter how big your team and how deep your budget, there is no way you can produce content faster than the playerbase can consume it. You can't ever come close. I my case this true-ism is just greatly magnified.

I therefore set down the requirement that any gameplay designed for Skies of Psyberia be generated either algorithmically, or by the actions of the amalgamated playerbase. Here are some examples that I have off the top of my head:

Delivery quests: These are not scripted, one use quests that we normally experience in today's games, but quests generated out of need. I plan on going with a pseudo-closed economy, in that if a Shop in the city of Cog sells swords... the need to come from somewhere. If a store's inventory is finite then the price of the items should naturally be tied to supply and demand. If you live on a floating island, and a war is starting, weapons will be a hot item, as the stock of weapons in stores dwindles, the price goes up. At the same time merchants will need to restock, so local weaponsmiths will be swamped with production re'Quests' (see how I worked that in there), and suddenly there is a need to move objects from one place to another... thus delivery quests are born. There are all kinds of variations that can be put on a system such as this, because it is a system rather than a hand written quest. Let us say that the player is carrying a crate of daggers from the smith to the market stall and is set upon by a few opportunist rogues (either generated AI or real players, doesn't really matter, the players could even be following a generated quest that popped into the system when the crate was picked up at the smiths). If the player evades or bests the rogues and makes it to the delivery, then all is well and the player is rewarded with both money and the trust of the merchant. Possibly even a discount. If the crate never makes it to the destination, then the quest has failed, and the player is no only out whatever potential rewards would have come from the delivery, but might find it harder to be trusted with such valuable cargo in the future. This can be scaled up and down to be a simple note passed between lovers, to an entire ships hold full of cargo, but the idea is the same. Build a 'system' that 'generates' a quest rather than authoring the quest directly.

Kill X foozles: Kill quests are a core of MMORPGs and they probably always will be, but rather than author them, generate them. Want a 'Kill 10 Rats' quest, ok, design a spawn system that creates rats at a reasonable exponential rate, the more rats there are, the the faster they multiply, we will cheat the system by making them spawn at a minimum rate even if there are none left (you never can find them all you see, tip of the iceberg and all that). Now, and here is the twist, give the rats a way to affect one or more other systems... say they can steal grain from the mill, or they can ruin crops growing in the field, or they can cause disease by proximity, etc... There are plenty of reasonable bad effects that rats can cause. Now the systems react. The mill owner, detects stores dropping without sales... basic inventory management. It also detects rats, basic perception. One table look-up later and the mill owner is running down the street to the Job posting board with a reward poster for each batch of 10 dead rats... or at least their tails. This quest will be available to anyone that sees it until such a time as the miller no longer feels threatened by the rat population. At the same time, a local farmer is having trouble with his cabbages... you get the idea. When merchants and inventory are not magically stocked, but are the just a part of a system, then it becomes logical to interconnect systems that are normally independent silos in current games. This also means that players can really effect the world... visibly. If nobody takes the rat killing quests because that is beneath them, then things happen, big things... The cabbage crop is lost, the mill goes out of business, the baker either imports flour and raises prices to cover the deliver quest cost, or goes out of business. An ir/responsible playerbase can cause an entire ecosystem to fall apart, or cause it to flourish... A developer can cause a stable system to start moving again by introducing plot... such as a war between NPC factions, and thus generate tons of quests and 'gameplay' with just a few paragraphs of text and some database tweaks.

There are some limits that would have to be put in place. Players by their nature are not invested into the survival of the world... If a core pivotal city in the game world crashes down around them and everyone else dies, it might just be a giggle for them. After all, it is just a game, there are no real repercussions. SO the systems as designed would need to be monitored and tweaked. If players destabilize too many systems, then artificial enticements or stimulus would need to be added into the system. The Miller might be given a cash infusion from the city council (in exchange for a discount price for future product), A farmer from a neighboring island, hearing about the cabbage crisis might start shipping in his own cabbage at inflated prices... he might even have to switch crops to do so. The idea is that a few administrators can chase large systems and keep them healthy faster than the same number of content authors can create new and unique content. This won't be a perfect solution, but rather than say it can't be done I would diversify and insert created content chains into the world to fill the gaps while letting generated content become the bulk of the player diet. The more content that can be triggered or generated either directly or indirectly by the players actions... the better.

Now, I just need to get off my butt and start coding interdependent systems... umm, this is going to be easy... right... ... ... anybody wanna help? ... Please?

Monday, August 03, 2009

This is just a quick test of a mobile blog entry. I just wanted to see how easy it would be to post from my Blackberry Storm.

World Building

I'm currently developing a game with the working title 'Skies of Psyberia'. The name isn't really important, and it mostly stems from the fact that I have owned the psyberia.com url for over 10 years and figured I would use that domain.



Now I have designed and re-designed a world background story for SoP in an almost never-ending loop since I started this project. There are only a few things that have stayed the same thru each re-design, so I will list them here. These factoids are the building block that I want to wrap everything else around.



Game type: MMORPG. Not much of a surprise, everyone is making one of those now-a-days. I my defense, I started the project 10 years ago while deciding that I wanted to improve on what PennMUSH could provide in the realm of multi player gaming. Not trying to say anything about the current crop of games stealing ideas or anything like that... I'm just embarrassing myself into forward action on something that could have really been worthwhile if I had just gotten my act together sooner.
Game World: Post disaster, floating islands, flying pirate ships and zeppelins. I imagine a world where oceans cover most of the old continents forming islands from the higher land masses. Trade and piracy between floating cities. All clothed in a fantasy 'SteamPunk' level of technology.
Back story: Wow, this has changed far too often to even think about trying to write it down again. I'll be happy to fill in the back story later to enhance what is already a fun and playable game. :P


Now that I have that out of my system... actually pressing the 'PUBLISH POST' button instead of the 'SAVE NOW' button will be a vary hard task... wish me luck.

Failure and Renewal

I've been working on games for so long without actually producing anything publicly that I have decided to change my methods.

This Blog was supposed to be a catalyst for change in that by making thing public (or at least semi-public) I would force continuous advancement without constantly re-working things that I had already posted as fact. I sought to shame myself into forward action by denying myself the ability to revise the public image of what I have committed myself to.


'It Didn't Work!'


If you check the posting dates, you ca see that I have not posted anything in the last several months. That doesn't mean that I haven't written posts tho... The dashboard for this blog is filled with additional posts that are in draft form, and will probably never see the light of day. I have written and edited content, trying to perfect it and at the same time revising facts to concur with my current development directions. This has to stop!

What I will try to do now is to place my opinions, thoughts and progress into written form as they happen. I promise to refrain from revising history to suit my current whims.

That said, enough whining... Lets talk about development. :)

Thursday, March 27, 2008

Schema Scheming

I've been prototyping the database over and overagaing, trying to find a ballance between ease of coding and what I believe will be high performance. There are a couple of isues with this, one of them is simply that I am not a DBA. If I was, I'm sure that this would have been done long ago and I would currently be fretting about other things. Second, There are many designs that will work. Thousands of combinations that can contain the data in a readable format, but the question is "How efficient is this one, or this one, or that one..." I'll have to set a time limit for myself and just go with the best one I have at that point, understanding that it will probably be re-factored at some future time. Next post... the basic schema!