Blog for Nathan Snell at GarageGames.com

Fractured Univese - Designing XP & Time / Level

Nathan Snell — 2007-02-09T04:20:02+00:00

While it may not be too terribly exciting, I thought I would at least do some form of documentation in terms of what I am doing game design wise for Fractured Universe. I do this as a means of hopefully starting conversations on methods, theories, general thoughts, and just all around game dev talk :). I am not saying the methods I am using are the best, so much as what I came up with and what seems to be practical and effective with the FU team. I am really just wanting to share this for developers (or anyone, really) who are curious about the methods and processes used and to start conversations. That said, I will start with what I just finished up- experience and leveling time.

After much deliberation on how to approach setting the required experience per level and the amount of time it takes per level, I decided on an approach.

The Approach
I wrote out initial values that I thought would be a good length of time between levels (varying from level to level, faster in the beginning and longer later on with some variations in shortness). From there, I wrote an equation that more or less matched the values I had written earlier. I put this equation into an excel spreadsheet applying it to every level and placing all the equations changeable variables into their own box. I'll explain the importance of this later on if you don't realize it outright.

XP Per Level
The next step was to figure out how much XP would be necessary per level. Since I had the amount of time it takes to level in minutes, I decided I would calculate the average expected XP / minute. This was easy as we already had a few mobs in game and I knew the XP they yielded. So after deciding about how many mobs a player should kill per minute, I was able to easily figure out the average xp, modifying it a bit of course. Additionally, the average XP /minute would also be increasing as the player gained in level. With this in mind, I wrote another equation to calculate the average XP and applied it to every level, again having all the variables in the formula modifiable.

With this I was at my final process, really, a simple one. I had my average XP / minute and the number of minutes per level. All that was left to do to figure out the amount of XP I needed per level was multiply the average xp / minute by the number of minutes per level and viola!

Now, the use of the spreadsheet and making all the variables changeable is a complete must. I wouldn't have it any other way. The reason is it allows me to tweak one element of any of the aforementioned formulas and all my values are automatically recalculated. I also have weights as to allow for various levels and brackets to be higher or lower. The benefit of this is that I can easily see what effect an increase in the avg xp / min will have on every level, the total estimated playing time, the amount of xp per level, and so forth. It also makes it nice for the coders ;)

One last thing I do after I've completed the first version of ths spreadsheet is upload it to Google's Docs & Spreadsheets. This allows for easy discussion & collaboration on the formulas, their results, easability for others to make quick tweaks, version control, etc. It is a very nice system, and thus far has been serving us well.

That's all for today. Nothing particularly revolutionary, but hope this was at least somewhat beneficial or interesting.

MMORPG Contest End - Fractured Universe

Nathan Snell — 2007-02-02T06:07:23+00:00

Fractured Universe - City

Hello everyone! A quick introduction: I am Nathan, also known as PyroGuNx. I do game design / business & marketing stuff (as it becomes necessary) for Fractured Universe.

The MyDreamRPG contest came to a close yesterday. This, however, has not been any reason for those of us on the Fractured Universe team to slow its development. While the contest has come to a close, we still have been ruthlessly plugging away developing, adding quests, and moving the game forward.

Originally, I debated whether or not I wanted to post anything about FU. Tony (SgtFlame) and Allyn (MrBloodworth) pretty much covered a lot of what might be said. While I personally could say a lot, most of it would be pertaining to design philosophy, concepts, or business which of course makes sense since that's what i'm on the team for. But I feel it might not be as appealing as other topics. After much deliberation, though, I found two things I felt really aided our success that I wanted to comment on.

The first is a comment on Tony's post mortem post. He made the comment that one thing he wouldn't have done was start alpha testing as early as he did. While I generally agree with him, I personally think it was for the best as it brings in real feedback. Ideally, we would have started alpha testing about a month from now, maybe two at most. However, due to the time constraints, we wanted trusted people on and testing it now. It has really worked out for the best, and in my opinion, is a solid development philosophy. Get your target players (trusted, of course) testing as early as possible, even before you're actually ready to test. It allows for you to take many of the concepts you have and receive real feedback. Why take the time developing guesses so far along when you can find out the answers at the beginning. It also allows for the appropriate trimming of gameplay which is the most important thing, irregardless of the number of features a game has.

