Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Take Over The Galaxy with GitHub (DCPU16 support)

github.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Take Over The Galaxy with GitHub (DCPU16 support)

#81

Post by lloeki »

Niten wrote: post #73
secoif wrote: post #8

Earlier quoted context omitted.

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.

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...

That very well may be part of the game: https://twitter.com/#!/notch/statuses/187474819980328962

Re: Take Over The Galaxy with GitHub (DCPU16 support)

#82

Post by mzl »

dons wrote: post #21
flatline wrote: post #5

Earlier quoted context omitted.

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…

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. (See e.g. in this style : http://www.fftw.org/faq/section4.html#whyfast or this style : htt…

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?

Re: Take Over The Galaxy with GitHub (DCPU16 support)

#84

Post by obtu »

tcas wrote: post #55
rasur wrote: post #33

So, who's going to be first with a hardware implementation of the 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 wel…

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.

Re: Take Over The Galaxy with GitHub (DCPU16 support)

#85

Post by dons »

mzl wrote: post #82
dons wrote: post #21

Earlier quoted context omitted.

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. (See e.g. in this style : http://www.fftw.org/faq/section4.html#whyfast or this style : htt…

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?

That's not in the polymer paper, but its what FFTW is doing (and the ICC compiler that we relied on for the monte carlo work).

Re: Take Over The Galaxy with GitHub (DCPU16 support)

#86

Post by seanp2k2 »

Niten wrote: post #73
secoif wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: Take Over The Galaxy with GitHub (DCPU16 support)

#87

Post by seanp2k2 »

DanBC wrote: post #9
flatline wrote: post #5

Earlier quoted context omitted.

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…

> 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…

DID SOMEONE SAY HATS?!

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 :)

Re: Take Over The Galaxy with GitHub (DCPU16 support)

#88

Post by mzl »

dons wrote: post #85
mzl wrote: post #82

Earlier quoted context omitted.

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?

That's not in the polymer paper, but its what FFTW is doing (and the ICC compiler that we relied on for the monte carlo work).

Thanks. I misread the content description as referring to the latter paper only.

Re: Take Over The Galaxy with GitHub (DCPU16 support)

#89

Post by xsmasher »

yolesaber wrote: post #77
xsmasher wrote: post #61

Earlier quoted context omitted.

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,…

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."

Post reply on HN