4 ms·

Thank you for sharing this! > Don't build an engine instead of a game Only too true... That's a trap I always fall into. I guess programmers are so hard-wired

by veddox 10y ago

Thank you for sharing this! > Don't build an engine instead of a game Only too true... That's a trap I always fall into. I guess programmers are so hard-wired to abstracting problems they that need solving they end up doing a lot of abstracting and very little solving. (Compulsory xkcd: https://www.xkcd.com/974/ https://www.xkcd.com/974/)

ewjordan 10y ago
This is one of the reasons Unity has become so popular in the industry - from a project management point of view, it makes sure that programmers don't start yak-shaving and building tech that's already been built a thousand times by other people. It certainly has its warts, esp when going into full production, but at least in early development it's really good at making sure you're only building what's unique to your game.
- seanp2k2 10y ago
  Yep; most likely you don't have Romero and Carmack on your team, who can make a great engine and a fun-to-play game, and even they switched to making engines to power multiple games (id Tech engines). Unity and things like it are great if you're serious about actually making a game and bringing it to market. Engines might be fun, but that's not what sells games and gets them into the hands of people who would enjoy them.
  - rocky1138 10y ago
    Even the tools and engines built by them took years to make. In fact, for a good chunk of the development of Quake, everyone was waiting for Carmack and Abrash to finish the engine.
    - lomnakkus 10y ago
      Yeah, most good things take years to make. #universal-law
- lomnakkus 10y ago
  > This is one of the reasons Unity has become so popular in the industry... Yet someone had to decide to write Unity. Obviously, writing a framework/engine that gets this kind of popularity is in the "unicorn" range, so it's probably not something you should bet on. Still... it could be your engine! :) /tongue in cheek EDIT: Just to contribute a little bit of actual content: I find the "7DRL" episodes of Roguelike Radio to be very informative as to what you need to focus on when trying to ship a game. Obviously, it's focused on turn-based games, but I think most of the experience applies to basically any software project.
tfinniga 10y ago
"Give a man a game engine and he delivers a game. Teach a man to make a game engine and he never delivers anything." https://twitter.com/sandbaydev/status/403219167236857856 https://twitter.com/sandbaydev/status/403219167236857856
- formula1 10y ago
  I literally laughed out loud. Thats a good one!
deleted 10y ago
[deleted]
mcculley 10y ago
It's an easy trap to fall into. Refactoring something that works into a more elegant abstraction is intellectually satisfying work. One need not worry about ill-defined external requirements and is limited only by one's own creativity and capability. Adding value beneficial and perceptible to a user often requires frustrating interaction with people or organizations who don't even know what they want, much less how to communicate it in a form a programmer can work with. Often there are ugly and non-obvious special cases to be dealt with. Left to their preferences, many programmers will retreat into abstraction building instead of doing the hard work of working with users to add value or dealing with the ugly special cases, rationalizing it as the best use of their time.
- kiba 10y ago
  Then those programmers will realize that they hadn't built a game.
- Ace17 10y ago
  Some "engine" vs "gameplay" abstraction is needed though. It's not about re-use, it's about a strategic separation of concerns allowing you to iterate more quickly over your gameplay. You don't want to deal with linear algebra or image format loaders when you're modifying the way your enemy monsters behave.
TazeTSchnitzel 10y ago
Every time, I look around at the existing game engines and decide they're too much hassle to use or don't work quite like I'd like. So I decide to write my own. …and then the game never gets written.
SomeCallMeTim 10y ago
I find myself constitutionally unable to build anything that isn't an engine at this point. When I was young and inexperienced I could crank out Crap That Works(TM) in seemingly no time at all. At this point I know how to write good code and crap code is just too painful to look at ever. So I write good code, and I don't attend 48 hour hackathons.

by veddox 10y ago

ewjordan 10y ago

This is one of the reasons Unity has become so popular in the industry - from a project management point of view, it makes sure that programmers don't start yak-shaving and building tech that's already been built a thousand times by other people. It certainly has its warts, esp when going into full production, but at least in early development it's really good at making sure you're only building what's unique to your game.

seanp2k2 10y ago
Yep; most likely you don't have Romero and Carmack on your team, who can make a great engine and a fun-to-play game, and even they switched to making engines to power multiple games (id Tech engines). Unity and things like it are great if you're serious about actually making a game and bringing it to market. Engines might be fun, but that's not what sells games and gets them into the hands of people who would enjoy them.
- rocky1138 10y ago
  Even the tools and engines built by them took years to make. In fact, for a good chunk of the development of Quake, everyone was waiting for Carmack and Abrash to finish the engine.
  - lomnakkus 10y ago
    Yeah, most good things take years to make. #universal-law
lomnakkus 10y ago
> This is one of the reasons Unity has become so popular in the industry... Yet someone had to decide to write Unity. Obviously, writing a framework/engine that gets this kind of popularity is in the "unicorn" range, so it's probably not something you should bet on. Still... it could be your engine! :) /tongue in cheek EDIT: Just to contribute a little bit of actual content: I find the "7DRL" episodes of Roguelike Radio to be very informative as to what you need to focus on when trying to ship a game. Obviously, it's focused on turn-based games, but I think most of the experience applies to basically any software project.

tfinniga 10y ago

"Give a man a game engine and he delivers a game. Teach a man to make a game engine and he never delivers anything." https://twitter.com/sandbaydev/status/403219167236857856 https://twitter.com/sandbaydev/status/403219167236857856

formula1 10y ago
I literally laughed out loud. Thats a good one!

deleted 10y ago

[deleted]

mcculley 10y ago

It's an easy trap to fall into. Refactoring something that works into a more elegant abstraction is intellectually satisfying work. One need not worry about ill-defined external requirements and is limited only by one's own creativity and capability. Adding value beneficial and perceptible to a user often requires frustrating interaction with people or organizations who don't even know what they want, much less how to communicate it in a form a programmer can work with. Often there are ugly and non-obvious special cases to be dealt with. Left to their preferences, many programmers will retreat into abstraction building instead of doing the hard work of working with users to add value or dealing with the ugly special cases, rationalizing it as the best use of their time.

kiba 10y ago
Then those programmers will realize that they hadn't built a game.
Ace17 10y ago
Some "engine" vs "gameplay" abstraction is needed though. It's not about re-use, it's about a strategic separation of concerns allowing you to iterate more quickly over your gameplay. You don't want to deal with linear algebra or image format loaders when you're modifying the way your enemy monsters behave.

TazeTSchnitzel 10y ago

Every time, I look around at the existing game engines and decide they're too much hassle to use or don't work quite like I'd like. So I decide to write my own. …and then the game never gets written.

SomeCallMeTim 10y ago

I find myself constitutionally unable to build anything that isn't an engine at this point. When I was young and inexperienced I could crank out Crap That Works(TM) in seemingly no time at all. At this point I know how to write good code and crap code is just too painful to look at ever. So I write good code, and I don't attend 48 hour hackathons.