Now, I have seen (and been with) teams that don't like this philosophy simply because they don't want to have a huge list of bugs early on and they're afraid of frightening players off. Certainly a merited concern... but those are bugs you need to be squashing anyways, and just because it's on a list doesn't mean you have to fix it now. So long as frequent updates are occurring, players are going to be aware that what they're playing is a work in progress that, best of all, they're a part of. If you picked them right, they'll understand it's not final and that you're actively working on it... which leads me to my next comment.

Regular, small updates. This is something I have seen other teams use with great success and that our team has thus far been using with great success. Frequent, small updates. They're fantastic. They help keep the motivation flowing both within the team and within its community. People see development actively occurring, even if it is small, and it gives a sense of achievement. Not only that, it also helps bug fixing! But the bigger point here beyond regularity is size. By avoiding doing massive updates, it seems to me that feature creep can be more easily avoided, and that updates or bugs won't be put off. In addition, it allows for newly implemented ideas to be quickly elaborated on, shrunk, or potential downfalls or necessary improvements with them noticed.

With large updates, however, it's easy to get caught up in the "oh, we can't release until we get X finished." or "we can't release this yet, it still has Y bug." and inevitably your progress is slowed, if not halted for a time. I also I think this will cause the motivation within the team to be lowered for a number of reasons, and the community I know will be less motivated, or anxious at the least, which is just an additional strain on the team.

I'm not saying that those two methods should be a staple (although I certainly wish they were present in each project i've worked on) to any good team, nor am I saying that this is the only way to develop. But I am saying i've seen these things as primary factors of success (speaking purely beyond our project at this point, as it could only really be considered a moderately short term success right now) to many projects, especially when the majority of the team is made up of volunteers, and perhaps that is the key. What do you all think?

In ending, the contest, though challenging and time consuming has been a blast. Our team of about 5 core guys (including myself) has been an awesome bunch to work with. I don't know about others, but I know that I am impressed with what we have put forth, even if all of us on the FU team would have liked to have had more. Best of all, whether we win the contest or not, we have the foundation and team to put out an indie MMORPG that will, if we have any say in it (which fortunately enough, we do!), will stretch the limits.

Learning Curves in Game Design

Nathan Snell — 2006-09-26T17:40:25+00:00

The following is a game design methodology/concept to the design and creation of learning curves in games. I felt the need to write this up as I have seen other developers approach the learning curve task and as I saw the need for a very clear cut method to this task as I've been working with the RenWerX team on Ascension. I'd love to hear peoples comments, critiques, and thoughts on this. Though I don't post much, I thought i'd share it with all of you in hopes of helping even one in some way :)

When taking into consideration the design of a game, phrases like "learning curve" and the likes tend to start to get thrown around. It's no surprise, though, as the learning curve is an important factor in determining just how easy it is for new players to 'pickup' your game and start playing. However, when it comes time to take the steps to really approach, assess, and develop the learning curve everything tends to get jumbled together. The movement is put together, other assets like weapons are added in, maps are created, various features are added in addition and soon you've got a jumble of factors that may or may not be a detriment to your games learning curve. I say this because I've seen this as the case for games in the past and it was also an issue in which the team I work with was facing. With that, I developed a concept to designing learning curves that makes sense both to the developer and that will ultimately make more sense to the end user - the gamer - as well.

In my concept I take the single, general gameplay learning curve and break it into one primary learning curve that I call the initial learning curve and into however many other secondary learning curves are necessary. I refer to these secondary curves as the expansive learning curves.

The initial learning curve can potentially look similar to that of the general learning curve (downward sloping), but is often times shorter visibly and in terms of time with respect to difficulty. This is because the initial learning curve is reduced to what a player has to learn initially in the game to be moderately 'effective'. That is to say, the initial learning curve is a representation of the amount of time with respect to difficulty it takes the player to learn the bare minimum of what's required for them to be able to begin enjoying the game.

