3 ms·

Something lots of people in the tech community get really hung up on is focusing on tech and technique rather than what the technology is doing for the user. T

by bane 9y ago

Something lots of people in the tech community get really hung up on is focusing on tech and technique rather than what the technology is doing for the user. There are writeups on here fairly frequently that talk about successful companies being successful despite their product being built on barrels of spaghetti code. This is because those companies are focusing on accomplishing something for the user, not trying to impress with their coding skills (something the customer is not ever likely to see). Games are kind of an ultimate distillation of this phenomenon, they are required to provide a single thing to their user (fun) and anything else is distraction. Games which focus on other things aren't going to make it. Some of the best game designers in the world will ruthlessly focus on designing core mechanics first, with very very basic technology and will work out the necessities of what the game is supposed to do to create fun first before almost any other work is done. This extends to hyper-technical 3d first person shooters as well, with entire games being sketched out with cubes and basic geometry in order get the gameplay perfected. Once that's done, these core mechanics are documented and the rest of the presentation is swapped in. As the game develops, it's checked against this set of documented standards and tested tested tested to make sure key elements haven't been lost. Application development can learn lots from successful game development shops: walk-up interfaces, teaching mechanics, application flow, presentation and so on. It's almost worth studying game development more than other application development models.

humanrebar 9y ago
> ...anything else is distraction Is it? I was under the impression that many game shops do several releases based on the same code. It seems it would be valuable to limit the incremental cost for extra episodes, DLC, Madden YYYY+1, etc.
- caseysoftware 9y ago
  Notice that those examples are wholly dependent on the first thing being successful. Cash flow can solve many, many problems.
- MaulingMonkey 9y ago
  > extra episodes, DLC This is pretty likely to share code. > Madden YYYY+1 This may or may not. Just to keep up with the Joneses, so to speak, may require adopting new graphical techniques and occasionally rewriting your pipeline to better align with the current generation of graphics hardware and APIs. A triple-A studio isn't likely to target the Xbox One or PS4 with an aging d3d9 forward renderer - for one thing, d3d9 isn't even an option for either, and for two it'd look quite dated. Oh sure, you can reuse a little vector math when overhauling to, say, a PBR-oriented d3d11 hdr-supporting deferred renderer, but you've rewritten a huge amount - and what hasn't been rewritten may be a bit awkward and ill-fitting. And of course graphics APIs aren't the only thing changing between console generations. Even the basics like multithreading primitives, basic I/O, gamepad input, user profiles, etc. change wildly. You can build abstractions, but those don't always age well on either the design or the performance front. It's also not uncommon to prototype e.g. your core gameplay loop in an entirely different engine (likely something lightweight that focuses on speed of iteration) than your actual implementation of the idea as a final game (which may focus more on efficiency, high fidelity graphics and animation, etc.) The internal overhauls of a long lived MMORPG may also leave the codebase bearing little resemblance to the earliest released versions. Ports - especially if outsourced - are often developed as very divergent forks, rather than variations on the same shared codebase. So in a very real sense you may have multiple unrelated or barely related sets of code for the same release. If you're less successful, you may be able to stay in the game by reusing your existing codebases more to be a bit more efficient. If you're even less successful, the most efficiently reused codebase in the world won't keep you in business.
- vvanders 9y ago
  They do, however there's one important distinction. Usually somewhere 6-8 months out from ship they fork the codebase from mainline with the discrete intention of not ever merging back. After that point all sorts of game-specific optimizations go in that would/could break other types of games the engine could be used for. Also, if you do ever have to rebase on mainline, it's a bastard to do :).
- ehnto 9y ago
  You should check out the rather prolific and open development of Star Citizen. They are building in what I would considered a great compromise between feature focus and long term technical investment. Some context to why they need to have strong systems in place is that they intend to deliver new content continously into the same platform/engine/world over the course of at least a few years. So their focus is on fast and efficient asset pipelines and the ability to scale, and to that end they have built some very cool technology, but never without a direct purpose that aligns with those goals. It is a great example of pragmatic development. They didn't do network optimization until they had to, they didn't use microservices until it made sense, and then only where it made sense, they have made some nifty tools but only to solve problems that had actually manifested. Not without their failures of course, but we get to learn from those even more so.
  - chii 9y ago
    and yet after this many years of development, there is still no "game" - just tech demos after tech demos. At some point, you have to question whether the 'real' game is going to be delivered!
    - ehnto 9y ago
      Perhaps you haven't been paying too close attention to progress if that is how you feel. Other games of smaller scale have taken more time, and they didn't have to build out a team of hundreds and have massive scope creep like SC has had thanks to reaching various funding goals. Not to mention it is actually two games developed concurrently! The game to be delivered is nothing like the game in the kickstarter, and it only really kicked into full development in the last couple of years. In game dev time it's really impressive how far they have gotten, all things considered. So long as you don't expect the impossible, and understand it is likely still a couple of years away, then you get to see the project in a much more positive light.
CM30 9y ago
> Something lots of people in the tech community get really hung up on is focusing on tech and technique rather than what the technology is doing for the user. This times a million. Outside of games, I've seen this happening a ton in the social media world. You see lots of people on Reddit boasting about 'Reddit replacements' they've made with the latest fancy programming languages and server setups and what not as if that's what people actually care about. They don't. They care about the community on the site and the content you can find there. And the fact of the matter is, your fancy tech demo is completely and utterly dead. No one uses it, so there's no reason for anyone to bother with it either. You're spending all your time tweaking the code and making design adjustments while your site's last post was six weeks ago. Stop with the server setup stuff and constant tech updates and post some content instead. Same goes with games here too, as you mention. It's great you're having fun with the programming side of things, but the vast majority of the world doesn't care how it's been coded at all. Spending all your time on a well coded system and ignoring whether the game is actually fun to play is utterly pointless. As is spending too long trying to be 'perfect' too. You know who else was like that? 3D Realms when they made Duke Nukem Forever. They were so enamoured by thge concept of making the 'most technically advanced game ever' that they wasted 15 years on the same project and didn't actually ship anything. What they should have done was accept their game was midway through development, finish what they had and released it. People would have liked it, the money could have supported future games and they'd have 5 Duke Nukem games finished in that time frame rather than a few tech demos. Enough with the tech obsession here. Focus on what matters, your game or product's actual purpose and who it's made for.

