Now here's an interesting bit:
"Question: can we trade the programs we create? How will you stop malicious viruses etc?"
"yes. And I won't stop viruses, the players will have to do that themselves."
"Question: can we trade the programs we create? How will you stop malicious viruses etc?"
"yes. And I won't stop viruses, the players will have to do that themselves."
I can imagine nothing pissing off a noob more than getting a virus within 10 minutes of play and having no idea how to stop his ship from self destructing.
Perhaps this will need some sort of firewall system built in where ships cannot communicate unless ports have been explicitly opened. Perhaps some sort of communications proxy that can serve for safe communications.
It could have a system similar to EVE where high security systems have infrastructural to mitigate risk whereas low sec systems lack this but contain the best rewards.
It has 64K 16-bit words. What exactly are you expecting the default software to do that opens it up to viruses?
Not to mention the usual social engineering stuff. "Hey install this great program, it'll make your guns 200% more powerful"
Obligatory (but illustrative of my point): http://www.pbm.com/~lindahl/mel.html
Assuming memory mapping is used for displays the (128k of ram (64k of words)) is also needed to hold your display buffer. Assuming a mere 320 x 200 x 8 screen will use 1/2 of your entire virtual memory space. Look for demos of what people do on C64 demos for a better idea. Yes you can run a UNIX, yes you can talk TCP... but its going to chew up a lot of the capacity for that infrastructure. I expect very light weight protocols, TCP/IP is likely too heavy weight.
Plasma Shield Generator requests the following permissions:
* Read/write to the ship's log
* Draw power from the core
* Use the red alert system
* Access communication protocolsYou can't think about this in modern terms. It's not a modern computer. It's a 1980s computer, and it's supposed to run a spaceship. Think microcontrollers, not smartphones or set-top boxes.
A rough static analysis of the code might reveal where those components are accessed, and as long as you enforce permissions while the software runs then you should be able to catch anything that tries to slip past.
[1] I have no idea what the correct terminology is here.
Yes, that's what I said. :)
Bear in mind that this is already only a 16bit CPU with a restricted address space.
I suspect the interpreter could be made to fit, with limited space left for the untrusted (to-be-interpreted) code. As has been pointed out elsewhere, though, if there is a backing store (i.e., simulated hard drive), it's probably possible to have effectively unlimited "RAM" in the game in practice, unless Notch implements a slowdown for accessing the backing store.
In practice that might not matter for many applications if they do not have to use intensive algorithms etc.
I would still imagine that compilers would be used more than interpreters though which would mean that some security would need to be present at the "hardware" or "firmware" level.
Another interesting thing to think about regards backing stores:
I assume that the programs will be able to take input from the world around them, i.e other ships , objects in space etc.
So what's to stop you from using (perhaps) a tractor beam to re-organise the position of asteroids in space and then "read" that data back using ship instrumentation?
Potentially the entire universe becomes one big DB!
Even with finer program access controls, it would still be hard to protect as long as untrusted code was allowed to alter trusted.
Here is an analogy, what you are talking about is secure walls with a lockable door; what you have in this chip is some wood, a saw, some nails and a hammer.
I hope this is the opposite of EVE in practically every way... except the high-level concept. Let's not give Notch any ideas.
Examples would be: The Economy. Ship Configuration System. The Artstyle. The security model. The unforgivingness (made you think carefully before you acted).
The problem was just that the combat always felt a bit bland and favored players with the biggest ISK supply and XP. So in reality you needed to be part of a huge corp and wait for months for skill training to be competitive.
So not everybody needs to actually know how to program, they can just buy stuff from NPCs or from the market off other players. But obviously, the ones who do know the system inside out will have an advantage.
I can imagine how an economy of reputation could arise where some people are trusted to distribute malware-free code.
A road location would be rwxr--r-- while a road texture could be rwxrwxrwx.
Your player's character look could be rwxr--rwx.
A signpost coudl be rwxrwxr--.
Question: Will we need to program an OS? And does it run Linux?
This would be a tremendous way to do that.
Programming on normal computers is always kind of disconnected from the real world. So, your program can add two and two. Great. Now what?
Microcontrollers alleviate that issue to some extent. Now your program can walk and talk, and push real-world objects. But you kind of need to learn a bit of electronics too.
Notch's Universe solves this issue neatly. It's a mock real world, with programmable computers. Now your software can do some interesting mock-real-world stuff, like fly spaceships. That's pretty neat.
This is why most people advocate learning python or ruby. You don't have to deal with the underlying manipulation of the computer until you've decided you actually like programming.
Personally, I think Python is a great way to teach programming, because it allows us to get to concepts quickly. Accidental complexity is at a minimum, and the inherent complexities of programming become the focus. But, even thought that's my personal preference (based on some experience; I've used Java and C++ to teach programmers and had to explain away accidental complexities), I hesitate to say it's best because I have no evidence backing up that claim.
What's important is learning certain concepts, perhaps the most important of which is algorithmic thinking. That is, knowing what result you want, knowing how you start, and being able to reason through how to get from the start condition to your desired result, step-by-step. What helps is when the result you get is something you care about. I can easily see that for some people, getting something to behave a certain way in a videogame will be a more compelling result than others.
An MMIX like ISA would open up the world for compilers much more. With this, it looks like people should be confined to writing simple stuff - which is kinda the point but still rather sad.
And in my mind, "serious about programming" extends beyond building web apps.
Now for practical usage? Sure Assembly is probably a waste of time. I still haven't found a real way to implement that wouldn't be. But the fundamental understanding of how a computer works, how decisions are made so close to the machine enhanced my understanding about programming which in turn enhanced my understanding about how I wanted to develop and engineer, even for the web.
My .02 cents anyway.
And there's a certain concreteness to such a machine. The mental model has no vagueness at all. You could imagine building a physical copy of it and playing the role of CPU--adding small numbers, moving data between registers and memory, etc. I've played with this idea myself before of using an invented 16-bit machine as a teaching device.
Maybe it's just a case of personal differences, but as a starting programmer, I would have been extremely excited about a simple programmable thing that I can fully understand and use to do things within a game world. Python is cool too but it's overwhelming. There are learn-Python books that are thicker than most of my university textbooks.
It will not run Linux, because Linux requires a 32-bit CPU with megabytes of RAM. Someone might write a Linux-like system for it though.
It is unlikely to need any mechanism for managing drivers for example (unless you can build custom hardware). You might need some form of scheduler if you are running different programs to do different stuff (weapons , engines , navigation) but this could be something very simple and again baked into the emulator.
Some form of shell might be nice, but again not necessarily required.
Well, actually that sounds like a recurring theme, now only taken to a more complex extent.