[swat17]

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.

[jmull]

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?

[swat17]

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

[freeflight]

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

[chii]

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

[jmull]

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.

[striking]

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

[chii]

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.

[masiulis]

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.

[luckydata]

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]

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

[kbenson]

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

[Domenic_S]

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.

[ethbro]

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.

[moron4hire]

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.

[matwood]

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.