Page 1 of 2

Yet another doomed-to-fail attempt at an online uplink

Posted: Wed Nov 26, 2008 1:26 am
by Qwertyuiopas
So I recently found the demo and downloadable bonus CD.

I liked the idea fo an oline version and have had a small bit of C experience.

Although I know it is doomed from the start, I started thinking about the possibility and this is what I have:

34 fake assembly language instructions that would become the low level language
A flowchart like thing for the high level language
The idea that most of the in-game functionality will be implemented in those languages, for authenticity.

The reason that this topic is here, is that if I ever do write a line of code for it, I would like to have a professional opinion for the listings of low level language commands.

code <parameters> :description
NOP :does nothing
INC <dest>:increments the destination value by one
DEC <dest>:decrements the destination value by one
ADD <dest> <val> :stores <dest>+<val> in <dest>
SUB <dest> <val> :stores <dest>-<val> in <dest>
SET <dest> <val> :stores <val> in <dest>
IPT <src> :Sets input source to <src>
OPT <dest> :sets output destination to <dest>
JEZ <src> <dest> :jumps to <dest> if <src> is 0
JNZ <src> <dest> :jumps to <dest> if <src> is not 0
JLT <src> <val> <dest> :jumps to <dest> if <src> < <val>
JLE <src> <val> <dest> :jumps to <dest> if <src> < or = <val>
JGT <src> <val> <dest> :jumps to <dest> if <src> > <val>
JGE <src> <val> <dest> :jumps to <dest> if <src> > or = <val>
JEQ <src> <val> <dest> :jumps to <dest> if <src> = <val>
JNE <src> <val> <dest> :jumps to <dest> if <src> not = <val>
JMP <dest> :jumps to <dest>
AND <dest> <val> :stores the result of a logical AND of <dest> and <val> in <dest>
LOR <dest> <val> :stores the result of a logical OR of <dest> and <val> in <dest>
XOR <dest> <val> :stores the result of a logical XOR of <dest> and <val> in <dest>
NOT <dest> <val> :stores the result of a logical NOT of <dest> and <val> in <dest>
GET <dest> :stores the next input in <dest>
PUT <src> :outputs <src>
PSH <src> :pushes <src> to the stack
POP <dest> :pops stack to <dest>
SUB <dest> :jump to <dest> and pushes the current address
RET <stuff> <varies with stuff> :if set as a sub ret(in <stuff>) pops value and jumps to it, otherwise returns from the program
MUL <dest> <val> :stores the result of <dest> * <val> in <dest>
DIV <dest> <val> :stores the result of <dest> / <val> in <dest>
MOD <dest> <val> :stores the result of <dest> mod(or %) <val> in <dest>
NRT <dest> <val> :stores the result of <val>√<dest> in <dest>
SIN <dest> :stores the sine of <dest> in <dest>, cosine, secant, and cosecant can be simulated with this
TAN <dest> :stores the tangent of <dest> in <dest>, cotangent can be simulated with this
CPY <src> <dest> <size>:copies <size> bytes from <src> to <dest>. good for buffer copies.

all arguments(except <stuff> and <varies with stuff>) are 4 bytes, the first for flags, the other 3 as a pointer or number.
the first 2 bits of the first byte signify the typr of number:
0: a number
1: a pointer(the value at <number>)
2: a double pointer(the value pointed to by the value at <number>)
3: a system variable, most read-only. This includes display and audio buffers, and the actual descriptions of input and output.

the other 6 bits are the size of the final target value, in bytes(pointers are always considered to be 4)

