kylratix

Fixed the bug where the applet wasn't loading for most people (other than me, apparently). Thanks for the emails!

Ready for a test run: http://subcomm.net/ The project is open source (BSD license). Details are on the "project" tab of the UI. Java used for the protocol IO. JS used for the application and UI. This project is available at: https://github.com/r...rie/subcomm-web The project for the SubComm Netchat library is available at: https://github.com/roylaurie/subcomm The project for the SubComm client applet is available at: https://github.com/r...b-client-applet What say ye?

ETA alpha server / client?

Sure. It also reduces the amount of code that you have to maintain on the server.

Nice. And a quake-style console (~) to go along with it all? =D

I don't see a lot of complexity in: if (input.startsWith(COMMAND_DELIMITER)) sendToHost(input); else sendToChat(input); Along with importing a 3rd party library to handle connection setup to the chat server ... 100 lines of code? 200? XMPP and IRC ... there are pros and cons between the two. GameSurge IRC network doesn't have as huge a limitation on nicknames. XMPP is awesome, but also consider that now the server admin has to run an XMPP daemon along with an SS daemon. IRC traffic is being offloaded by someone else. In IRC, you can control channels via channel services and bots (see PIRC library). It's easier to have redundant bots than redundant end-user services. You're not handling the client connection.

btw, why have the server handle chat? it's extra load without much benefit. the client could just use irc. the nice part with that is that the server's social pull would span beyond in-game stuff. regulars could chat throughout the day without having the game open. (at work using pidgin, adium, etc.)

i thought they disabled the api? [edit] ah, correction. it's just not free anymore.

That brings up another point though, you could make all of the interface components as windows that can be moved, pinned, and/or pinned seamlessly. This would make it easy for mods to swap out interface components. For example, if Cheese wanted to run a server that represents energy/health by unicorns rather than a bar, he could.

Hot. How about dialog windows that can be fed an HTML view? You could define an out-of-the-box CSS that works with your GUI. Server plugins could simply call your API and point at static html/css/js files.

+1

If you guys need an extra hand with that, hollaaaaa. http://nerdsatthecooltable.com/wp-content/uploads/2009/12/holla.jpg

Right, that was my point.

Hmmm ... You've attributed that success to the closed source model, when it sounds like it was really due to good project management skills and wise leadership on behalf of you, Priit, and the rest. I don't think it would have mattered what source control system you used there. The centralized leadership system you're using still works and is a necessary element in an open source or even distributed open source workflow.

I totally agree that 'security by obscurity' has been working and is working now. I think that, maybe, I have a different opinion on why it's working and, most importantly, what "obscurity" means within the context of ASSS's success. It's successful here because: ASSS moved code/logic out of the client side and on to the server, limiting what could be cracked. Sadly, nobody cares about subspace, limiting who is cracking. Most of the people playing it are people who knew about it from back in the day. We have less people playing than we did at Subspace's height and certainly far less attention than any "current" multiplayer game. In regard to #2, I assume that cracking, crime, or any activity, is a somewhat predictable ratio of the regular community. For example, if 1% of players attempt to crack SS, with 1000 regulars or so, you might have to deal with 10 crackers at any given time. Of that number, maybe 1 of them at any given time is successful. That's not that bad. You have enough programmers easily. However, if the project is successful, Subspace is re-invented, and new crowds are attracted, that pool of potential exploits is going to increase and the code, never being perfect, will need to be maintained for security with far more programming hours involved. In the end, I think that it comes down to each gaming community policing itself, which is why I think it's currently successful here. I see people actively report all the time. That's what's really stopping crackers. You know the people that you're playing with and when someone is cracking or cheating or spamming, it's obvious, you notice them immediately, and they're booted. Other humans are your real asset in security, not software, in my opinion. I'd focus on harnessing that. Closing your source code off won't prevent people from using tcpdump and that's all they need. What it will do, though, is limit the number of programmers available to your team that can respond to cracking attempts or, more likely, identify potential security flaws ahead of time and prevent an exploit before it's used.

yeah, i've used many of them at different jobs. cvs, svn, hg, p4, and git. git, so far, git is my favorite. the only one out of that list that i hate is cvs. bitbucket, meh. not to mention, a private repo? security through obscurity isn't going to work. people will crack it, regardless. there are plenty of closed-source / private games to prove that one. open arena (quake3 gpl) is a fine little community and they're open source. you're always going to have hacking...

i'm a java developer and would love to pitch-in with a mini-sprint every week or two. however, please, for the love of god, don't put it on sourceforge, dropbox (wtf?), or use anything other than github. github will make your life easier. cheese's comment on decentralization goes for source code as well. in github, just create an account for -yourself- (github.com/jsmith), put the project up there, and anyone with an account can fork your project. when we want our changes added back to you, the project owner, we just click "request for pull". you accept, make sure it doesn't suck, then merge in the changes. p.s. the workflow i'm describing here is shown on this page: http://progit.org/book/ch5-1.html as "integration-manger workflow"