“Mirage” means several things to me. I have used the name for my Second Life avatar, who is also the main character in my comic, for example, but what I’m really doing with that name is simply seeking a poetic synonym for “avatar.” Technically speaking, a mirage is a reflection or refraction of light through air due to sharp temperature differentials. Poetically, it is a shallow copy of something, having the appearance — but not the properties or identity — of the thing being copied.
I’m not suggesting “mirage” is a better word for “avatar” than, well, “avatar.” I am explaining why I have used it for my SL identity, and why I have used it for my new project, which is what I am referring to in this post.
Mirage is a framework for building games and virtual worlds. It is at once an API, an engine, and a design. It is intended to be like the Web. It doesn’t speak HTTP and it doesn’t run inside a browser, as both of these would be pointless hindrances.
Instead, Mirage consists of a suite of concepts at its root. These concepts are simply described in terms of how they relate to one another:
- The Browser is exactly what it sounds like. Instead of visiting websites, which are conceptually collections of related web pages (and other content), the Browser visits Worlds.
- A World is logically similar to a website and consists of a number of related Places. Like websites, some Worlds may require you to register and/or log in (and possibly pay a fee) in order to use some or all features of that World. A Mirage World might be a simple social space, an open virtual reality in which users can upload and place their own content, or even an online game.
- A Place is an individual location where users’ avatars can gather to play, socialize, build, or do whatever it is that the World enables them to. It is logically equivalent to a web page, though a closer analogy might be to a room or zone in a multiplayer game.
Those are the three main components. In addition, there are static data servers (simply HTTP servers) which World owners provide to allow Browsers to download the World’s static data – which might be maps, avatars, objects, scripts, screen elements, fonts, and/or anything else that the World needs to run that doesn’t need to change.
This project is progressing again after some stagnation. I had to redesign the networking module, which was way too unreliable and didn’t fit well with Pygame at all. I’m also having to rewrite some of the things that connected too closely to the old networking system, like storage of shared data, which was poorly designed and used directly by too many pieces of the code.
With these redesigns, I should be able to stabilize the velocity and trajectory of this project and get to alpha before I get bogged down in something else. At this point my major concerns are developing more test content, putting together tools to help with authoring and publishing world content, security concerns (Python will have to be sandboxed for client-side scripts for the same reason that JavaScript is in web browsers), and fleshing out things like visual effects, configuration, and the scripting API(s?).
That may sound like a lot, but I already have a networked client displaying an isometric tile map with placed objects and avatars which can chat, move around the map, and play animations and sounds, and I’ve done just enough optimization of the rendering and data storage mechanisms to make the client load up in a few seconds and then freely scroll an enormous (10,000×10,000 tile) map at a good framerate thanks to aggressive culling of the render frame.
I realize most of what I’m doing here has been done before, but the concept itself is quite novel, and I’m reinventing the wheel in places intentionally — this is intended to help me to learn many different things about game development and design, from low level optimization skills like culling and caching to big-picture design methods and the ability to write approachable, flexible, and maintainable code, APIs, and tools.