The Universe is a Big Place ...

Ok anyone who has done any sort of research on the universe at all, or attended some basic science classes, or opened a book, or looked up into the sky ... ect, knows that the universe is big. Very big, really big, we has humans cannot even grasp exactly how big it is much less see across the whole thing. Currently we can see somewhere like 13-14 billion light years away because that is how long it has been since the big bang.

So what?

Some games have lots of different playable worlds, which according to string theory is plausible, but the main reason for this has been server limitations. For a web-based mmo game however there is no real good reason for this limitation if you design your engine to work across multiple servers. Their has been great advances in cloud computing so as such I believe it is entirely feasible to create a JavaScript version of this and apply it to an mmo game.

I very much believe in the K.I.S.S. method even in programming. I've seen many programmers over complicate things just to prevent theft of their work or to justify their jobs. In it's simplest form this is what i'm thinking:

Servers ...

1. 1 login server
2. 1 chat server
3. 1 AI server (?: possibly a cloud depending on the number of units it needs to control)
4. 1 server for every X number of users
5. 1 database server (?: possibly it's own separate cloud at a later point) to bind them all in darkness.
6. (?: possibly) Star-map server. The only thing it does is path-finding as the star-map is fixed. Would be a behind-the-scenes server like the database-server.

With exception of the database server itself all of the other server programs should be a single entity to make installing and expanding easier. The base program will load the required modules for that type of server so as such initially they can all be loaded onto a single server and then expanded outwards as required.

Client Side ...

• Each user is given a list of of user servers (#4) to poll for data, the system polls the list and uses the one with the fastest response time.
• The servers are re-polled every (x) minutes to help reduce server lag and overloading.
• Script will keep track of data return times and will force a re-polling in case of lag from a single server.

So it seems fairly simple and as such should be possible, but what about new players?

• Players are not given a starting world, they must find their own world to colonize (possible addition to 'autopilot' to a inhabitable planet.
• Players are given a copy of the the latest available copy of the compendium (all publicly available knowledge)
• You start as a colony of the faction you choose, not your own independent nation (this however does not mean you can't be attacked even as a noob).
• Technically speaking you can be a leach and never leave your colony and never perform any research at all. Factions share group knowledge with their members including leaches ... this however may make your leaders unhappy but that is up to the players themselves.
• New players will naturally migrate out towards the edge of the known galaxy.
• Their are fixed travel lines between stars (though it is possible later to circumvent these travel lines but it takes a much longer time)
• More than 1 player can inhabit the same planet ...
• That's right you can start on the same planet as your bestest buddie in the whole world.
• You don't have to colonize a planet, you can choose to build a space colony instead. Though this idea does have strategic advantages it comes with it's own obvious set of problems such as expense and habitation limitations.
• Shared Knowledge: Just via interaction with other players, trade ... ect. Knowledge is shared with each other in the form of bonus points, the time it takes to research something is reduced.

I will expand more on these ideas in later posts.

Moving, ugh!

Ok, so for like the next two weeks we seem to be renting two places at the same time, talk about expensive ... but can't afford for me to take any time off either. So for my next couple of days off will be spent trying to get the lead out of my butt and get this moving thing done. Good news about the new place is the fact that we will be paying less rent than what we are here, and we'll have about 400 sq ft more space! The wife and I are definitely hoarders and seem to have issues throwing anything away! lol. Instead it get's tossed in a box where it will remain for 2-5 years before donation to the salvation army. :p

I've set my DVR to record episodes of 'The Universe' on the discovery channel to see if I can get some more ideas for the Nemesis Star game. Still thinking to do that one first but at this stage I'm still flip-flopping quite a bit so anything is up for grab's. Everything that will be needed in both games is very similar for the JavaScript engine, the only big difference is the addition of a flat or 3/4 view perspective in addition to the isometric drawing routines ... which is infinitely easier.

For the server side I've been doing some research on SSJS (Server Side JavaScript). There seems to be way too many choices and confusion about it with little real information. I have though ruled out using any SSJS engines that are programed in php or any other server side scripting language ... i don't mind sacrificing a little bit of speed for ease of use, but not that much. Hell at this point it might just be easier to program the server side in C# with spider monkey overlaying it for the scripting routines.

Well i got to get my lazy butt to work get these next couple of days over with (work two jobs 3 days of the week). Then it's moving time! Ugh!

General Updates

Busy busy busy! The freaking Christmas season is almost here! Ok at least at good ole wally world it is. Yes yes, I'm still working two jobs one of which is for Walmart ... hey they have benefits! Just about anyone working in the computer field as a web programmer will tell ya ... unless you get a great gig working for Google or some other large company you probably won't get benefits anywhere. Getting ready to move soon again! ugh! but at least now with this move I will be 1.6 miles from work! which means more time to do the stuff I want to be doing (aka, this game design thing)

Was reading through a forum news feed archive and came across this: http://news.ycombinator.com/item?id=751075 Instead of resurrecting an old thread (3 months at the time of this writing) I figured i would cover one of the topics that someone their suggested.

CSS Sprites and Javascript Canvas ...

The long story short ... don't waste your time using CSS to clip the sprites from a large png image ... all the browsers have big performance issues when clipping and if your going to build a GUI or game of any real scale this alone will kill any good performance you would get. This isn't to day that the persons idea was so off either ... the advantage to using fewer files is faster load times especially if you are using xmlHTTP requests to tell it what files to load.

A simple tile prototype ...

function Tile()

{

this.img = new Image(); // create a new Image object.

this.width = 128; // width of the tile. defaults to 128

this.height = 64; // height of the tile. defaults to 64

this.offX = 0; //X offset for drawing abnormal sized tiles

this.offY = 0; //Y offset for drawing abnormal sized tiles

}

From the above i think you can get the picture here already ... you simply load the big file then you piece it out into actual tile objects thus pre-clipping everything. You get the speed performance from using smaller images that don't require clipping and reduce server latency time because you are pulling fewer files.

Also another way to get great performance increase ... use multiple canvas's! ... How many you use and what each of these layers does is of course entirely up to you just remember that the top most layer is the layer the user actually interacts with for your event processing.

If their is interest i will discuss this in greater detail with actual numbers to back up my claims here. I've done quite a bit of testing and this is the fastest way to process canvas games of any real size or scale.

M. Hagston