[h3]http://gameprogrammingpatterns.com/[/h3]
I’ve known about this site for a while, and it (and the guy’s book) is complete!
Lots of great info here in an easy to understand format, all the way from game loops to homebrew VMs for scripting, and all in a gamedev-relevant context. Brilliant!
God this is useful, I’m just glad there is finally some kind of book about game programming architecture.
Thanks!
For the sake of cute fluffy bunnies, don’t write your own VM and skip this chapter entirely:
http://gameprogrammingpatterns.com/bytecode.html
This is the only chapter I read (well, skimmed), so my impression is that it’s a push in entirely the wrong direction for 99.99% (maybe 99.999%) of the target audience.
I hope I missed some sentence in there that explained how this is only an explaination of the concept of a VM, and one should never ever do this, while writing a game, or game engine - even AAA engines are dropping their support for scripting languages, forcing the mods to be programmed in plain C.
Anyway, the more I read of that chapter, the more it seems he’s seriously suggesting others to make their own language (parser, compiler, interpreter). :clue: Most people would fail when parsing the code, let alone handling operator precedence correctly, and those are the basics. (Classic example of having lost touch with the target audience, expecting them to be experts like you?)
making a simple scripting mechanism which can be edited in a level editor to control events for each individual level seems like a good idea to me… i didnt read that article though so ill assume its not talking about something so simple
Even a minimal (not even remotely close to full fledged) scripting language is a huge undertaking, and once you’re doing it, you will keep adding features.
If you want to write a game, write a game! Don’t create an environment with custom tools. True experts have done it before you, did it better than you will ever do it, and open sourced it. Use it, and finish that game, make it entertaining for the player, not technically impressive.
If this was GameEngineProgrammingPatterns.com I’d be the greatest fan (kinda), but this is just plain bad advice.
His main reason for rolling his own language is working around C compile times, which can take a few minutes per… tweak. In Java we don’t have that issue, and we can even hotswap code. Regardless of his motivations, he should have used (and advised) an existing scripting language. We have enough indies that never get to publish a game.
Yeah, I only really included that particular in the OP to, uh, pique interest? It is, as you say, almost never a good idea and I’d say is pushing the envelope of a “design pattern.”
I had a good time writing a CPU emulation (more of a instruction set simulator I guess) and it’s assembler inspired at first by that article, but only as a pet project. I wouldn’t ship in a game or anything else for that matter, it’s not mature at all. And that’s good.
If you need some kind of scripting, write an API for mods to interface with, or use Nashorn or something. A VM (and it’s language, it’s implementation of that language, the list goes on…) is an enormous time sink if you want to even begin to have anything more than a really hard to use assembly language. And you most likely won’t get a lot of it right, like security, which was one of the main points in this context.
I think it’s a great little curiosity project, but that’s it.
Edit:
I’d listen to Deutsch:
“Every now and then I feel a temptation to design a programming language but then I just lie down until it goes away.”
A design pattern book like this is best read like a normal cook book. You don´t compulsively cook every single dish in the book, and you should most definitely not use each and every pattern in the book. Some may be useful, some may be very bad for you in your situation.
So although this website is an awesome resource, it is kind of lacking in some essentials of design pattern descriptions: in what situations is this pattern a good idea, and in what situations is it a bad idea?
I don’t really see the point of writing my own virtual machine when I’m already bundling the awesomest of all virtual machines with my game…
I read it this morning. There is more than just the byte code that is not good. But there is good stuff in there as well. And the GoF patterns are better explained with perhaps more relevant examples.
What i would recommend: Design Patterns Revisited, the whole section. The is really a good intro for programmers looks to get started with design patterns.
What you should read with a grain of sand: The Rest with exceptions below.
What you should ignore: Bytecode, Spatial Partition (that’s not a design pattern), Object pool (we are not using C++).
There is probably more to ignore really. And you should always consider the criticisms of the GoF book and design patterns as well.
I found the Type Object and Subclass Sandbox chapters to be interesting and useful. I thought the Decoupling Patterns section interesting as well even though I am not directly applying them to my game.
Thing about Subclass sandbox, is that its just a plain old class hierarchy. Its not really a pattern per say. At least in a usefully defined way.
Anyone that’s been around here for awhile should know I’m a “patterns concerned harmful” kinda guy. Why on earth do pattern-heads have to take existing techniques (usually reducing them down to a special case) and tag the word pattern at the end without bring anything new to the table? Why I ask?
I skimmed all the pages in “Design Patterns Revisited” and I have to admit that’s I don’t have many complaints. Looks like it’s reasonably accessible to the target audience and isn’t dogmatic.
He actually talked about that in the introduction. IIRC, the GoF talked about it as well. Patterns are intended to establish a common vocabulary for people to discuss software architecture. Instead of giving a long winded description of how someone might implement something, you can just advise them to “use a flyweight implementation.” I makes it much easier to hash out ideas, describe projects you’ve worked on, and so on. In practice, many have come to view them as cookie-cutter recipes, but that was never the intent at all.
Indeed. Like “Gotos considered harmful” and “premature optimization is the root of all evil”…people don’t understand what the authors were talking about. The concepts has been extrapolated well beyond their original intent.