New Online Uplink(Hacking Simulator) Attempt

[nebulos_one]

I've been busy trying to create a new group to start putting together a new Uplink clone which will run completly using online technologies. Nobody seems interested in this kind of project from the other boards I've been posting around on.

Basically it will be a system based mainly on open source technologies. Currently, I've thrown together a few specs which can be changed if required. The backend is planned to be MySQL and PHP, while the frontend will probably be a fullscreen web browser session (no toolbars or status bar - these will be provided by web code) running javascript and an AJAX interpreter (probably Backbase). Data calls will be done via XML from the web browser based client to save bandwidth.

Personally, MySQL database is my forte - and I have above average PHP. I'm a little weak in the Javascript and AJAX (BXML) departments. I also have a large number of ideas in the works for enhancing gameplay and increasing User-To-User interaction in the game environment.

It's not much as I just setup the group, but the more the merrier (or is it too many cooks in the kitchen...). If anybody here is interested in having a look, checkout http://games.groups.yahoo.com/group/hacking_simulator/ - I'm always welcome to new ideas and enhancements.

[ScareyedHawk]

You will still fail.

[nebulos_one]

If people have that kind of attitude it probably will fail...

I've been in love with Uplink since it was first released years ago, I'm not planning on giving up on a new version that easily. Besides, if enough people are interested, and I do get tired of it (which I doubt), I can always hand control/coding over to other people in the group and it will keep on trunkin'.

[coolsi]

The problem is there have been many, many attempts at making 'Uplink Online' and none of them have got off the ground. Good luck with your project, but I'm afraid the odds are against you.

[Digital-NW]

You will still fail.

And people wonder why I never even bother to post in public forums here -_-

On a lighter note. Please check out http://www.onlink-mod.net

EDIT: I guess they have changed their focus over the years. :/
http://onlink-mod.net/new/modules/forum ... c.php?t=24

Note: This isn't an impossible project, but would require almost a complete rewrite of the core functionality in most areas.

[nebulos_one]

Digital-NW,

I checked out the onlink site you gave me, will have to have a look at this program closer when I get a chance. Seeing I'm looking to make the entire program run through the web interface with AJAX/XML and a MySQL backend to manage the large quantities of data required, The group will have to do it's own coding from the word go.

I appreciate the nudge in the right direction though, and as long as people sign up to the group and interest to create an Online version remains, I'm planning to do my best to make it happen.

Regards,
Nebulos_One

[Digital-NW]

I think that the program as a web-app is a noble idea, but I do not know how well it would actually work out honestly. I guess the future would prove this or not.

Given that though, if you would like a php developer (given you will even use php on the backend) I could probably help a little. My schedule is a little heavy, but I could offer up some spare time I suppose I went ahead and registered for your group.

[Krid]

This is quasirelated to the topic, but not actually addressed to anybody here. It's more addressed to people I've talked to about this and such.

Why is it that people who want to make a miltiplayer uplink so often seem to think that they should be breaking into people's ACTUAL systems (ie: client), and bouncing calls between ACTUAL (game) servers? I just don't understand it.

Uplink is a VERY low-intensity game, and it uses a custom client. There's no logical reason for each client to act as a server, or to have a one-to-one relationship between virtual and real machines. Having it be massively P2P as posed by the quoteblock on the onlink forums (Which seems to come from bonus content not included in the Steam release, sadly) seems more than a little strange to me.

The most reasonable way of handling it would be a client/server model similar to how it is in game:
1: There is ONE server to which all people connect. That server simulates all game servers. Eventually, it could do things like faking latency, load, and other such effects, but that's not very important.
2: When you connect your client to the server, you get a virtual virtual machine that acts as your gateway. When you disconnect, the 'machine' stops accepting 'external' connections and shuts down after everybody disconnects from it (Claim that you connect to it from a secure line which has WOL or something; getting hacked while sleeping is annoying).
3: As the players never connect to each other, they never need to know each other's IP addresses. As long as the server is secure, the players are in no danger. Further, with server-centric coding the worst a cheater could do would be scripting common actions - such as autodeleting logs.

etc...

