Local LambdaMOO on Windows

Instructions to set up the server:

• Get WinMOO and extract it
• Save the LambdaCore database in the WinMOO folder
• Open command prompt (Start -> Run -> cmd), go to your WinMOO folder and enter:
  WinMOO.exe LambdaCore-latest.db LambdaCore-latest.db 23
• Server should say LISTEN: #0 now listening on port 8888
• To shut it down, ctrl+C

Connecting to the server:

• Launch putty: hostname=127.0.0.1, connection type=Telnet, port=23
• Type connect wizard to log in as a wizard (= Game Master)
• That's it. To say something, type say blablabla. help works as well. @create makes creating items with scripts possible.

Scalability definitions and milestones

Definitions

Scalability is a major technical focus for MMOG, but there are actually many different meanings and assumptions hidden behind the word. In general, Scalability is the capability of a software system to be adapted to meet new requirements of size and scope (Taylor et al. p467).

For system and network engineers, scalability can be achieved in two ways: horizontally (load balancing and clusters of multiple computing resources) or vertically (adding more power to a current computing resource). In both cases, if any of the layers of the stack (hardware, database, application and so on) does not scale, then the whole system won't.

For software engineers, a system scales well if its rate of growth is not greater than the corresponding rate of complexity increase (Taylor et al. p468-474). This definition looks a lot like positive scalability in system and network. However, software architecture scalability also deals with adding new components and takes into account the dependencies between components and connector logic.

Milestones

To my mind, there are so many definitions of scalability that it makes more sense to talk about domain-specific metrics meaningful to the end-users and stakeholders. The number of users is a perfect example. So here is a list of situations illustrating different meanings of scalability with different numbers of users.

Configuration	System/Example	Scalability meaning
Scalability milestones reached so far
2 or more players sharing the same game world state	Game development platforms such as Unity have quite hard times providing a transparent interface to sharing game world state. Each object in the world has to explicitly contain a Network View for it to be sent to other players.	Being able to send all relevant game objects to other players without the hassle of having to add a networking layer on top of them.
From 40 to 100+ users in the same world	Throughout 2009, Intel has worked on scaling OpenSim. They noticed that the number of users (as well as the number of object prims and scripts) were independent of the number of hardware threads available. This meant OpenSim could host no more than 100 clients, even if more resources were added.	Scalability was achieved through an impressive cleaning and optimization work from both software and netsys engineering perspectives. Adding a server to the back-end means being able to handle more users (thanks to an inter-shard daemon mechanism of some sort). There is still a problem, though: if everyone goes on the same shard, the shard crashes. Sharding originally comes from the database community. It has been applied to the software architecture of military simulations in 1995: 1000 users can be supported simultaneously. Current MMOG architectures still cut their world in maps (shards) to be able to use this principle.
Inter-server events	Cross-realm pick-up groups in WoW. Opensim's hypergrid foreign user information stored locally and non-persistently on remote servers.	In this case, scalability sounds more like portability and data compatibility (as the number of users involved stays relatively small). Also, an extra layer of logic can be added: in WoW, experienced players can be grouped with novices so that cross-realm groups are more balanced. But ... on which server shard(s) are these instances stored and computed?
Cloud gaming (Gaikai or OnLive)	Streaming video to computers that do not have enough graphics power to run the game themselves	A pure example of horizontal scalability: more computers in the cloud means more users.
Scalability milestones not reached yet
1000 players seeing and interacting with each others	Giant boss battles, live events, voting in Parliament	1) Clients must still be able to compute the graphics and 2) the server has to be able to cope with the sudden and unusual overload (dynamic resource re-allocation? Hybrid architectures mixing P2P and client-server?)
Cloud gaming for MMOG	Cloud gaming NOT as a service on top of existing gaming infrastructures, but as a graphics help for weak clients of an MMOG	Some MMOGs have high-end graphics. And there is always a server doing various computations. In the end, the overall architecture would approach something like: weak client <-> "middlebox" shared with a few other weak clients for the graphics <-> game logic server. But this naive method consumes a lot of resources and can certainly be optimized. It sounds a little bit like booster boxes.
10.000+ players seeing each other and interacting with some	Stadiums, French demonstrations	For the server, scalability means 1) being able to distinguish who can interact with who, 2) allocate resources dynamically (as these events are temporary and can be spontaneous) and 3) approximate distant actions and determine which clients share the same content locally so that some computations can be factorized. For the client, graphics might get demanding.

Indie game developement and polishing

Video games are among the most complex softwares to design and implement. They deal with graphics, database, UI and so on. Yet programming them is very accessible: there are books, forums and frameworks for game programming in nearly any language. All recommend using rapid prototyping, and player-centric game design requires a design -> code -> test -> redesign loop as short as possible. After a few iterations in the loop, game development can get very messy if the code has not been organized into components. Software components are embodiments of the software engineering principles of encapsulation, abstraction and modularity (Taylor et al. p69). In other words, building a game from early prototype to end-product requires modularity (and therefore components). More generally, modularity is the key to adding and editing features in rapid prototyping and agile software development processes.

But looking at game repositories such as pygame, it seems the myriad of small projects it contains seem to pay no attention at all to modularity. I think they may have started all right, but as development progressed, the code got tangled without them noticing it. Locating themselves in the development process became more and more difficult. In the end, their project does not have any distinct component, they have three 500-line files named "main", "game" and "classes". Each of these files contains more or less the whole game and does not have any comment. The game is certainly working, but it is ugly and buggy and does not give a good experience to the player.

Braid is the opposite. It has been polished to provide a unique experience to the player. Images taken from the Gamasutra article about The Art Of Braid: Creating A Visual Identity For An Unusual Game.

Reknown game developers such as Chris Hecker ranted about unfinished games. Hecker gave the example of games (or rather game design proofs-of-concept?) developed in less than 20 hours. Cactus, the main indie developer targeted by Hecker, explained that his mentality was to make games available for others to be inspired by. Other indie developers of growing fame such as Mathew Galant disagreed cautiously: nobody can create a masterpiece without first making a hundred crude sketches, and It's better to get those ideas out there, even if they're flawed and incomplete!

I think there are very distinct categories of indie game developers: veterans, explorers and beginners. For veterans such as Hecker, agile processes promote sustainable development (taken from the Agile Manifesto). For explorers such as Cactus, agile is actually cowboy coding (not in a derogatory sense). For beginners, agile is a way to learn. Voluntarily or not, explorers and beginners do not pay attention to modularity. In my opinion, this is what sets apart veteran masterpieces from beginner and explorer trials.