by bane 9y ago

humanrebar 9y ago

> ...anything else is distraction Is it? I was under the impression that many game shops do several releases based on the same code. It seems it would be valuable to limit the incremental cost for extra episodes, DLC, Madden YYYY+1, etc.

caseysoftware 9y ago
Notice that those examples are wholly dependent on the first thing being successful. Cash flow can solve many, many problems.
MaulingMonkey 9y ago
> extra episodes, DLC This is pretty likely to share code. > Madden YYYY+1 This may or may not. Just to keep up with the Joneses, so to speak, may require adopting new graphical techniques and occasionally rewriting your pipeline to better align with the current generation of graphics hardware and APIs. A triple-A studio isn't likely to target the Xbox One or PS4 with an aging d3d9 forward renderer - for one thing, d3d9 isn't even an option for either, and for two it'd look quite dated. Oh sure, you can reuse a little vector math when overhauling to, say, a PBR-oriented d3d11 hdr-supporting deferred renderer, but you've rewritten a huge amount - and what hasn't been rewritten may be a bit awkward and ill-fitting. And of course graphics APIs aren't the only thing changing between console generations. Even the basics like multithreading primitives, basic I/O, gamepad input, user profiles, etc. change wildly. You can build abstractions, but those don't always age well on either the design or the performance front. It's also not uncommon to prototype e.g. your core gameplay loop in an entirely different engine (likely something lightweight that focuses on speed of iteration) than your actual implementation of the idea as a final game (which may focus more on efficiency, high fidelity graphics and animation, etc.) The internal overhauls of a long lived MMORPG may also leave the codebase bearing little resemblance to the earliest released versions. Ports - especially if outsourced - are often developed as very divergent forks, rather than variations on the same shared codebase. So in a very real sense you may have multiple unrelated or barely related sets of code for the same release. If you're less successful, you may be able to stay in the game by reusing your existing codebases more to be a bit more efficient. If you're even less successful, the most efficiently reused codebase in the world won't keep you in business.
vvanders 9y ago
They do, however there's one important distinction. Usually somewhere 6-8 months out from ship they fork the codebase from mainline with the discrete intention of not ever merging back. After that point all sorts of game-specific optimizations go in that would/could break other types of games the engine could be used for. Also, if you do ever have to rebase on mainline, it's a bastard to do :).
ehnto 9y ago
You should check out the rather prolific and open development of Star Citizen. They are building in what I would considered a great compromise between feature focus and long term technical investment. Some context to why they need to have strong systems in place is that they intend to deliver new content continously into the same platform/engine/world over the course of at least a few years. So their focus is on fast and efficient asset pipelines and the ability to scale, and to that end they have built some very cool technology, but never without a direct purpose that aligns with those goals. It is a great example of pragmatic development. They didn't do network optimization until they had to, they didn't use microservices until it made sense, and then only where it made sense, they have made some nifty tools but only to solve problems that had actually manifested. Not without their failures of course, but we get to learn from those even more so.
- chii 9y ago
  and yet after this many years of development, there is still no "game" - just tech demos after tech demos. At some point, you have to question whether the 'real' game is going to be delivered!
  - ehnto 9y ago
    Perhaps you haven't been paying too close attention to progress if that is how you feel. Other games of smaller scale have taken more time, and they didn't have to build out a team of hundreds and have massive scope creep like SC has had thanks to reaching various funding goals. Not to mention it is actually two games developed concurrently! The game to be delivered is nothing like the game in the kickstarter, and it only really kicked into full development in the last couple of years. In game dev time it's really impressive how far they have gotten, all things considered. So long as you don't expect the impossible, and understand it is likely still a couple of years away, then you get to see the project in a much more positive light.

CM30 9y ago

> Something lots of people in the tech community get really hung up on is focusing on tech and technique rather than what the technology is doing for the user. This times a million. Outside of games, I've seen this happening a ton in the social media world. You see lots of people on Reddit boasting about 'Reddit replacements' they've made with the latest fancy programming languages and server setups and what not as if that's what people actually care about. They don't. They care about the community on the site and the content you can find there. And the fact of the matter is, your fancy tech demo is completely and utterly dead. No one uses it, so there's no reason for anyone to bother with it either. You're spending all your time tweaking the code and making design adjustments while your site's last post was six weeks ago. Stop with the server setup stuff and constant tech updates and post some content instead. Same goes with games here too, as you mention. It's great you're having fun with the programming side of things, but the vast majority of the world doesn't care how it's been coded at all. Spending all your time on a well coded system and ignoring whether the game is actually fun to play is utterly pointless. As is spending too long trying to be 'perfect' too. You know who else was like that? 3D Realms when they made Duke Nukem Forever. They were so enamoured by thge concept of making the 'most technically advanced game ever' that they wasted 15 years on the same project and didn't actually ship anything. What they should have done was accept their game was midway through development, finish what they had and released it. People would have liked it, the money could have supported future games and they'd have 5 Duke Nukem games finished in that time frame rather than a few tech demos. Enough with the tech obsession here. Focus on what matters, your game or product's actual purpose and who it's made for.