I'm having a hard time articulating why I think this is so fantastic. It's great to see people attack a not-so-serious problem with such gusto. I love the passion behind taking things apart just to see how things work.
As someone with not a lot of experience in low level languages and I can't wait to play around with this. I think it will be fun way to learn and maybe even try building hardware implementation using a FPGA.
I haven't been thinking about an FPGA myself. Mostly because I don't know verilog/vhdl well enough.
I've been thinking of how hard would it be to take two 32k SRAMs and an AVR and do some fancy bank switching to handle it. I know I could probably manage it by using the onchip support directly but then I'd end up with some memory inaccessible from addressing holes.
It seems like it should be possible to do, and then it would be easy to allow real IO and everything later when that's standardized.
On my list of things to get around too. I don't expect it to be too hard as it's a fairly simple processor as specced. It'll be interesting to see what architecture techniques could be added to improve things while still remaining within spec.
In a way this almost saddens me as by the time the game comes out it looks like the community will have javascript ported to the CPU and no one will actually have to program in assembler as per the original idea... ;)
Don't start worrying about the "purity" and "this was never intended". You don't specify a processor instruction set in the real world without expecting people to write higher level languages for it, so why expect people to write at such a low level in a GAME of all places? I am fairly certain everything is going exactly as planned. Notch has got this.
I second this. If anything, Notch must be feeling immensely satisfied if not somewhat overwhelmed by all the effort that the community has put into his project.
It must definitely be overwhelming. So much hype is building, and he doesn't even have a functional prototype working yet. Greater men have failed to succeed when so much pressure is present.
I love the game idea, and think Notch is a great game designer+developer, and sincerely hope that it will be what we think it will be. But at the same time, I'm not as optimistic as others might be.
Along similar lines, this morning I was thinking how wonderful it would be if whatever interfaces exist between the ship's computer and the rest of the 0x10c game world are rich enough to make security vulnerabilities in players' DCPU-16 code a real concern. Imagine disabling an opponent's ship by exploiting a buffer overflow in a custom communications protocol implementation, for instance...
This. Also, if it gets one kid interested in asm/ low-level stuff, it's worth it IMO.
We keep abstracting, but we can gain so much by going back to the hardware. Also, exploiting in general is fascinating to me, and I hope this pushes it more mainstream.
Yeah this seems like the exact scenario where hand-rolled assembly and perhaps some hand-optimized C will really shine. You don't see a lot of embedded processors running javascript, for example. If your ship can process data and respond 5% faster than an opponent's, all other things being equal, you will come out ahead.
If the current level of interest persists, by the time the game launches, I imagine that the vast majority of people will be downloading and running programs written by others. These will have been pored over and optimized to an extent that most of us would be unable to achieve by ourselves, and it will not pay to roll your own trivial implementation. I'd be curious to see what Notch can do to still encourage people to learn how the CPU works themselves. If the environment and game dynamics are rich enough, perhaps this will not really be a problem?
I think we're going to see some clever optimizing DSLs (a la FFTW) -- restricted languages for the kinds of embedded programs you write on such an architecture will be easier to optimize than general purpose languages. Particularly if they have a clear cost model.
The Haskell embedding is very likely to head in that direction.
The polymer article was very interesting, really cool stuff. However, I could not find any mention of using a constraint solver for instruction level timings. Is that in another article, or did I just miss it?
> I'd be curious to see what Notch can do to still encourage people to learn how the CPU works themselves.
Have some ship customisation stuff tied to assembly programming. People love changing the colour of carpets or wearing hats or collecting and displaying fossils.
Then allow the community to create simple how to guides - "This program will do $THIS_THING; here's how it works; now try to change it to do something slightly different."
I guess Codecademy should have a DCPU section too.
Agreed that higher-level langs would be helpful for "newbies". I wonder if this was at all inspire by Schemaerse (google it, but TL;DR it's a space game written mostly with Postgres triggers where /you build the game client/ in whatever you want to use to interface with the pgsql :)
Yep, only thing I dislike is that the processor does not simulate the importance of cache. If the in-game processors allowed the selection of different cache-line sizes (both instruction cache and data cache) for different costs (paid via the in-game currency), it would add another level of depth to the game market. It would also mean getting into the nitty-gritty of optimization would be even more worth it.
For those old grey-hairs around and reading that remember RSX-11M/M+, there was a tool known as TKB.
The task builder.
TKB allowed (much) larger applications to run in the address space of a 16-bit DEC PDP-11, using what were called overlays, and overlay trees.
With overlays, the application call tree within an application was analyzed and implemented to allow various sections of code within a tree of subroutine calls to be paged out to backing storage.
If the underlying "processor" is fast enough and if you have enough swap space available, then you can stuff a whole lot of code into a 16-bit address space. Just not all loaded in physical memory at once.
He who has the best systems will win, no matter the tools or platform. I love it.
I think it is great for teaching kids to program as well, or be excited about it. Notch is going to do what thousands of teachers can't do because he is using the power of gameplay to drive it.
I want to see a networking protocol between ships so that fleets form in order to take advantage of multiple "cores."
So for example, you'd have the difference between a single-celled organism (standalone ship) versus a multi-celled organism (a fleet), with a fleet of ships delegating work to specific ships. So 10 ships run the "scout" programming in a perimeter, 5 act as resource gatherers, and a few others as transports within the protected space. Perhaps some act as brain cells which tell ships when to change roles.
All of this is happening even when no members of the fleet are actually playing.
This just boggles the mind with possibilities and I can't wait to start playing this game.
Furthermore, you have people trying to break into space protected by fleets by attacking networking protocols--in a game!
I had a dream the other night wherein there was a start-up that took custom code requests for 0x10c players on commission. Requests ranged from optimizing the ship's defense to autopilot and hyperspace jump controls.
For some definitions of viable. Perhaps taking the requests, and converting those into mechanical turk tasks would work. That'd allow the price to be low enough to be doable.
There's a market for minecraft servers, so anything's possible.
Due diligence is called for. Has this business model been successful in other games? Do you have some advantage over the throngs who will gladly do it for free / recognition?
While I can't think of a specific example, there are related precedents: consider the advent of the Mann Co. Store in TF2 where players purchase game items with real cash. There is definitely a model to be made off players with disposable income who want to be the top dog.
Your second question is a reservation that I have as well. We have already witnessed a huge influx of people coding up DCPU-16 software for free, but such programs are only related to the software engineering side of the spec rather than the actual gameplay. Obviously we know less about the latter since few details have been released, but in the competitive game I imagine it could be different. For example, to build a really awesome weapons system and then share it with other people seems a bit counter-intuitive. So there may be room yet for a business built on custom, clandestine code for a player's ship.
Gamers are already a demographic with money to spend. This could be seen as a worthwhile investment to some. If you are interested, email me and we can talk there.
I phrased it as a question because I don't know the answer either. I've heard that second life had a thriving economy of user-generated content and that some players "make a living" from the game; I've never seen hard numbers though.
I doubt the returns reach the proportions necessary to support a startup, especially with the low barriers for entry, competition from free alternatives, and piracy. Maybe it could support a single developer, though; more of a "lifestyle business."
Considering that the gold farming business runs revenue in the billions, the moniker of startup could definitely apply to a service catering to MMO gamers.
HN is funny. Last week as each new dcpu emulator implementation popped up, they got fewer and fewer votes and more comments like "oh great, yet another dcpu post. let's call this Dcpu News for crying out loud!" Then github adds syntax highlighting and gets 150+ points. I'm very curious why that is...
The emulators got less votes because it was more of the same exact thing ("someone implemented DCPU-16"). This is news because a big name has taken notice of DCPU-16, going so far as to officially support it. It's a different flavor.
My sentiments exactly, I don't believe that Github adding syntax highlighting of a language is "hacker news". They are supposed to have syntax highlighting for most of the languages. Maybe on HN people are discussing DCPU, but if you look at the comments on Github, they are all "awesome", "+1", really? for adding a syntax highlighting for one more language.
Looking at all the amazing work done regarding the DCPU and the article yesterday on Instagram's technology stack made me realize just how far we've advanced. With the tools that we have available now, it is possible to do things in a few days that it took people years if not decades to achieve.
But the first C compilers were written four decades ago by a couple of people in a matter of months. And they were not just writing the compilers but also designing the language at the same time.
"When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and Zed (the Canadian answers to `what follows B?'). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder."
Well, but those 18 person-years did their part to allow those person-weeks.
That is: I agree, technology got far. But there's a second phenomenon involved: human knowledge. Technology steps happen in generations, often restarting from scratch. Knowledge steps on the other hand most come incremental (well, with some losses here and there). We're standing on the shoulders of giants.
Weird that they didn't include the language link[1] that shows all the repo statistics for the language, like most watched, most forked, newly created, etc.
Notch tweeted the other day that he was thinking about DCPUs coming with some fan-made open source OS... as soon as someone writes one. This should be interesting.
I wonder if Notch is regretting releasing these details so soon. Now he's already going to be a slave to backwards compatibility and the game is about 0.1% complete.
Seeing that everyone is doing this just for fun, I doubt it. He could change everything tomorrow and I bet people would be excited to do it all over again.
I don't think everyone's doing it for fun, I'm sure there are savvy dudes out there that know that there's a lot of money to be had by being a first mover in the Notch ecosystem.
But even those that are doing it for fun -- you might be underestimating the amount of nerd rage that people are capable of when stuff they don't want to have happen happens. Just sayin'.
GitHub uses the open-source Pygments (http://pygments.org/) to highlight source code. If you can find the code for whatever ASM highlighter Pygments uses, you could probably fix it yourself. Though I tried searching for it and didn't find it after a while, so it would take some tracking down.
I'm a beginner programmer with a little of bit of programming experience, and this idea of programming a game through assembly interests me, but I'm not familiar with assembly. How should I go about learning DCPU16?
I'm working on a multicycle implementation that I will be able to push to a FPGA. There's no way I'll be able to get the same cycle timing as the specs indicate however. 3 cycles for a divide is very, very generous for such a simple CPU, I'll probably either end up implementing a shift and subtract algorithm (will take more than 3 cycles), or using huge look up tables (probably too big fit in a single blockRAM as well...) to try and achieve it.
On the other hand, SHR and SHL are trivial to do in hardware via a barrel shifter, but he assigned 2 cycles for them.
The [next word + register] instruction is also a bit annoying to deal with in the given time tables and a simple register file design, though I haven't thought about the design of that too much.
Would it be a good idea to run the instructions as fast as you can, adding some cycle accounting and using it to generate some external interrupt to help implement quotas? Though when it gets IO support you might have to run things entirely in lockstep again.
Thanks, github. You made my day.