Stress testing

From HEWIKI
Jump to: navigation, search

What stress testing has been done on the server tech?

All of these questions are highly dependent on your game design and implementation. Imagine that a very sophisticated and high-frequency combat system, for example, would be more CPU intensive than a simple, low-frequency one. This is true of all your game systems. This particular caveat is true no matter what engine you use (licensed or build-your-own), and thus it's not really possible to give a general answer. Essentially you have to establish a design and work within a budget.

We establish average CPU (in MHZ) and memory (RAM) budgets per player to make such estimates. Of course these are highly depending on the game design of Hero's Journey and may not map well to your or any other particular game design. How one implements the concept of Items and Inventory, for example, can have a dramatic impact on CPU and memory utilization. For example, SWG implemented an Inventory system where every item was a unique item with no shared attributes... this represented the most intense (aka, worst-case) scenario.

We provide concrete systems and pattern implementations at the HSL level which allow you to build robust and efficient designs, but it still is important for you to use the tool wisely. We are always available for design and implementation review to help you make the most of the tool.

Having said all that, it is reasonable to expect a given area to handle many hundreds or thousands of users based on what is going on there. For example, if combat is intensive then you'll want to subdivide your world into smaller areas. If you have a town where essentially little to no intensive activities take place, then it can handle more (some some areas may require more CPU and others less even though they have more users).

One way to get a handle on this is to consult with you on your basic design requirements and we can better map that to how many users is reasonable per area. That information exchange would be key to making any reasonable estimates.

Additionally, we support multiple frameworks for Automated testing which can be utilized to test your game systems and simulate load.

Are most outdoor areas expected to connect to one another via chokepoints or other easy transition spaces (S-curves, etc.)?

Currently, yes. This creates what is called non-linear space, which has many, many advantages over linear spaces (the type where the world is continuous surface). With non-linear space you can change your scale throughout your map (high density in towns, low density in hunting areas) easily. You can interject new space anywhere without worrying how it fits... a feature you should consider extremely valuable as your user population migrates in endless unexpected ways; allowing you to easy adjust your world-flow.

The limitation of this is the "chokepoints" for transitions. However, even that can be disguised so well that with careful design your players won't even be aware of them. For flight models, it requires some extra care and trickery to pull off but can be done.

A continuous world surface is a future enhancement on our Road Map for those who want that. We've not designed this in detail yet, so the exact nature of that implement ion is still pending.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox