6 ms·

It's more like he saw a type of game that made a lot of money that seemed not that technologically advanced and thought he could replicate the monetary success

It's more like he saw a type of game that made a lot of money that seemed not that technologically advanced and thought he could replicate the monetary success and this part was like a lot of apps - it's not the making of the app that is hard - it's making an app that people want/need to use in numbers to support the development. I mean no disrespect because his team did succeed in producing an online only game so that part was not a failure. However, leaving the figuring out the fun bit to the end doomed the project (as a fun to play game) in my opinion.

naiyt 9y ago
Yeah, I'm at the part where he's implementing lag compensation before even building a fun prototype for the game. Seems very backwards. (This problem may very well be addressed later in the post, still working my way through it. It's an interesting article.)
- eterm 9y ago
  He also says that Carmack re-wrote the quake network engine which is true, but links to and focuses on Valve's lag-compensation which went far further than what quakeworld did. The quake re-write was Quakeworld[1], which didn't have valve's lag compensation for shooting. The crucial thing that quakeworld did was de-couple client and server for movement. The result was that when you fired you would see your shot locally, but any effects from that such as blood wouldn't be seen until you got a response from the server. You would still have to lead your shots (shoot ahead of moving enemies) in quakeworld to hit on a modem. Even Half-life (based on the Quake 1 engine) didn't have valve's lag compensation until the half-life 1.1 patch in 2000, two years after half-life was first released. [1] https://en.wikipedia.org/wiki/QuakeWorld https://en.wikipedia.org/wiki/QuakeWorld
  - ryandrake 9y ago
    Here's another fact about the Quake re-write: It was done AFTER the hugely successful product was shipped, not before.
    - bananaboy 9y ago
      Yeah, this should be the key take away from that anecdote!
advice_giver 9y ago
Yeah, I see this all over these indie game dev posts. Highest priority is writing your own engine and solving some deep but tertiary technical problem. Whether the core mechanics are fun or not is whatever. It's truly BPDD (blog post driven development).
- stevenwoo 9y ago
  It's pretty funny because I got lucky and got paid to game development with people who made some big hits and the very first thing we did after getting a block to draw on the screen was try to make a fun game mechanic. Even for a multiplayer online game - we made or simulated something that could be done on a developer's machine to find something fun first and then worked on the multiplayer details that this blogger spent a large amount of time on - in at least two of the three parts of the blog postings on this project - we had difficulties to overcome in exactly the same manner in adding multiplayer to a game but that was after we had something fun.
- rhizome 9y ago
  It also validates their student loan payments.
swat17 9y ago
It seems so obvious reading his post that he went at this backwards. The basic idea of developing and iterating on a lightweight MVP is completely absent. I'm genuinely curious - because I see this error replicated all the time when engineers try to take a side project to market - why otherwise rational people do this. This approach is obviously doomed to failure. I understand that as programmers we enjoy solving technical problems, but that should be second to actually building something that people enjoy (if that's your stated aim). Why do developers so often seem to lack this foresight? Are we just too absorbed in our craft to see the forest for the trees, and we mis-prioritize as a result? Shouldn't there be some moment of self realization, akin to "oh fuck, I just spent the last 3 months fixing the lag on a game that doesn't actually exist?" The psychology of this error bewilders me.
- moron4hire 9y ago
  It is psychological. It's a lot easier to tackle the problems you know about, and know how to handle (even if it's just knowing the meta-process of how to figure out how to handle it), than it is to take on completely new, alien types of work. Every project has too many tasks. It's the things we don't know that we don't know that hurt us the most.
- luckydata 9y ago
  Because primary and secondary market research is a skill just like programming, takes time to master and many just think that asking a few people unfocused questions constitute research. The easy way to gain knowledge is build things and see if it works which is crazy expensive. Even the famous MVP is just a catchy name for market research that has gotten out of control due to the unfortunate decision of putting "product" in the acronym.
  - eric_h 9y ago
    > Even the famous MVP is just a catchy name for market research that has gotten out of control due to the unfortunate decision of putting "product" in the acronym. I think the general problem with MVPs and their development and usage is really that people put significant focus on the 'M' and the 'P' and very little to the 'V', which IMO is the most important letter in that acronym.