For example:
Pong's initial learning curve consists of the following:
1.Movement (side to side)

A bit more complex example:
Counter-Strike Source's initial learning curve consists of the following (abbreviated):
1.Movement (forwards, backwards, side to side)
2.Jump
3.Firing a weapon
4.Throwing a grenade
5.Weapon switching
6.Interacting with the buy menu
7.Identifying maps
8.Identifying environments

With the above, we can obviously see that Pong has quite a short learning curve in comparison to Counter-Strike Source. This is also a trade off, however, as Counter-Strike Source's learning curve is somewhat longer though still relatively short. The difference is that Counter-Strike Source also has many expansive curves, where Pong has very few such as angled shots, speed, and rebounds.

While the initial learning curve is the bare minimum in which a player has to learn to enjoy or be moderately effective at a game, the expansive learning curve is a curve representing and is based on a different idea. The expansive curve is based on expansive elements of a game. That is, elements that a player can expand into and learn, but that are not a requirement for interacting and enjoying the game. That does not mean that expansive elements do not bring or add enjoyment, mind you, on the contrary, they almost always do. Often times it's the expansive elements that keep players playing a specific game. Because of what the expansive learning curve represents, it deals with different factors than the initial learning curve. While the initial learning curve deals with Difficulty with respect to Time (downward sloping), the expansive learning curve deals with Mastery with respect to Time (upward sloping). That is to say, the expansive learning curve deals with how much time it takes for a player to master the expansive element. This is important because as opposed to being a facet of the initial learning curve where the element is being measured by difficulty as it's another road block to playing the game, it's being measured as a voluntary addition or evolution of the game that is a facet to their overall skill within the game, but not a requirement of it. This allows players the freedom to learn and adapt to various expansive skills as they feel they appropriately ready for it.

A good example of this comes from Enemy Territory. Enemy Territory has an initial learning curve slightly more complicated than Counter-Strike source, but has more obvious expansive elements. Depicted below:

Enemy Territory Initial Learning Curve Elements (abbreviated):
1.Movement (side to side, forwards, backwards)
2.Firing a weapon
3.Throwing a grenade
4.Understanding classes
5.Understanding various class specific utilities
6.Interaction with map assets/objects (like building a bridge)
7.Jumping

Enemy Territory Expansive Learning Curve Elements (abbreviated):
1.Sprinting
2.Leaning

In this case, I mention 2 of the expansive learning curve elements from Enemy Territory. Sprinting and Leaning. They're expansive elements because while you initially figure out how to sprint when you first start playing, and while you could lean if you felt so inclined - neither is necessary to enjoying or being 'good' at the game. In fact, I know a number of skilled players at Enemy Territory who rarely utilize lean as an expansive element. In addition, when using sprint in conjunction with jump you can move even faster- another expansive element. These expansive elements are a necessity to any game due to the additional depth of gameplay given. By adding in expansive elements, you give players the ability to evolve their skill but don't force them to evolve them when they first start playing.

Life is a great example of the concept of the initial and expansive learning curve, and can possibly contest to the validity of making games easier to learn and understand. In life, you start with a rather daunting learning curve. You have to learn to see, eat, walk, and so forth. However, once you've overcome the initial learning curve, you're prepared to face the more expansive elements. Perhaps you want to have your hand at surfing. If it appeals to you, you might invest more time into mastering it (becoming a professional, or just become good). If surfing isn't your think, you might want to take up soccer, investing time into mastering it. If you don't like soccer, you can drop it and move on to something else. You can do this because it doesn't effect any of the elements involved in your initial learning curve- it doesn't affect any of the elements involved in you interacting or enjoying everyday life.

The prior has been a concept that I think many game developers have considered intuitively but have perhaps not laid out thoroughly in a clear-cut, defined form. Because of this while they design to some extent intuitively with this in mind, certain elements fall between the cracks or become a jumble of the overall learning-curve idea. By using the concept above as you allow both the your team and the end user a way of properly addressing and easily understanding the elements of your game.