FANDOM


Future This article or section contains information about a scheduled or rumoured future release or update.
As such, the information found in this article should consist only of facts said in official Jagex releases, but NOT speculation.


FunOrb Central is a planned central lobby for FunOrb. It will be similar to the Games domain castle and the old Jagex Multiplayer suite. It was first mentioned in the Funorb questions and answers post and then there were three Developer Diaries about it.

Question and answers relating to it Edit

  • What will happen to the unpopular multiplayer games? -Dr Korvett
  • Private chat in single player games? -Dr Korvett
  • Can we get a “small virtual funorb world” that links to all multiplayer games? - Pieceofcake8
  • What is the plan for the deserted multiplayer games? – Evil Yoyo
  • Do you plan on introducing Clan Chat into FunOrb? It would be a great addition. You should also allow us to start a conversation with a friend while in a game. – Evil Yoyo

One of the major system-wide development projects currently under design is “FunOrb Central”. This is our global lobby system. At the moment, you enter a game and then enter the lobby/chat element of that game, in order to set up a multiplayer encounter or just to socialise. With FunOrb Central, you will enter the lobby first and then select the games you wish to play. This will let you do a lot of things that are currently impossible:


* Look for players for one game and go and play another whilst you wait.
   * Chat in single-player games.
   * Flag yourself as interested in different multiplayer games
   * Add and remove friends and ignore list players
   * Clan chat
   * Plus a lot of other stuff we are still designing


This is major undertaking for the developers and technically very complex. It’s likely to take some time before it gets released, but we think it will provide FunOrb with a world beating, gaming and socialising web environment. Expect a development diary on this topic in a month or two. – Mod_Korpz

Development Diary One Edit

Here at Jagex, we're always keeping tabs on the FunOrb website. There are many aspects that we like - the games, for example, and the sense of community that can be seen on the forums and in the lobbies - but there are improvements that we think we can make. That's why I'm excited to be working on FunOrb Central; a radical update to the FunOrb service. While the project still has a long way to go, I'd like to tell you about some of the neat things we're trying to do.

For example, at the moment, it's not possible to talk to friends on FunOrb unless you're in a multiplayer game or on the forums. We really like the interaction between players on FunOrb, and we'd like to let you take that even further. So, we thought it'd be fun to develop a chat service that spans across all of the games - even the single-player ones - letting people talk to friends and join chat channels wherever they are on FunOrb.

