StarDestroyer.Net BBS

I think I have an awesome, some what simple, game idea I would like to discuss, and possibly devlope. Right now I want to see how complex it actually would be to carry out. (I am decent at 3d graphics for modeling and such)

Basiclly like a tradewars type game in a potienially unlimited galaxy to explore.

my email address is altar000altar@yahoo.com to learn more about the basic concept. Both AIM and yahoo names are altar000altar . (The "000"'s are zeros). Only looking for some serious people.

Sam Or I wrote:I think I have an awesome, some what simple, game idea I would like to discuss, and possibly devlope. Right now I want to see how complex it actually would be to carry out. (I am decent at 3d graphics for modeling and such)

Basiclly like a tradewars type game in a potienially unlimited galaxy to explore.

my email address is altar000altar@yahoo.com to learn more about the basic concept. Both AIM and yahoo names are altar000altar . (The "000"'s are zeros). Only looking for some serious people.

What you're using as language and 3D system?
Already have thoughts on the AI system?

I think we have a couple of programmers, The Shadow, Durandel, and afew others.

me too, but i'd like to know what exactly the idea is, what platform, language, etc

I'm a programmer, But I'm aready booked up a Utopia clone I've been helping write. As well as World of Warcraft eating my time, and work experiance(as a sys admin) starting again soon with the possibility of payed work.

I'm a programmer. Work keeps me too busy to do any freelance programming, but I'd be more than happy to comment on your design plans.

OK, here is the basic concept.

We have all played tradewars right. The idea is basically the same thing, except in real time, in a galaxy of unlimited size. A MMOG of space trading games.

There will be 2 different parts to the game, a privateer, and a sectors governor.

The privateers client, would be basically a web browser, with a chatroom built in. Each sector would be nothing more than a web page running a sort of java script like a similar any other real buisness. Managing an numerical inventory and stuff like that. The jumpgates (aka hyperlinks to other sector webpages). Maybe your storage manifest would be in some sort of cookie.

So to put it simply you are flying a spaceship around the web, trading and making a profit.

As the sector governor, you would need your own webpage, where you could up load the sector script to the webpage, and manipulate it like a real buisness. You would pick a planet type, which there would be natural resource to mine or grow, then sell, naturally feeding the economy. You could select a 3 or 4 other sectors to be linked to.

So who ever had the webspace, could have a sector or 2. Thus eliminating the need for a massive game server, and giving the universe an unlimited size potenial.

Combat would be a direct linked system, only one on one, and kinda like a starfleet command lite.

Sam Or I wrote:OK, here is the basic concept.

We have all played tradewars right. The idea is basically the same thing, except in real time, in a galaxy of unlimited size. A MMOG of space trading games.

Haven't played it, but I think I get the concept.

There will be 2 different parts to the game, a privateer, and a sectors governor.

The privateers client, would be basically a web browser, with a chatroom built in. Each sector would be nothing more than a web page running a sort of java script like a similar any other real buisness. Managing an numerical inventory and stuff like that. The jumpgates (aka hyperlinks to other sector webpages). Maybe your storage manifest would be in some sort of cookie.

So to put it simply you are flying a spaceship around the web, trading and making a profit.

As the sector governor, you would need your own webpage, where you could up load the sector script to the webpage, and manipulate it like a real buisness. You would pick a planet type, which there would be natural resource to mine or grow, then sell, naturally feeding the economy. You could select a 3 or 4 other sectors to be linked to.

So who ever had the webspace, could have a sector or 2. Thus eliminating the need for a massive game server, and giving the universe an unlimited size potenial.

Why do you want every sector owner to have their webpage? A single serve can provide you with a very large number of sectors to begin with, and it elimates a number of issues (for instance, governors aren't going to want to have to buy their server - thats a huge cost for them - and it elimates the problems you have a distributed network, such how to update data and what happens if one server fails). Its far easier and much faster to run a single, beefy webserver that serves up all of your sectors and keeps all the info in a common database (this is how businesses do it). If your game gets really popular, you can always add a second server (it can either host the website, freeing up your first server for DB duties, or have it host a second site that shares data with the first).

Combat would be a direct linked system, only one on one, and kinda like a starfleet command lite.

How does the combat system tie back into sector system? Why limit combat to one-on-one? Why not have a convoy system, where pirates can hit your shipping lanes, possibly having a major impact on sector trade?

If they are web pages, how will it be in real time?

Oh no, you don't get first dibs on borrowing programmers to make games.

*Goes back to brainstorming 'Junkyard Wars'-esque HL2 multiplayer mod*

Mad wrote:If they are web pages, how will it be in real time?

It would be a web-app for it to be realtime; think about your credit card company, and how they can update your account info and display on their site right after you've made a purchase. Now, since it has to be a web-app, that means you need a web server (I guess Apache will do, I'm not a full-up web programmer) and a database server (which is what will keep you realtime and up-to-date; it can run scripts to modify all data in reaction to a change by one individual). This is also why a distributed system that Sam wants to is a bad and very expensive idea - its easier and cheaper to run one web-server and one database server in one box than to use mutliple boxes running web-servers and database servers that have to share data and stay synchronized. Not to mention backing up one back is a lot easier...

Arrow Mk84 wrote:It would be a web-app for it to be realtime; think about your credit card company, and how they can update your account info and display on their site right after you've made a purchase. Now, since it has to be a web-app, that means you need a web server (I guess Apache will do, I'm not a full-up web programmer) and a database server (which is what will keep you realtime and up-to-date; it can run scripts to modify all data in reaction to a change by one individual). This is also why a distributed system that Sam wants to is a bad and very expensive idea - its easier and cheaper to run one web-server and one database server in one box than to use mutliple boxes running web-servers and database servers that have to share data and stay synchronized. Not to mention backing up one back is a lot easier...

What I mean is, how are interactions done? While you're in a sector (a page), other players will come and go, buy and sell, get in fights, etc. How will these changes be reflected on the web page in real time? If the page refreshes every minute, that's still a bit of lag. Some players will have come and gone in that time. It would also be annoying to wait while the page reloads if it's a slow connection or server.

Basically, in order to be real time, the data presented must be sent out to all relevant players immediately. That way a player can just hang out in a sector and watch traffic and purchases if he or she wishes.

Reliability with many, many servers is also going to be a huge a problem. If each sector is its own server (or close to it), then it's possible for servers to go down. Since the layout is Tradewars-like, that means that it's possible for a player to get stuck in a sector if the sectors it links to goes down. That's frusterating. Expecting thousands of players to properly maintain servers is also a bad idea. If it doesn't pick up, the game will be very small.

A decent server should easily be able to handle thousands of sectors anyway.

Afraid I never mastered anything more complex than Basic, and when I quit I was only beginning to explore the 3rd Dimension(TM) of programming.

Mad wrote: What I mean is, how are interactions done? While you're in a sector (a page), other players will come and go, buy and sell, get in fights, etc. How will these changes be reflected on the web page in real time? If the page refreshes every minute, that's still a bit of lag. Some players will have come and gone in that time. It would also be annoying to wait while the page reloads if it's a slow connection or server.

Basically, in order to be real time, the data presented must be sent out to all relevant players immediately. That way a player can just hang out in a sector and watch traffic and purchases if he or she wishes.

I think for this case real time can be acceptable defined as thirty seconds or so. I'm think frames will have to be used, with information frames set to refresh at an acceptable interval. This also means they data needs to be as small as possible.

It would probably be better if an applet was coded up for this instead - it could keep all the graphics/symbols loaded into memory and just get very small status updates. That would also reduce the server workload (send a data struct is a lot less work than sending a pretty webpage).

Arrow Mk84 wrote:I think for this case real time can be acceptable defined as thirty seconds or so. I'm think frames will have to be used, with information frames set to refresh at an acceptable interval. This also means they data needs to be as small as possible.

It would probably be better if an applet was coded up for this instead - it could keep all the graphics/symbols loaded into memory and just get very small status updates. That would also reduce the server workload (send a data struct is a lot less work than sending a pretty webpage).

Use of CSS can present a very nice looking web page with less HTML coding.

However, an applet would be a much better idea, I think. This makes setting up servers more difficult, but no more so than setting up a server for any other game.

A better idea, for reliability, would be for each server to be a galaxy. Each server/galaxy has thousands of sectors and has points where they can use a jumpgate to reach another server. If the remote server goes down, then the jumpgate becomes inactive.

Each sector can still have a governer and everything. Managing the sector could be done through the applet, so immersion is better for the governers.

Mad wrote:A better idea, for reliability, would be for each server to be a galaxy. Each server/galaxy has thousands of sectors and has points where they can use a jumpgate to reach another server. If the remote server goes down, then the jumpgate becomes inactive.

Would the galaxies affect one-other? Like trade routes and intergallactic empires? If so, then you still have a data-sharing problem if a server goes down (but much of a less of a problem that each sector being a server).

Arrow Mk84 wrote:Would the galaxies affect one-other? Like trade routes and intergallactic empires? If so, then you still have a data-sharing problem if a server goes down (but much of a less of a problem that each sector being a server).

I'd think the galaxies should affect each other. If a server goes down, then the jumpgates go down and there is no transition to those galaxies, so there's no data that can be shared anyway. So I don't think there'll be much of a problem.

Perhaps if the client detects that the current server has gone down, some event can occur to warp the player to an active server. To the player, it looks like a wormhole, powerful being, or whatever has interferred.

Arrow Mk84 wrote:Would the galaxies affect one-other? Like trade routes and intergallactic empires? If so, then you still have a data-sharing problem if a server goes down (but much of a less of a problem that each sector being a server).

You can have multipule webservers all cluster together by a DNS load-balancer.