Re:The Future of Games is an Instant Flash to the past
by bitwize on Saturday June 26, 2021 @02:00PM
(#27644236)
> Gamedev has got to be the most rewarding type of software coding there is.
It is... under certain circumstances. At a AAA studio it's an utter slog, unless you're the designer or one of the top coders working closely with the designer. Then you get to build prototypes, bounce ideas around, etc. until you come up with something you can hand down to the C++ slaves in the salt mines.
If you don't want to be in the salt mines yourself, the best route to take is the indie route. Become the designer/lead programmer, write the game on your own schedule, and either do your own art/sounds/music or hire people to make those assets for you as necessary and use placeholders while you refine the game design. You also get your choice of language. Want to write a game in Lisp or Haskell? Go nuts!
Do yourself a favor and start with a data-oriented model for your game world like ECS, instead of an inheritance-based object-oriented model. Your inheritance tree is going to whack you like a Whomping Willow the minute you try to build a game object with traits from different classes across the tree. With a data-oriented approach, your game objects are just pieces of state -- rows in a spreadsheet -- and you can change them with whatever tools are most handy: objects, plain functions, whatever. Choosing an ECS has saved me much hassle in adding new enemies and behaviors to the game I'm working on, and that shortens the time and effort from "I need to add this thing" to "WOW! It works!"
Oh, and START SMALL. The easiest way to get from zero to finished game is to limit the scope of your game! Kenta Cho, the guy behind rRootage and all those bullet hell shooters, put up a bunch of tiny web games on his site, each of which uses tiny bitmaps or canvas graphics primitives, so has little in the way of assets: https://abagames.github.io/games-web-pages/browser.html
> But surely building “yet another react form” feels like coding an already solved problem.
Building "yet another React form" should take minutes to hours. If it doesn't at your shop, consider the processes you have in place. Processes like Scrum are there to ensure transparency to management throughout the SDLC and to act as dampers to prevent programmers from becoming too efficient -- not to make the programmers better at their jobs!
> You’re not approaching the creation with the usual “what problem am I trying to solve” but rather “what’s the most fun thing I can build?”.
That can quickly degenerate into "what problem am I trying to solve" when you are trying to work out why collision detection isn't working or why enemies do random things they shouldn't be doing, etc.
It is... under certain circumstances. At a AAA studio it's an utter slog, unless you're the designer or one of the top coders working closely with the designer. Then you get to build prototypes, bounce ideas around, etc. until you come up with something you can hand down to the C++ slaves in the salt mines.
If you don't want to be in the salt mines yourself, the best route to take is the indie route. Become the designer/lead programmer, write the game on your own schedule, and either do your own art/sounds/music or hire people to make those assets for you as necessary and use placeholders while you refine the game design. You also get your choice of language. Want to write a game in Lisp or Haskell? Go nuts!
Do yourself a favor and start with a data-oriented model for your game world like ECS, instead of an inheritance-based object-oriented model. Your inheritance tree is going to whack you like a Whomping Willow the minute you try to build a game object with traits from different classes across the tree. With a data-oriented approach, your game objects are just pieces of state -- rows in a spreadsheet -- and you can change them with whatever tools are most handy: objects, plain functions, whatever. Choosing an ECS has saved me much hassle in adding new enemies and behaviors to the game I'm working on, and that shortens the time and effort from "I need to add this thing" to "WOW! It works!"
Oh, and START SMALL. The easiest way to get from zero to finished game is to limit the scope of your game! Kenta Cho, the guy behind rRootage and all those bullet hell shooters, put up a bunch of tiny web games on his site, each of which uses tiny bitmaps or canvas graphics primitives, so has little in the way of assets: https://abagames.github.io/games-web-pages/browser.html
> But surely building “yet another react form” feels like coding an already solved problem.
Building "yet another React form" should take minutes to hours. If it doesn't at your shop, consider the processes you have in place. Processes like Scrum are there to ensure transparency to management throughout the SDLC and to act as dampers to prevent programmers from becoming too efficient -- not to make the programmers better at their jobs!
> You’re not approaching the creation with the usual “what problem am I trying to solve” but rather “what’s the most fun thing I can build?”.
That can quickly degenerate into "what problem am I trying to solve" when you are trying to work out why collision detection isn't working or why enemies do random things they shouldn't be doing, etc.