And how RONIN avoids them

Bandwidth Constraints

Typical gamer’s 28.8k modem makes the Internet feel very slow

• Ronin players communicate very small packets of information.
• All graphics and sounds are composed LOCALLY from preloaded elements.
• A heavy four-way battle requires less than 10k of bandwidth

Latency problems

It is difficult to assure latencies below 250 msec

• While Ronin is not explicitly turn-based, it is paced.
• Non-twitch nature of game makes 2HZ game cycle quite responsive
• Ronin is designed for 500 msec latencies

Revenue Models

So far there is no proven method to make money on the Web

• Ronin could operate on any combination of four "traditional" revenue models:
  • Advertisement supported: Ronin delivers a highly desirable demographic
  • Subscription based: Persistence and evolution ensure long-term interest.
  • Usage charges: Long gameplay supports hourly charges. Tiering fits naturally.
  • Shareware: Limits on lifespan, scope, or graphics can be used to sell up.
• But Ronin supports its own unique and highly flexible revenue system.

Server Upkeep

Large-scale projects generally require large-scale server capacity

• Ronin is decentralized, with small, sporadic demands on Big Fun servers.
• Big Fun server authenticates and introduces opponents, and records outcomes
• Only peer-to-peer communication occurs during actual battle
• NPC opponents require only local gameplay.

Constant change

Net users demand regular maintenance and upgrade of any site.

• Ronin is designed not as a static product but as an evolving game
• People who loved the simple game see it grow in complexity and depth with them
• Quality greatly advanced by cooperative, open, live development environment