whats wrong with having a server cloud for a social network app except for the money involved? a lot of browser based games have insane servers... if you build it capable of being big and dont used it how is that different from not using a bunch of the current features? what im saying is it would suck to have to rewrite it again because its too small for some mythical player upswing.

You should be more clear as to who the opposing view represent. The only issue that has been brought up is the node limit. It just does not look like it would be a viable solution to increase. Plus by increasing the node limit, then what happens to the stability of the TWGS itself.

From my perspective, I am not worried about scripts working or not. But I will remind you that this is not Smack talk, so keep your discussion civil please. If you wish to debate, take it to the proper section.

Sorry I’ve been focused on coding and haven’t had a chance to give my input on this thread. I’ve read everyone’s posts and I definitely understand the perspectives. In general, I’ve definitely considered the pros and cons of increasing the node count, and how to do that. However, it’s not as simple a decision as saying “node count should be as high as hardware can support”.

Many considerations go into this decision, and at this point, I’m actually on the opposite side. I think the 100-node capacity is too much. Right now there’s far too much fragmentation of the player base among the prominent public sites. Every site can run up to 25 different games and support up to 100 connections. If there were only a few sites with that kind of capacity, you might actually see enough activity on those sites to warrant that capacity. Even if the player base starts to grow, I don’t expect it to reach a level where we see the list of public sites reaching anywhere near the current node capacity. If I’m proven wrong, at that point I would consider alternatives. But at this time, based on the current state of the community, I am convinced that the better approach is to favor smaller private sites and decrease the number of larger sites. By having free access for personal games and inexpensive private servers, plus a handful of large public sites, it’s more likely that players from the smaller sites will seek out the small number of premier larger sites to compete in tournaments and high profile games. That would be ideal.

This was my goal when I decided on the new pricing options. If the goal is to increase node count, I’m going in the wrong direction. But if the goal is to increase the number of people exposed to the game while allowing an exclusive pool of large public games, it’s the right approach. With the new pricing, you get the full TWGS with TW Gold, all functionality, supporting a single game and a single connection, for free. This is essentially a “personal game”, though it would support an old-school “multiuser” game like we had back in the single-line BBS days. If you want to increase the number of games you can run, or the number of connections you can support, you can upgrade game slots and connection nodes for $2 and $3 each respectively. I expect this to greatly increase the number of small private LAN games where people can experience this game in a closed environment the way they want it to be played. The current pricing is too prohibitive for this kind of game, with TWGS Lite with TW Gold costing $60 for 4 nodes. A similar registration with the new approach would be 4 games and 4 nodes for $15. On the other hand, the new pricing should decrease the number of large capacity sites. If someone theoretically wanted to support 100 nodes and 25 games using the new pricing, the price would be $345. Of course I don’t expect anyone to do that, so I’m effectively saying the maximum capacity of these sites is going down.

Keep in mind, of course, that current registrations are fully supported, so if you have a full TWGS registration, you have your 25 game slots and 100 nodes. It’s only for new registrations that this disincentive for larger games comes into play. I consider this a positive, because I want to reward existing gameops by decreasing the competition against their sites, not undermine them by giving the game away and saturating the server pool.

Ultimately, my goal here is not to find the way to maximize my earnings for this game, but to find the way to maximize exposure to the game, and player activity. I feel strongly that the best way to do that is to have a pyramid where at the base you have many small personal and private games, and at the top you have a small handful of premier game sites where players from lower in the pyramid can converge for larger games.

Of course there is some flexibility here. If a particular game site is so popular that they can easily support the more than the 20 node capacity that I consider a practical maximum today, I will work with that game site to meet their needs, and to do it in a way that does not cost them $350. But I’d rather handle that on a case-by-case basis. Any one of you in this community who is truly hindered by these limitations, just talk to me and we’ll work it out, as long as it’s in the best interest of the entire community. But I’m not going to do anything unless there’s a clear need for it. It’s simply not the case that this game would benefit from 500 simultaneous connections. Sure, other games do have that kind of capacity, but this game was designed to support a relatively small player population per game. The game can be very fun with a player count of less than 20 in a game. And though a site could run multiple games with this kind of player count, they don’t need to. Why not spread it around so other sites can have some players as well? The max we should be looking at here is players per game, not players per server. The server should be able to support a maximum player capacity required by the game, and right now, 100 is more than enough, and 20 is a very reasonable number.

Here are a few other points on the subject:

1) The codebase is ancient and is essentially the same one that could run under DOS and Desqview. Though it’s been upgraded through Delphi 32 bit and is now only supported under Win32, it was never rewritten from scratch and there are many limitations that remain from that legacy code. One of the biggest issues is the fact that every connection must create its own process, and that’s a lot of overhead. 500 player nodes would mean 500 TW2002.EXE processes running. Even if the resources needed to support 500 players would be reasonable, the overhead associated with running 500 individual processes is excessive. I have worked on a new engine that would run all players for a game in a single process and a single thread, so the number of processes running would be based on the number of active games, not players, and that approach would be much more conducive to supporting thousands of players. That engine also uses SQLite for database, so it’s much more efficient and robust than the current flat-file engine.

2) Any kind of facebook game or any modern game is not going to support public servers. The facebook game will be a very different thing. It’s simply not possible to implement a game like classic TW for facebook. The best we could do would be to capture the spirit of the game in a much more casual and less interactive way. Other games may be more like the original, but initially would use an in-house server, and focus more on the player experience than the gameop experience. I do want to continue to explore public server games, but it’s frankly a much tougher sell. I can do it with classic TW because it’s essentially a hobby, but any effort to make a financially successful game will need to be more player-centered than gameop-centered.

