Live data from Hacker News

Game Programming Patterns – Bytecode

gameprogrammingpatterns.com

61–70 of 73 posts

Re: Game Programming Patterns – Bytecode

#61

http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp"

Are there any good real-world examples for this?

It's a similar observation to the Inner Platform Effect http://en.wikipedia.org/wiki/Inner-platform_effect

Any project that runs some sort of external script would count. Soon a config file has some sort of conditional (#define grows #ifdef) and variables.

Also any project that has a VM (in the traditional sense) such as SCUMM.

It incorporates the notion that Lisp will do everything already, the code as data as code that Lisp gives you is a win that coders dismiss until it's too late and they have spent years learning C++

Re: Game Programming Patterns – Bytecode

#63

http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp"

But at least, unlike CommonLisp, chances are it is actually used by someone.

Re: Game Programming Patterns – Bytecode

#64

Seems like he is reaching for an Entity-component-system - https://en.wikipedia.org/wiki/Entity_component_system

I wrote a chapter on that too! http://gameprogrammingpatterns.com/component.html

It seems this and subj patterns could be books themselves.

Re: Game Programming Patterns – Bytecode

#65
post #51
post #6

In summary: Why create a game when you can design and implement a new programming language?

Corollary: Why create a game when you can implement cool new engine tech?

I guess this is why we have 100 HTML5 game engines and 0 HTML5 smash-hit games.

Re: Game Programming Patterns – Bytecode

#67

Seems like he is reaching for an Entity-component-system - https://en.wikipedia.org/wiki/Entity_component_system

I wrote a chapter on that too! http://gameprogrammingpatterns.com/component.html

You might want to look at how people are approaching components now. Instead of components containing logic, components only contain data.

You then have systems that operate on the components. This solves the problem of needing components to interact with each other, since a system can look at as many components as it wants.

https://en.wikipedia.org/wiki/Entity_component_system http://t-machine.org/index.php/2007/11/11/entity-systems-are... http://piemaster.net/2011/07/entity-component-artemis/

Re: Game Programming Patterns – Bytecode

#69
post #60
post #41

I think a lot of people misunderstand what is being proposed here. He's not saying to write a whole new language, he's saying to write a byte code interpreter. You can implement one of those in about an hour.

Ah yes, I'm sure designers will just love to write their scripts in raw bytecode. This section is somewhat important: http://gameprogrammingpatterns.com/bytecode.html#how-is-the-... While you're at it, you'll probably want to write some debugging tools since your designers are bound to dream up some complicated scripts you never imagined your system needing to handle...

They will write them in FORTH and they will like it!
Post reply on HN