Input and output is specified in detail in read-only sysvars, but it set to with IPT and OPT with an argument to the target sysvar location(crafty hackers can use a portion of the graphics display as a wwriteable input/output description.

IP addresses will be 5 bytes, with the final one split into 2 bits added to the front of each of the rest, to give the full 0-999 per . values(0-1023 with said clever hacking)

Memeory(RAM and otherwise) will be stored in 1024 byte structs, 1000 of them will be data, 24 bytes of header. In RAM, the structs will be merged seamlessly, but files will be read in full 1024 byte structs.

Quad: 1000 bytes
SuperQuad: 32 Quads(the standard indevisible-without-a-defragger size)
GigaQuad: 32 SQ(the standard starting memory)
OmniQuad: 256 GQ(that would be 256 megabytes of real life space used each, except that it is allocated as needed)

IP addreses will be encoded verions of their real-life(IPv4) versions with an extra byte tacked on.

Okay, there, I think that is all.

I would be very happy for any feedback at all.
Unless it is a delete and ban for some stupid reason(such as your IP doesn't come from antarctica, so get lost)

It just might work.

Posted: Mon Dec 22, 2008 8:52 pm
by D1Hazel
You planned out a programming language, so you don't have to do that. A few things to note, though:

    1. Remember, write all the programs in your fake ASM language, but unless you plan on making multiple OSs for the game, write it in C++ instead of your programming language. Speaking of which...

    2. Write it in C++. C++ is capable of using object-oriented programing. This is important because you should...

    3. Never start programming something in a way that's inefficient. You will NEVER, I repeat, NEVER fix it. Trust me on this.

    4. Oh, and assemble some kind of team. Testing net code with only yourself is absolutely terrible, let me tell you.

    5. Make a Linux version or people will get really mad. Even if they are not going to play, they will be really mad. @_@

    6. Put in a translation file. Even if you only have US or UK English in it, you might one day need it.

    7. And finally, put in AI people that aren't hackers but run businesses and are just there. Give the players some people to frame, screw up, and possibly kill.

By the way, I'd help if I knew a bit of C/C++. When I do learn C++, I hope you let me join. :D Best of luck.

Re: It just might work.

Posted: Tue Dec 23, 2008 8:59 am
by KingAl
D1Hazel wrote:Make a Linux version or people will get really mad. Even if they are not going to play, they will be really mad. @_@

Appeasement yesssssssssssssssss. Worked out well in the 30s.

Re: It just might work.

Posted: Tue Dec 23, 2008 1:02 pm
by Ebola
KingAl wrote:
D1Hazel wrote:Make a Linux version or people will get really mad. Even if they are not going to play, they will be really mad. @_@

Appeasement yesssssssssssssssss. Worked out well in the 30s.


Also people only get mad if IV don't make linux versions of stuff.

Posted: Tue Dec 30, 2008 1:34 am
by D1Hazel
What do you mean? When I was illusioned, I tried to make an Uplink online, and people got made because it didn't work on Linux. Even though it did!

Posted: Sun Feb 01, 2009 1:03 pm
by Shandolum
Me and my friend are also trying to make an online hacking game, though it requires a lot of thought for a balanced online gameplay, which is why we are still just writing down ideas.

Posted: Sat Feb 21, 2009 2:11 pm
by exosyphen
Shandolum wrote:Me and my friend are also trying to make an online hacking game, though it requires a lot of thought for a balanced online gameplay, which is why we are still just writing down ideas.

Making hacker games is not easy .... hence the lack of them :)

Posted: Sat Feb 21, 2009 11:08 pm
by Shandolum
exosyphen wrote:Making hacker games is not easy .... hence the lack of them :)

I know, there are many aspects to take into consideration, especially how to make it into a good gameplay, which is why I am thinking a game more like Uplink, than Hacker Evolution where you need to type everything. Though a new interface can always be made, new programs for new OS and the likes, which would make it more exciting to play the game.
But probably the most difficult thing is making a game that is dedicated to a multiplayer experience, since hacking normally doesn't take any time deleting a persons files and programs, and leaving them with nothing. But there are really many things that can be done to go around that problem too, like having backup servers, though they might also be hacked.
Then there are all the limitations like processing powers and bandwith that needs to be regulated on each machine.
The only thing we have begun on is making an sql database to hold account information and program information, that will eventually be used with the server.

So our basic though is a game taking a lot from Slave/Hack, Uplink, and eventually Hacker Evolution. With as much group/faction options as possible.

Posted: Sun Feb 22, 2009 10:35 am
by exosyphen
Sounds pretty cool :)

Posted: Mon Feb 23, 2009 9:47 pm
by Shandolum
The 1 thing that will probably be missing in the first place in the game we are making, is a good UI, since neither of us are animators or graphics artists. But the main concept behind the game is well under way.
But this might still be yet another doomed project like so many others. If I have nothing to say about it in a month, then it probably is.

Posted: Tue Mar 10, 2009 11:19 pm
by Qwertyuiopas
Well, it's not dead, just "dead".
At the current rate, it may be done in a couple thousand years, but it WILL be done.

