“Game Programming Patterns” is now finished
gameprogrammingpatterns.com
gameprogrammingpatterns.com
He had some interesting comments on his writing process in a previous thread entitled, "Write Code Every Day." [1]
He also graciously answered some questions I had regarding his writing workflow, as well as his plans to self-publish a print version of the book. [2]
Thanks!
> He also graciously answered some questions I had regarding his writing workflow
I've got a long blog post about the whole writing process I'll put up soon.
"The first 90% of the work takes 90% of the time. The last 10% of the work takes the other 90% of the time.
http://en.wikipedia.org/wiki/Pareto_principle
I've found it to apply to many things in life.
Edit: why would this be downvoted?
There have been several times where I've accidentally upvoted low-quality (sometimes malicious) posts, and I never feel good about it.
-- Yogi Berra
Mental: 64.29%
Physical: 35.71%I teach coding to high-school kids. When I tell them that "We'll be building a game" attention increases exponentially; unfortunately I know nothing about how to program anything beyond simple board games, e.g. tictactoe. I can totally use ideas from your book in my course.
Also, many of the students are also in the school's FIRST Robotics Team. I noticed that programming the robot and game programming are quite a similar (at a high level). So this might help with that, too.
Thanks a lot once again, I entered my email and will definitely be following along.
Congrats. Any idea when I'll be able to buy it?
Like the other free-online-first books I've read, I've gotten enough value from it that I'd like to thank you by paying for it.
The author is the submitter of the post and is replying to comments. He addressed the same question there too.
As soon as possible!
Unfortunately, I don't know how long that will be. I'm going to be typesetting it myself with lots of love using InDesign. I hope the final result will be a really nice book, but it could take me a while.
Still, I plan to work on it every single day, so maybe it will go quickly.
> I've gotten enough value from it that I'd like to thank you by paying for it.
Just a thanks is more than enough, but buying a copy of the print book will be the best way to throw money at me (short of showing up at my house and making it rain, I suppose).
YMMV - but you dont have a lot to lose. You could be surprised by the time you save.
Have you perhaps considered LaTeX/XeTeX? Would get you incredibly beautiful typeset foundations, then you can customise it a lot further.
I'm still trying to figure out the optimal way to organize every part of a Dwarf Fortress-style simulation (but multi-threaded of course), and I feel like I'm reinventing the wheel somewhat poorly. Component-based design is an important part of that, but there are still so many hairy problems to solve.
These are problems which most games don't encounter because they're not complex simulations. And the agent-based simulation literature isn't much of a help either.
The same underlying simulation could conceivably be used for a peaceful economic sim, or a highly strategic military game, or just an RPG with a ton of depth.
Don't really understand how you would stop players just slaying all your NPC's? Which I think isn't a problem in the whole if it was offline single player but after playing many online games I just can't see it actually working online.
Also recreating DF with a lot less detail in real time across multiple servers seems like a insane technical challenge good luck!
One place this is likely to break down is the transform (position) component, but one strategy for that is to differentiate between read-only and write access. Lots of systems need to know where things are (const access) but few need to change where things are (write access). All the systems that can deal with const access can still run in parallel.
The trick here is you have to strictly enforce all this. You CAN'T have a method for getting an arbitrary component from an entity, and this may drive you nuts. Instead you have to have each system specify ahead of time exactly what components it needs and how it uses them, and then hand them those components, and only those components. As soon as you let someone write "entity->GetComponent(Physics)" in leaf code, you've lost your ability to analyse the dependency tree.
For a lot of games, the other problem you're going to run into is that one or two systems are going to take up most of your time and every other system is just going to sit around waiting for those anyway. Usually those are physics and rendering. Which you might be happily avoiding by making a dwarf fortress style game!
I have a coworker who's got a "toy" engine at home that does all this and some other fairly amazing tricks. He says he's going to open source it, still waiting on that. Sorry for this pointless tease, just wishing he'd hurry up out loud.
It's really hard to get the motivation to finish such a project, serious kudos to you; I shall be buying that e-book!
Most of the time I work with game engines, which already use the patterns mentioned here. I struggle with stuff like moving entities in specific directions, collision detection, physics, gravity, etc.
There are sadly few serif fonts on Google Web Fonts that have consistent letterforms, good metrics, a nice middle-of-the-road x-height, and good bold and italics, but Merriweather is quite nice.
Does anyone have a script to package this into an ebook format? I'd love to be able to read it on my Kindle.
Super excited to see that his writing strategy worked and it is released. Nice work Bob.
Thanks!
Looking forward to ponder on it.