Another thing that we find annoying is that in some of the less frequented multiplayer games, it's possible to spend a long time waiting for a game in an empty lobby. With FunOrb Central, what we'd like to be able to do is let, say, those die-hard Pixelate fans among you (we know you're there, hands up!) keep an eye out for a game starting, even while they're perfecting their technique in Vertigo 2.

Still on the topic of multiplayer games, it can sometimes be a bit of a hassle to start a game with your friends - you have to first log on, find the server they're in, switch to it (reloading the game), and even then they might already be playing someone else. It'd be much easier, we think, if your Friends List could tell you where each of your friends is and what they’re doing, then give you easy options to invite them into games or join them in theirs. Server-hopping and long delays would become a thing of the past.

Finally, FunOrb sometimes feels to us like collection of separate games, but we'd prefer to see it more as a service. One of the more powerful features we're adding to FunOrb Central is a unified game loader, so you won’t have to keep bouncing backwards and forwards to the Game List - all the games will be available within the same Java applet! You'll be able to quickly flick through all the games to find one you like, as well as review your Highscores and Achievements in each of them.

As you may be able to see, this is going to be a major update, so developing it will bring with it its fair share of problems. In the next diary, I'll run through some of the ones we've encountered so far, and how we plan to resolve them.

Mod Artifice FunOrb Developer

Development Diary 2 Edit

This diary covers one of the most significant problems involved with building FunOrb games and FunOrb Central: memory consumption.

Memory inside a computer forms a pyramid of sorts. At the top, there is a small amount of very fast memory embedded into the processor (cache). At the bottom, there's a slow, but very large capacity memory (the hard disk/drive). In between these two, there's the type of memory that’s relevant to this diary, which is commonly called core or main memory. Managing the transfer of data between these three types of memory is an important aspect of development, as it heavily affects performance.

When a Java applet (e.g. a FunOrb game) is running, it is stored in this main memory. All of an applet's resources (e.g. graphics, music, sound effects) must be held in memory before they can be used. Unfortunately, the most commonly installed versions of Java limit the amount we can use to around 64MB (referred to as 'the heap'), and it's already very easy for the resources of a FunOrb game to overrun this limit. A background wallpaper the size of the average screen takes about 1MB, and large backgrounds (e.g. an Arcanists map backdrop) or sprite sheets (e.g. Tor Challenge animations) can take more.

FunOrb Central restricts things further, as both the game and FunOrb Central need to run within the 64MB limit. To help alleviate this problem, we're aiming to get FunOrb Central running using no more than 10MB of memory, leaving 54MB for a game. Many FunOrb games require more than this at present, though, so we'll need to go back and amend them, which will require some technical work from the entire FunOrb development team.

Here are a couple of the techniques we'll use:

1. Throwing away content that's no longer being used (e.g. an intro sequence, once it has finished) It sounds simple, but there are complications. We can't predict when data will be needed again, so we'd prefer to keep everything in memory for speed. When that's not possible, we'll sometimes keep hold of a compressed copy instead. It's not quite as fast, but saves us some space.

2. Changing the format of data in memory When we're choosing how content will be stored in memory and for download, it's always a trade-off between performance, quality and size. Generally, to maximise the speed of our games, we'll go for the least compressed version, but memory constraints mean we might have to use other options, such as compressed images*. The trick is to make sure that any loss of quality or performance isn't noticeable to the player.

Even using these techniques is not going to be enough for us to get FunOrb Central working within a 10MB limit, so, after discussing this with Andrew, we plan to have FunOrb central do something sneaky... There is a group of technologies that were added to Java a couple of years ago, with the somewhat arcane name of 'NIO' (new input/output or non-blocking input/output). They were primarily intended to let Java applications access files and network devices at high speed, but they have an interesting secondary ability that lets applets allocate a bit of extra memory outside the 64MB limit. Using this technique, we hope to be able to have FunOrb Central store most of its data in this 'ghost space’, pulling only the parts we need into main memory and only for the duration they're required.

The other aspect of memory management in FunOrb Central is what to do when more memory is available for us to use. In more recent versions of Java, for those players who've tuned their memory settings to allow it, applets can access more than 64MB. We want to make sure that, where extra memory is available to us, we make good use of it. Some of our existing games already do this using a Java technique called 'soft references'. It’s a way of asking the Java implementation to try to keep data in memory, but allowing it to drop it if space is becoming tight. For example, you should get better performance in Dungeon Assault with more memory allocated to it, as it won't have to keep decompressing the animations. Along these lines, we'd like to have FunOrb Central keep entire games loaded in memory, providing enough memory is available, which should give improved load times for games when using more recent versions of Java.

So what does this mean for you? Essentially, FunOrb Central will have similar requirements to all existing FunOrb games - if you can run those, you should be ready to go - and it will be able to make better use of resources on computers with more recent versions of Java. We'll be more specific about the requirements and recommendations closer to launch, so stay tuned!

Mod Artifice FunOrb Developer

  • For example, photographic images are often compressed as JPEG (or JPG), which allows for detailed images at a fraction of their uncompressed size, and with minimal loss of quality. Unfortunately, decompressing such images to render them is slow - too slow to use compressed images for every frame in a game.

Development diary 3 Edit

Some of the new technologies we're integrating into FunOrb Central are improvements to the graphics libraries.

At the moment all FunOrb games display graphics using software rendering. This means that the computer's processor is responsible for all the drawing that the game performs, setting each individual pixel one at a time.

This certainly gives FunOrb games a great deal of control over their graphics, and is fast enough for most purposes. It does mean, however, that our games are what's called 'fill-rate limited' because each pixel that we change requires (more or less) one line of Java to execute. Therefore the performance of our games is chiefly limited by how many pixels we need to draw to in each frame.

Among other things, this limits the resolution our games can use. Let's imagine we have a standard FunOrb game, with a 640x480 pixel window (that is, around 300,000 pixels total) and that, on my computer, the game is managing to redraw the game 30 times a second (30fps). Doing the maths, my computer can write (set) around 9 million pixels per second. (As an aside, that's guaranteeing that each pixel is only set once - it's not always reasonable to arrange that.)

Now let's scale things up. The next standard window size we have available is 800x600. Now, to draw our game to the screen, we have to write nearly 500,000 pixels per frame. With my computer's 9 million pixels/sec budget, we're now only managing 19fps - which is getting to be a little on the slow side. At the next size up (1024x768) we get 12 fps, and as we approach cutting-edge gaming resolutions (1680x1050: 5fps) things get unreasonably slow.

As part of our plans to extend FunOrb games to these higher resolutions, we need to change our approach. There's a piece of hardware built into modern computers called a Graphics Processing Unit (GPU), which accelerates your computer’s ability to process graphics. It's used by modern games (including RuneScape HD) to run high resolutions at blazing speeds, and we're keen to take advantage of these capabilities with the next generation of FunOrb games running within Central.

The key advantage to using hardware accelerators (such as a GPU) is that they're capable of offloading work from the main processor (CPU). Whereas a FunOrb game currently has to individually copy each pixel from, say, a Kickabout League pitch texture to the screen, it could just request that the GPU perform the copy and the CPU could be used to calculate physics for the ball in the meantime. Also, because the GPU is a specialized piece of hardware, and running without the overhead of an operating system or Java environment, it can do much more work per frame.

One thing we'd like to do, then, is amend some of our existing games to use this to allow higher resolutions, starting at 800x600. We'd also be particularly interested in eventually supporting widescreen modes for FunOrb games.

As you may have guessed, though, there're reasons we haven't done this already. There are two key problems with using hardware graphics acceleration, even when we're technically capable of it: One is that a lot of GPUs currently around are what's called 'fixed-function' - that is, there's a limited set of operations that they can efficiently perform (unlike the general-purpose CPU, which can be programmed to do just about anything). Some games work perfectly fine with this so Arcanists, for example, only really needs some sprites (images) copied to the screen, which is well within the capabilities of even the most basic accelerators. Other games, though, such as StarCannon, use more advanced effects, such as outlining, blur, glows or ripple distortion. In cases like these, some more effort is needed; we have to decide if the existing effect can be replicated, or, if we need to replace it, what can we use in its place that uses the additional power of the hardware?

The other main issue is that of compatibility. If you've ever visited the Java Options menu in the FunOrb site, you may have noticed there's an option to choose between signed or unsigned applets. Signed applets, assuming you permit them, have a bit more control over your computer - including the ability to access your graphics accelerator, if you have one. For those players that aren't able to run the signed applet (usually in places like offices or libraries, where the security settings on the computer don't allow it) or players who just don't possess suitable hardware, we need to make sure that the software mode of FunOrb games continue to be as good as possible - this can take additional time to design, develop and test.

I think the advantages, though, are worth it. While we're probably not going to be able to launch FunOrb Central and immediately have all of our games run at higher resolutions, the work we're doing on it at the moment is certainly laying the foundations. I'm looking forward to having more screen space to play with, both as a developer and as a player, as well as the possibility of yet higher detail modes. Just as a taster, have a look at the Kickabout League and Shattered Plans images.

Mod Artifice FunOrb Developer

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.