Hacker News Reader

Comment by stevenwoo | Hacker News Reader

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.

View on HN

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.

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.

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.

> 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.

I know like 2 engineers who are really, really good at coming at problems from a business perspective and I know like 70 who work the way you describe.

Maybe it's because if you acknowledge the business as the most important, then engineering is only a means to an end and not important. I think that's an error in reasoning, but it makes some sense.

To me, it's having the humility to accept that someone may know less about tech than you, but still more about the problem at hand.

> why otherwise rational people do this.

Because rational people aren't really rational, they're just slightly more rational that other people in certain aspects. It's really hard to actually see what biases are in your assumptions, and you have to assume quite a lot to get through every day.

> Are we just too absorbed in our craft to see the forest for the trees, and we mis-prioritize as a result?

It's easy to assume the thing you know how to fix has a big impact on success, because the alternative is often scary unless you've cultivated the correct mindset. Even after you've cultivated that mindset, it's easy to not realize you apply it to some portions of your life and not others, or even some problems and not others in the same area.

I think it depends. A lot of people claim a side business/project, but in reality they are just learning new tech. Learning new tech is perfectly fine!

I think what you are arguing is for people to just be honest with themselves.

Well, wait a minute.

The author started with a simple, fun-to-play game, worked on it iteratively until it reached a certain level, did a release push, and continued to iteratively improve the game. (I realize that "fun-to-play" is subjective, but that's the author's call at that point.)

I'm trying to see how this is fundamentally at odds with what you're thinking the approach should be?

If you, as the creator of a game, think dealing with the lag is necessary to making your game fun, then how could you possibly justify not resolving it prior to release?

Maybe test it locally with a split screen mode? Or lower your coding standards? It takes a day max to start a node server with websockets (he did that in the end anyway).

The biggest mistake I think was that the author "personally prefer strategies (such as Civilization) over action/arcade type of games", but decided to build a multiplayer game. With no experience. Now that is a recipe for a disaster.

> how could you justify not resolving it prior to release?

I'm not objecting to him addressing the lag, I'm objecting to him resolving it first. Until you've built something people want to play, addressing lag (and similar tertiary problems) is solving a hypothetical problem for a hypothetical player. And it may well be wasted effort, if you never nail the core product. But if you approach it from the other direction, as most game devs would, you know with a greater degree of certainty whether you should spend the time polishing. You either nail the core mechanics of the game and know that your polish work is justified in bringing the product to market, or you discover you don't have a product at all and avoid wasting your life solving imaginary problems.

Because even side projects are resource constrained. He missed a vacation with his wife. This is tragic, and happens all too often when you approach a product from a technical perspective prematurely.

I don't think you can separate the core mechanic from the lag. If it's a multiplayer game where the internet is the medium of communication, then any gameplay mechanic has to be tolerant of the lag. If it isn't, you don't have a game.

Dealing with the lag is part of the MVP, not polish.

Yeah, but you can iterate on the gameplay before solving lag, locally.

this only works if you are testing locally with actual players (sitting locally on the lan). If you/your team is the one doing the testing, you don't get real (player) feedback.

> Until you've built something people want to play, addressing lag (and similar tertiary problems) is solving a hypothetical problem for a hypothetical player.

Sadly those are not always hypothetical players. Gamers can be very demanding when it comes to such things as performance and especially network performance in anything related to PvP.

Tho, I agree with your premise: Have something that's fun first, then deal with everything around it. I just don't think it's that easy in practice when a lot of the player feedback boils down to "I couldn't tell you if the game is fun or not because your crappy netcode keeps getting me killed, that's not fun at all!".

In that regard, Steam forums for EA titles are sometimes their very own circle of hell.

> Have something that's fun first, then deal with everything around it.

but what if the fun is only apparent if the lag is gone, and the camera movement/framerate is smooth, etc? These are sometimes considered polish, and yet, you can't tell if the game is good or not based on a jittery, laggy version!

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).

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.

It also validates their student loan payments.

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.)

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

Here's another fact about the Quake re-write: It was done AFTER the hugely successful product was shipped, not before.

Yeah, this should be the key take away from that anecdote!

Reply on news.ycombinator.com