naiyt 9y ago

Yeah, I'm at the part where he's implementing lag compensation before even building a fun prototype for the game. Seems very backwards. (This problem may very well be addressed later in the post, still working my way through it. It's an interesting article.)

eterm 9y ago
He also says that Carmack re-wrote the quake network engine which is true, but links to and focuses on Valve's lag-compensation which went far further than what quakeworld did. The quake re-write was Quakeworld[1], which didn't have valve's lag compensation for shooting. The crucial thing that quakeworld did was de-couple client and server for movement. The result was that when you fired you would see your shot locally, but any effects from that such as blood wouldn't be seen until you got a response from the server. You would still have to lead your shots (shoot ahead of moving enemies) in quakeworld to hit on a modem. Even Half-life (based on the Quake 1 engine) didn't have valve's lag compensation until the half-life 1.1 patch in 2000, two years after half-life was first released. [1] https://en.wikipedia.org/wiki/QuakeWorld https://en.wikipedia.org/wiki/QuakeWorld
- ryandrake 9y ago
  Here's another fact about the Quake re-write: It was done AFTER the hugely successful product was shipped, not before.
  - bananaboy 9y ago
    Yeah, this should be the key take away from that anecdote!

advice_giver 9y ago

Yeah, I see this all over these indie game dev posts. Highest priority is writing your own engine and solving some deep but tertiary technical problem. Whether the core mechanics are fun or not is whatever. It's truly BPDD (blog post driven development).

stevenwoo 9y ago
It's pretty funny because I got lucky and got paid to game development with people who made some big hits and the very first thing we did after getting a block to draw on the screen was try to make a fun game mechanic. Even for a multiplayer online game - we made or simulated something that could be done on a developer's machine to find something fun first and then worked on the multiplayer details that this blogger spent a large amount of time on - in at least two of the three parts of the blog postings on this project - we had difficulties to overcome in exactly the same manner in adding multiplayer to a game but that was after we had something fun.
rhizome 9y ago
It also validates their student loan payments.

swat17 9y ago

It seems so obvious reading his post that he went at this backwards. The basic idea of developing and iterating on a lightweight MVP is completely absent. I'm genuinely curious - because I see this error replicated all the time when engineers try to take a side project to market - why otherwise rational people do this. This approach is obviously doomed to failure. I understand that as programmers we enjoy solving technical problems, but that should be second to actually building something that people enjoy (if that's your stated aim). Why do developers so often seem to lack this foresight? Are we just too absorbed in our craft to see the forest for the trees, and we mis-prioritize as a result? Shouldn't there be some moment of self realization, akin to "oh fuck, I just spent the last 3 months fixing the lag on a game that doesn't actually exist?" The psychology of this error bewilders me.

moron4hire 9y ago
It is psychological. It's a lot easier to tackle the problems you know about, and know how to handle (even if it's just knowing the meta-process of how to figure out how to handle it), than it is to take on completely new, alien types of work. Every project has too many tasks. It's the things we don't know that we don't know that hurt us the most.
luckydata 9y ago
Because primary and secondary market research is a skill just like programming, takes time to master and many just think that asking a few people unfocused questions constitute research. The easy way to gain knowledge is build things and see if it works which is crazy expensive. Even the famous MVP is just a catchy name for market research that has gotten out of control due to the unfortunate decision of putting "product" in the acronym.
- eric_h 9y ago
  > Even the famous MVP is just a catchy name for market research that has gotten out of control due to the unfortunate decision of putting "product" in the acronym. I think the general problem with MVPs and their development and usage is really that people put significant focus on the 'M' and the 'P' and very little to the 'V', which IMO is the most important letter in that acronym.