[nebulos_one]

First of all, Digital-NW, welcome to the group. Any developers who have any time available are more then welcome.

Now, Krid, The model I plan to use is the client/server model. So REAL Clients connect to a REAL server. All the User-User interaction takes place in the "virtual" world, I do not intend to let players see each other addresses (that would be dangerous and plain wrong - I know a lot regarding computer security). I realised a long time ago a server/client model would be perfect for this kind of multiplayer scenario.

Basically, the clients will be interacting with and updating SQL database tables and reading the results back to themselves. Being the whole thing can be web-client based, the idea is to download an AJAX web page + graphics when the user logs in so no more HTTP downloading takes place (download will take about 30secs to 1min from previous AJAX experience). The client "script" can communicate using XML calls to PHP scripts on the server. This method is good as it drastically cuts down on bandwidth during game play and increases client update speed, it is also secure as data can be encrypted/decrypted comfortably at both ends. Apart from this, if the client is web-code based, all major browsers can read the code and it becomes platform indepentant. (Windows, Linux, Macs, whatever can play it as long as their browser supports it).

Hope this answers some of your concerns.

Regards,
Nebulos_One

[Krid]

I know what AJAX is, although I have to admit that I'm concerned about the effects of latency.

I'm also concerned about the bandwidth requirements involved, since downloading the interface will put quite a bit of extra load on the server, let alone the extra bandwidth resulting from the fact that it is AJAX, which isn't exactly the most efficient means of handling a game's netcode.

Mostly, that rant was about people who I've spoken too about it.

[Digital-NW]

I know what you are talking about Krid and I must say, people that actually think that including the REAL client of a palyer in the game world would make gameplay fun is just retarded. At the very most, not that I would really want to do this anyway, I could see that a virtual player could come under attack via their gateway connection to the virtual world while they were playing. But I would never even begin to think of going beyond the virtual world (not even a "virtual client" that runs on the players real computer). It is just silly talk.

On latency, the way I see it, even in the real world I would see latency affecting the client. I see the gateway as an RDP type session between the player and the server. If they are having a high latency times, of course (I don't want to say we cause I'm no spokesman, but there is no better word) we would definatly want to do the best that we can to reduce it, but even on a program the latency times could be just as bad as a web app. I'm not sure of what more we could do about it.

[Krid]

I know what you are talking about Krid and I must say, people that actually think that including the REAL client of a palyer in the game world would make gameplay fun is just retarded.

Agreed. Hacking into other peoples' actual clients would be a meaningless distinction anyway, since from the perspective of the person doing the hacking the only thing that changes is the 'IP address' of the target system (And that the "firewall bypass" would actually bypass firewalls).

On latency, the way I see it, even in the real world I would see latency affecting the client. I see the gateway as an RDP type session between the player and the server. If they are having a high latency times, of course (I don't want to say we cause I'm no spokesman, but there is no better word) we would definatly want to do the best that we can to reduce it, but even on a program the latency times could be just as bad as a web app. I'm not sure of what more we could do about it.

There's a difference.
First: Every single action that the user took would have latency in the 0.5-1.5 second range at best. Standalone clients can mask this for the user so that they can't tell the difference, but I'm not aware of any AJAX setup that can handle lag compensation.
Second: AJAX needs to refresh a dataset constantly in order to keep it updated, which means a tradeoff of bandwidth, server load, and update frequency. A standalone client can be notified of changes instantly, and the server immediately knows if the client got the information or not.
Third: If a connection drops with AJAX, the server can't tell if the person has been disconnected or if they are just not clicking on anything. If it drops on a client, the server can tell that it's not responding to packets.

While it's fine for Player VS NPC hacks, it wouldn't exactly be the best choice for Player VS Player hacks. People with troubled connections would be targeted for the easy kill.

IIRC, AJAX uses plaintext XML data, which means FAR more data has to be sent and recieved in order to get the same message across.

Take adding a bounce to a chain, for example:

