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