3) On the subject of galaxy size, there are more considerations than field size, though that is a major one. Originally, there was a 64K cap on any allocated memory block, and that meant that only a 5K sector of max 6 warps, 2 bytes per sector (60K bytes) could be allocated. When the game got access to more memory with the DPMI and later versions, I got beyond this limitation by using blocks of sectors, so the map could be made up of 4 blocks of 5K sectors, and that’s what we have today. At this point, the maximum allocation block in Delphi is 2 gig, so it would be possible to have a flat map array of just under 90 million sectors. I would have to rewrite the sector manager and change all sector references to support unsigned int rather than unsigned word, but it’s technically possible. However, if I did that, then we start to see other bottlenecks. Having 2 gig allocated per player effectively limits you to only a player or two per game (depending on resources). Also, the pathfinding algorithm would not efficiently handle 90 million sectors. The solution would be to have bubbles, as has been suggested. But then there is the matter of having enough port names to fill all of the sectors. We currently support 16K unique port names. And then it’s not clear that the game would even be fun with so many sectors.

I took a look at what it would take to raise the sector count above 20K. The first major hurdle is field size, since the current code expects sector to be less than 32768 (a signed short integer because some negative sector values are used as flags). To avoid messing with changing to an unsigned word, I could shoot for adding 10K sectors for a 30K max. This would require the addition of about 12,000 port names, but I can achieve this by adding 6 more port name modifiers (like “New”, “II”, “Annex”, etc). That’s easy enough. In fact, I went ahead and did it just to see how easy it would be, and I’m supporting 30K sectors now. So that’s fairly trivial. The next threshold would be 60K or 65K sectors, staying under the word-sized field. In order to achieve that goal, I’d have to go through the code and make sure it doesn’t ever require the sector to be negative. That would be messy, but the real issue would be basically doubling the port name count from 2000 to 4000. That’s doable, but not trivial. I could raid some databases, like star names, maybe grab some wiki category lists for names and bulk up that port name list to 4000. I’ll consider doing that. But for now, let’s explore what 30K feels like. I think it’s worth doing for the pure novelty of it, but I’m not convinced the gameplay will benefit from it.

4) On the issue of how well TWGS will support large, active sites, I have been working on that, both on TW and TWGS, to make sure that the 100 nodes that it claims it can support can actually be supported. I wrote a tester program that scripted a number of different behaviors so I could test how the server handles a heavy load. Initially, I could crash the server very easily by having rapid connections and drops, and CPU spikes were common. One thing I discovered quickly was that the old Delphi memory manager leaks like a sieve. After some effort (and a new memory manager), I got it to the point where my biggest test had 60 connections jumping on and off the server, in and out of games, flying around the games, dropping carrier at random points, timing out, etc, and it’s holding up nicely (stayed below 60% CPU on my 2.5 ghz laptop, and plenty of my 4 gigs left over). So I’m confident that the server can support much larger node counts that it currently does, and that given sufficient hardware, 100 nodes is doable.

I hope this helps to illustrate what’s behind my decision on node count. In general, I’m open to extending the boundaries of the game, so feel free to recommend the things you think would bring the most bang.

I think you answered your own question - money, unless it is pay to play.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

if you have a bunch of players accessing an app on facebook with ad clickies you can get monies... like to cover the cost of said server... plus you could like 'sell' credits- spend 5 dollars get 2mil credits or something.

i understand the limitations of the old code now, but ive also said it would be a huge job to recode lol! i think if you can rewrite the node thing you could have one central 'facebook only' server and game, and get paid for it... i know thats not your goal but it is possible. now we see exactly how much is between possible and workable...

Does this mean the new twgs supports 30k sectors now?

H

Yeah, getting ready to post the update with support for 30K sectors (within the next few hours). Feel free to bang a test game with 30K sectors. If you want a new slot for it, let me know.

Is the new beta available to current gameops?

Gonna need an update for swath, it will only do a 20k database. Zoc and twx should work fine though

H

Sent the link of this thread to Stein so he knows what is going on.

Yes , swath will suport it ..

I'll have it in another hour .. but my guess .. is if in a slower connection .. timeout problems will accure if you have large grid in a 30k universe .. not to mention cim of the universe also.

but we will see I guess.

<A> TriCron Champion : No one           <1> Processing Interval    : 1 Sec
<B> TriCron Jackpot  : 0                <2> Inactivity Timeout     : 600 Sec
<C> TriCron HiScore  : 0                <3> Steal from Buy Port?   : Yes
<D> Ferrengi HomeBase                   <4> Planetary Trade Offers : 100% Normal
<E> Stardock Sector                     <5> Online Verification At : 600 Sec

I doubled the inactivity timeout and the online verification

Game H on the twgs.21-6.com is a 30k sector game.

H

So far , I've noticed a difference in login , J.P. said he would leave it so trigger
"Game Server" would still be usable ..
but in fact it is not , so I trigger on "John Pritchett." as well now

anyways , Swath will be repaired for that as well.

On to next change locating tour .. lol

Running around on worldtrade for a while then will flip to some wsst in a bit.

'Game Server' works for me in mombot for relogging.

Running Prom's ZTM41 now, seems to be working fine.