I have it parsing to bytecode from a file.
It has 9 instructions so far.

The following program:
ADD 0 10000
SUB 0 1
JNZ 1 0

takes 31 clock()(the windows version, 1/1000 of a second) ticks, even with debug file I/O.(generates a 302 kb file in the process)

I think that the hard part will be network and GUI stuff, but I think I could do the GUI stuff easily enough. It would just dump a pixel array into a texture for each "window" and the game itself would handle their location.
All drawing would be done directly to the pixel array, and it would update itself to the texture, only if it has changed, probably 20 times a second.

The command definitions:

#define INST_NOP 0x00
#define INST_ADD 0x01
#define INST_SUB 0x02
#define INST_SET 0x03
#define INST_DBG 0x04
#define INST_DIV 0x05
#define INST_MUL 0x06
#define INST_JMP 0x07
#define INST_JNZ 0x08
#define INST_JZ 0x09

You probably won't hear from me again for a long time(from minutes to months) but it may be done in less than a century.

Still, it's just an interpreted bytecode language based off of simplified ASM until I get around to a GUI.
And, in my opinion, it will be the networking code that is the hard part, although I won't worry about it until much later.

Posted: Wed Mar 11, 2009 1:17 pm
by exosyphen
You have to consider how many people will be able to play the game.
ASM is not something easy ... even for programmers.

Posted: Thu Mar 12, 2009 12:50 am
by Qwertyuiopas
I intend it to be a subgame, where you usually use the standard tools or pay another player for a custom app.
If only one in 100 players can make their own programs to any decent extent, it will still be a good system.

The goal is that none of the programs are hardcoded, so a virus is entirely possible and you CAN make a bot to play the game, at least to a lower extent.

You could make your own routing server to prevent total traces, but then it might be marked as such and added to a potential blacklist. I am unsure if I should leave such functionality for players or add it as a default feature, maybe available with some "unauthorized" tinkering, maybe by leaving the blacklist repository a blank IP that can be filled in later.

Additionally, a compiler is entirely possible, and again, encouraged, but SOMEONE must make the first one and sell it. The whole point of running the game through this language is so that players can improvise realistically.

Of course, after seeing that it is very fast on it's own, I have decided that the game will run at a rate of either 20 or 50 ms/frame, and in that time only a limited number of instructions will be processed, according to the "hardware" you have. There will be standard high speed graphics options such as writing text or lines/polygons so that a GUI is desireable, and a progress bar is worth the "CPU cycles" lost to updating it.

Data transferes will be precached to a limited extent, so the actual information goes out in chunks every second or two but the programs must read or write it in bytes or other small units.

Audio will also be handled externally, although require periodic resources(10 cycles/frame/audio? out of a default 500 or so at the lowest processor levels?)

Unless an intermediate node requests it, data transfer will be direct, and the connection bouncing will only be simulated(game must get accepted by each, but they don't have to transfer data unless requesting it) allowing such things as recording suspicious activity or denial of unauthorized IPs, although there should be ways to circumvent such denial, at the very least faking the IP of the sender if you are willing to take a risk and connect directly.

I have been tinkering with GUI stuff, and have a simple window system. You can drag them around by bar at the top, and clicking on one will bring it to the front of the rest. It also has the test feature of right click and drag to create a new window.
Needs a bit of work, but with the most basic bits in place, it should work out well enough eventually.

Bonus content:
Early window image.

Really needs borders though :)

Posted: Tue Apr 07, 2009 8:53 pm
by Aetern
Qwerty; I know a guy who can do music for your game...he is great. Here is a link to a song he made thank I think has an Uplink Feel to it... PM me if interested

or MSN :
Yahoo :
aim: DLT4006x2000v1

Posted: Fri Jul 17, 2009 10:44 am
by OScoder
I would like to have a professional opinion for the listings of low level language commands

I wouldn't call myself proffesional, but there's a couple of things:
1) You have *two* commands named sub!!! Name the second one 'call' instead
2) It seems pretty functional, but one way of doing things that might be easier to work with, is to use interrupts - so the user can call the uplink 'operating system' and perform calls to do things, like connect to an ip address, or fill in an input. This'd probably make things simpler for you *and* the programmer.

Hope this helps,