For a standalone client, you could do this with two packets. One down, one up.
Client->Server: [16bits][32bits][64bits]
[16bits]: Code for add link. I doubt a 16bit addressable space would ever be exhausted.
[32bits]: User ID for person doing the linking. 2^32 is more than enough for any concievable number of players.
[64bits]: IPAddress of target server; in uplink this would be 40bits but lets round this up to 64 for the sake of keeping the pattern.
Total size: 112 bits plus packet overhead.
Server->Client:[16bits#1][16bits#2]
[16bits#1]: Code for add link
[16bits#2]: Success/failure code, which tells the client if it can do that or not.
Total Size: 32 bits plus packet overhead.
A total of 144bits, or 18 bytes. After overhead it would still be under 512bits, or 64 bytes.

For an AJAX client, it would take quite a bit more. IIRC, first the client has to make a full HTTP request for a URL that's something along the lines of http://www.uplinkonline.gnu/client/inte ... 99.999.999
only hashed, and wait for the server to generate the page and start sending the browser the relevent information in the form of plaintext XML formatting data.

The difference is orders of magnitude; Half-Life 1 can update the positions of 32 people, weapon firing information, dozens of NPCs, and a slew of other information 60 times a second while only using 2.5KB/s. I figure that AJAX uses that much for a single transaction once or twice a second.

The only reason I could see somebody going with AJAX for this is if they're coding for what they know, or if they REALLY want true cross-platform compatability (Without using something like Java). But I'm in no position to guess at motives or judge people. Regardless of questions of technical details, I hope that this project is successful. I'd certainly spend some time on it. ^^

[Digital-NW]

Very good point you have made. (Wow, what am I?? Yoda? >_<)

There are other forms of communication that we could use rather than XML, which, with all of it's tags, is heavily bloated in size. We can send plain text executable js code and eval based on that (client-side/return) and send plain text data to the server. It would take an extra level of security to do so, but it would definately help optimize the data being transfered to the server. This definatly wouldn't compare to a stand-alone client, but that isn't something I ever expected. There is just too much overhead from silly stuff.

Properly implimented, would could (to some extent) give the same sort of masking I would think.

Anyway, I am no master of AJAX, or JS for that matter. I know a little and have been trying to get up to par with it over the past few months. So a lot of what i am saying is straight from experimental ideas or specualtion based on what I have learned thus far.

If you are up to help out, please sign up! I don't think that you would get turned away

Personally, I would prefer a server/client stand-alone game. I think that it would be more efficient in so many ways. Unfortunatly I lack the associated knowledge in C to try and impliment something like that.

[Krid]

The most cross-platform compatable would be Java, and since Java and C have somewhat similar syntax you would be able to harvest and convert large portions of the Uplink engine with perhaps a bit more ease than starting from scratch (I haven't bought a DevCD yet, so I can't take a look at their coding style to see how hard the transition would be. HEY! IV! PUT THE DEV CD ON STEAM! XD)

The easiest solution would be flash. Flash has tolerable netcode, and a VERY easy to use graphics system. Plus, it renders 3D accelerators optional (On the developer side, anyway. It can render to OpenGL/Direct3D/Software3D exclusive-or it's vector-art system. You can't really code it to toggle between the two inside the game without lots of work setting up the UI in both modes.)

Java is more powerful and more portable, Flash is easier and requires no installation.

Among non-portable setups (in the carry-it-between-platforms-without-recompiling sense), the king is always whatever the software was coded in. Most of the work is already done (The UI is set, the game mechanics are coded, etc...), but portions have to be ripped-out and replace to add a layer of abstraction and other requirements of online play.

While I'd be happy to help, except I'm not exactly all that skilled where it matters. About the only thing I think I could do well would would be helping with design, although while I'm not much of a programmer I might be able to scrape some rust off and get something useful done.
I'd also like to think that I'd do a decent job with design and play mechanics, but I'm not objective.

[nebulos_one]

Thanks to a donation from one of our members, we now have our own on-line forum that is not based on Yahoo! Groups. Interested people should head over to http://www.hacksim.metalaxe.com/forums/index.php?s=2514e3acec073f7c13377c3f292eb616& to join up.

Regards,
Nebulos_one

P.S. This is a temp domain and will change again later when a name for the project is decided.