3 ms·

I purchased this book. Might have been about 10 years ago, now. It is a nice book and, from memory, is well written. I do think that there are better books wit

I purchased this book. Might have been about 10 years ago, now. It is a nice book and, from memory, is well written. I do think that there are better books with regards to game programming. I would say this book is good is you are a web developer (or something) and want to brush over ideas on how to build games. What you learn from this book can translate to your day job to solving problems. The reality is many languages, libraries, etc, used in other domains are OOP focused.. so if thats your mindset, this is a good book. However, if you are serious about (wanting) to be a game developer/programmer, would recommend Game Engine Architecture. Real-tim collision detection is another book from memory. (I am out of touch if there are any modern books for game developers. Open to hear about them if any) Another recommendation is to watch Mike Actons 'Data Oriented Design' video on youtube. It is likely 10 years old, now. I still believe it is relevant for modern game dev. Disclaimer: I am not a game developer. I am an app developer. I builds gui apps, web sites, daemons, etc. However.. if I was to build a game, I would be using the C programming language (or maybe Odin)

cnity 3y ago
A note from someone making a game on the side (in C, actually!): beware of over-focusing on "patterns" and books about them. Yes, there are some great ideas (such as ECS and so on), but don't get bogged down in that. Solve the problems your game lays out for you first and see what difficulties arise. Don't "worship the gate" so to speak. I see many game developers who fall into this trap, and then there's the endless debates about "writing your own engine" (which is a bit of a misleading position from the beginning, my personal game has no "engine" that I can see that could clearly be separated from the rest of the game. No this does not mean it is poorly architected). All of this to say, relax about "patterns" already. Write your damn game, it's waiting for you.
- mysterydip 3y ago
  Fellow "making a game on the side in C" here :) One of the best pieces of advice I read was "you have to ask yourself, do I want to make a game, or an engine?" Both are fine choices, but you need to know which and stick to it. And engine in that context refers to all the bits that make the game work, not necessarily that they're in a modular form for others to use. Basically, you can spend your whole time adding cool or clever features but never turning it into an actual game. It's an easy trap to fall into because adding features is a fun distraction from some of the slog of gamedev. Make the features you need, but don't "gold plate" things.
  - cnity 3y ago
    Absolutely. I think a lot of people misinterpret this advice like this (or actually the advice is intended this way): if you don't use an off the shelf engine you are destined to slogging away writing your own engine. When in fact it's perfectly reasonable to ship a game without using any off the shelf tooling, or worrying too much about "patterns". Follow up advice (from someone who isn't really qualified to give it): stop listening to people who say "do this, don't do that, you can't do this, it must be done like this" etc. You know yourself what you're curious about and interested in and what you want to build. This includes this advice, maybe reading about patterns will help you. Let your inner voice guide you.
  - masfoobar 3y ago
    > make a game, or an engine There is another saying I read somewhere. It was something like: - many people who write games never finish them This hits home, especially in my younger days. If you are making a game.. focus on that game! Your next game might require you starting from scratch. I get why people try to make a nice engine (ie and using ECS) because the goal is to reuse it many games. I am sure the (silent) majortiy making an engine for their game... just keep working on their engine. It never leaves thier bedroom.
- masfoobar 3y ago
  > All of this to say, relax about "patterns" already 10000% agree. In all honesty, I use the word "patterns" loosely, but the word is so loaded today (ie design patterns) with ECS included. Yes - I am writing a game for my kids, also in C. The game comes first. If (things like) ECS makes sense, I will use it.
spacechild1 3y ago
> would recommend Game Engine Architecture It's an amazing book! But it's also a whopping 1000 pages :)

cnity 3y ago

A note from someone making a game on the side (in C, actually!): beware of over-focusing on "patterns" and books about them. Yes, there are some great ideas (such as ECS and so on), but don't get bogged down in that. Solve the problems your game lays out for you first and see what difficulties arise. Don't "worship the gate" so to speak. I see many game developers who fall into this trap, and then there's the endless debates about "writing your own engine" (which is a bit of a misleading position from the beginning, my personal game has no "engine" that I can see that could clearly be separated from the rest of the game. No this does not mean it is poorly architected). All of this to say, relax about "patterns" already. Write your damn game, it's waiting for you.

mysterydip 3y ago
Fellow "making a game on the side in C" here :) One of the best pieces of advice I read was "you have to ask yourself, do I want to make a game, or an engine?" Both are fine choices, but you need to know which and stick to it. And engine in that context refers to all the bits that make the game work, not necessarily that they're in a modular form for others to use. Basically, you can spend your whole time adding cool or clever features but never turning it into an actual game. It's an easy trap to fall into because adding features is a fun distraction from some of the slog of gamedev. Make the features you need, but don't "gold plate" things.
- cnity 3y ago
  Absolutely. I think a lot of people misinterpret this advice like this (or actually the advice is intended this way): if you don't use an off the shelf engine you are destined to slogging away writing your own engine. When in fact it's perfectly reasonable to ship a game without using any off the shelf tooling, or worrying too much about "patterns". Follow up advice (from someone who isn't really qualified to give it): stop listening to people who say "do this, don't do that, you can't do this, it must be done like this" etc. You know yourself what you're curious about and interested in and what you want to build. This includes this advice, maybe reading about patterns will help you. Let your inner voice guide you.
- masfoobar 3y ago
  > make a game, or an engine There is another saying I read somewhere. It was something like: - many people who write games never finish them This hits home, especially in my younger days. If you are making a game.. focus on that game! Your next game might require you starting from scratch. I get why people try to make a nice engine (ie and using ECS) because the goal is to reuse it many games. I am sure the (silent) majortiy making an engine for their game... just keep working on their engine. It never leaves thier bedroom.
masfoobar 3y ago
> All of this to say, relax about "patterns" already 10000% agree. In all honesty, I use the word "patterns" loosely, but the word is so loaded today (ie design patterns) with ECS included. Yes - I am writing a game for my kids, also in C. The game comes first. If (things like) ECS makes sense, I will use it.

spacechild1 3y ago

> would recommend Game Engine Architecture It's an amazing book! But it's also a whopping 1000 pages :)