I don't mean to be dismissive, but here are the main issues I see with the process (and the final product):
- Bottom line, the game is not particularly fun, novel, or difficult. You'll notice that games like Flappy Bird, Agar.io, Papers Please, etc. are at least one of the three. Bist.io is not the type of game that will ever go viral.
- You spent money on AdWords but didn't spend money on sponsored Youtube, Instagram, or Twitch content? To me, this just shows a fundamental disconnect with your target audience (gamers).
- You should never polish a multi-player game until extensive play-testing. Single player games are a bit different, but with multiplayer games it's the mechanics that sell it. If the mechanics aren't fun, polish doesn't matter. Case in point: H1Z1 and PUBG. Awfully optimized, and generally terrible lag, but still massively fun and massively successful.
- Too much premature optimization. Having your servers blow up is a good thing. Don't worry about preventing the blow up until you get there. In other words, you spent too much time on load balancing, etc. This is the canonical reason good engineers make bad business decisions.
Going into something (even games) to make the big bucks is perfectly fine, imo, but, in short, your game just isn't very good and you have no idea who your audience is. You added "social" buttons because it's the "thing you're supposed to do" but omitted Twitch and Steam? You're not on IndieDB or TIGSource?
You're a legend Walter, but there are millions of games available to play now. The days when a title circulated around university PDP-10s are gone. The dynamics of virality are very different.
Look at the vast majority of successful indie games on Steam produced by, say, no more than five people. They're basically all labors of love, the missing niche game that they wanted to make and play.
I can't think of a single independent success story that involved someone doing careful market research and engineering a product. There's a reason only big companies take that approach.
It's especially difficult when the game you want to play is probably out there, but impossible to find because it's buried by tons of other crap. So do you build the game only to find that the one you're looking for was there all along, then have everyone call you a copycat?
I think this is an awesome point -- and I can't help getting a bit giddy at Walter Bright replying to my comment. I think being passionate about what you're building is one of the best indicators to success (as opposed to something that you want to make a ton of money with).
It's _really_ not. It is important to enjoy and be passionate about your game. But writing your ideal game is a recipe for making crap, in my humble experience, unless you happen to be intuitively skilled in game design.
what experience is that? you seem to suggest something which seems unlikely; there are a bunch of second order effects involved with making a game you're interested in.
> I’d be curious to hear how good D can be in that area
Many of the games by ABA Games/Kenta Cho (Torus Trooper being the one I played the most, a long time ago) are all written in D, as is his BulletML library that is used in most of his games.
Best way to go. It's hard to make something great unless you're personally invested imo. Although, Carmack can do about anything he sets his mind to. Love that guy.
Once when I was working at a game publisher I thought it would be fun to help an indie game project anonymously. At that point I had designed or produced many games, but the job was going through a dull phase. So I picked out a project on sourceforge (this was a long time ago) and offered to help out.
Pretty much all they were doing was recreating all the UI widgets in any OS (buttons, pull down menus, etc.). Everything was less than half done and there was a lot of work put in. I suggested maybe prototype some gameplay.. No, it was important that they start from a clean code base.
On the one hand that's sort of mindblowing, on the other not that surprising, and reading the original article just underscores my (thankfully brief) experience of working in a large enterprise: the one thing you can absolutely trust is that when it comes to product development a senior enterprise developer or architect will always focus on the wrong problem.
I find their approach to software development in general, and product development in particular, to be both asinine and perverse, and despite banging on endlessly about architecture and agile none of them seems capable of delivering even mediocre software, let alone anything you'd call good, in anything other than a geological timescale.
Applying those observations to this case: they should have focussed on creating a fun game, i.e., on what users want. Instead they focussed on technical and architectural issues and built something that sounds like an impressive piece of software but which is not fun, and which doesn't feel terribly polished or playable. In other words, they failed, although at least they have the stones to admit it.
This is enterprise software allover. Seriously, if you want to build good software, where "good" means 10x value adding in your domain of choice, and which users love, do NOT work in a large enterprise, and do not work with enterprise developers. These people will waste your time, hold you back, and drag you down.
(All of that being said: interesting article, and a worthwhile read if only as an illustration of how not to do things, and hopefully the author really has learned something useful.)
There is value in writing clean, impeccably-designed, beautifully architected, const-correct, lint-free software. Just not much business value in it. I have unreleased hobby projects sitting on my hard drive at home that are works of art (if I must say so myself!), and were great learning experiences, but are commercially pretty much valueless. That's OK.
You need to have a goal and adapt your software writing to that goal. If your goal is to make the next Flappy Bird and pull in $100K revenue per day, you probably don't want to be spending your time figuring out why "the time between ticks increased to 20-30 ms and then it dropped again." Your time would be better spent slapping together version 0.01 of about 40 games and shipping them, hoping one of them takes off.
Needing to optimize and rearchitect something is a problem you have after you get U$ER$.
> you probably don't want to be spending your time figuring out why "the time between ticks increased to 20-30 ms and then it dropped again.
When I was in mobile games (3D) we saw a direct correlation between framerate and revenue. We released a patch that (accidentally) slashed the frame rate and our revenue tanked. We released a patch that did nothing but fix the performance and our revenue went back up to previous amounts.
Businessvalue-only code can get complex though, and difficult to work with. But, maybe, when the value/intention is clear, it makes it easier to understand. (That is, until there's years of accumulated complexity).
@bartread That's an awfully high and mighty opinion, don't you think? Sounds like annoyance over the fact that things that work reliably aren't "cool" enough.
It's certainly annoyance - and a good amount of it - but cool doesn't come into it. What I'm really railing against is people who talk a good game but seem to be incapable of delivering anything but bad software (regardless of whether what it does is supposed to be "cool", whatever that might mean when taken in context), and includes unreliable.
I have to admit that it may not be entirely they're fault: organisational culture shapes you whether you want it to or not. So perhaps what I'm really railing against is a culture of software development that tends to exist in larger organisations.
Clearly this isn't universal though - just common. There are notable examples where very large organisations have been able to avoid these problems, at least for a while, even at scale: Google, BBC, parts of Microsoft (I can personally attest to this one), facebook (although hearing from a friend t sounds like they're getting sucked into it).
I do find it frustrating that guys like this style themselves as thought-leaders - and often succeed - whilst unfailingly focussing on the wrong points, and making themselves a complete pain in the ass to everyone they work with.
The other point is that as I've got older it's become starkly obvious to me that I only have so much time left. Obviously that's always been true but when I was younger I suppose I just didn't take it that seriously, and that's sort of a gentle regret. And that's really for everyone: you don't have all the time in the world so if there's something you want to do then get on and do it - sometimes you have to do things just to make ends meet but, as far as is possible, don't subject yourself to anyone who's going to hinder you on that journey.
With that extra context, I agree. It can be quite frustrating to work with people who don't perform, or who don't understand where to focus their work.
if you make a game, you make a playable proto-type first. And that proto-type must be fun. Period.
Can be horri-bad in every other aspect.
Can be even bad regarding the architecture years after you went to market. Notch, we are still looking at you here!
And if the game is fun- it will still sell.
If Tech would attack that core-value, then changes are very much in order - but building the perfect system, before you know the game you do it for is fun- that is creating blueprintporn, with no value for the players.
this is what engineers do (I'm an engineer). All they can see is the tech and ok, maybe that's that they enjoy but it really has little to do with a hit game (here come the comments ;)
It's like claiming that most movies couldn't be made unless will build our own cameras from scratch.
The thing is, building engines and tools is conceptually easy. It might be a lot of work but it's mostly known solutions so we (engineers like me) see a big todo list and just do it. We get in the flow. We get proud of our solutions (even though 40k new games shipped this month that some how solved the same problems).
But arguably the real work is in design and design is much harder, at least for me, because it's a blank slate. I don't have to reinvent how to read joypads or stream files or serialize data. Sure I might write my own but it's arguably a waste of time. They real hard work is figuring out the game itself. Prototyping, trying out new ideas. Grab some working solutions (Unity, Unreal, or your favorite open source libraries, spend as little time as possible on tech and as much time as possible trying out ideas).
Of course I write that advice and I've believed it for years but I still fall back to my engineering ways and find busywork to do like add some unit testing system or automate some other step. Meanwhile no prototypes. No games.
I think your first point is the one that matters the most. The primary thing you should be thinking about here is "how compelling is this going to be to the intended audience?"
If you can get to the point where you can hammer out a game in a weekend, which isn't that difficult, I'd suggest building a simple game that showcases the concept that you find compelling and submit it a game jam like Ludum Dare. You're going to get a bunch of people playing it and you'll be able to see if they respond to the concept.
If they do, then go ahead and make a larger version of the game. If not, well it just costed you a weekend anyway.
I think a great example of this is Derek Yu's "Spelunky." He made a quick 'n dirty freeware version, which turned out to be massively popular, then remade a polished commercial version. It was easier for him to pitch the publisher since there was already a working, popular prototype.
the freeware version wasn't "quick 'n dirty" at all - he spent a lot of time doing it (and tweaking/fiddling the random generation).
Ditto with another game that may have been seen as a "quick 'n dirty" prototype - super meat boy (the flash version). These games had lots of time and effort spent polishing the mechanics/controls.
That's not to say one shouldn't do quick 'n dirty prototypes, but don't put your own prototypes up against those above, and say it sucks - coz you probably didn't put as much time or effort in it as them!
Interestingly, Tommy Refenes, which was written in C++, posted a write up that went over the process. What struck me is that he built a tool to export sprites from Flash because that's what the artist used.
It shows an iterative development model, focusing on gameplay features step by step. The big take away "focus on making the character do something":
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.
> 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.
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.
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.
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 :).
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.
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.
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.
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.
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?
> 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.
> 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!
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
I have been having a lot of fun playing this game with lots of others here on Hacker news.
Some suggestions:
1) Make the levels more obvious. It's not clear why players are stronger than others for some time. It would also be nice to see how far I need to go to level up more clearly.
2) ADD CHAT! I can't emphasize this enough. We need to be able to yell at each other and complain and work together.
3) Add the ability to switch classes more often.
4) Make the differences between bots and humans more obvious. I want to immediately know when I am fighting a person. A different color name, make them glowing, something.
5) Show the leaderboard after you finish. I want to be the best player today, or the last hour, or the last week or whatever.
6) Don't deduct any stats when I level up. Sometimes when you level up you are suddenly slower. I shouldn't get punished for leveling up.
7) Show my kills against different players. Let me develop a grudge. It makes it fun.
8) Show a message when a player kills a player! Let us know something cool happened.
> 6) Don't deduct any stats when I level up. Sometimes when you level up you are suddenly slower. I shouldn't get punished for leveling up.
I think that's for balance reasons and I kinda like that dynamic.
New players that join are weak and fast, high level players are powerful but slow, that way new players at least can run away from a hopeless fight against a way higher level.
The snowballing is already pretty bad as it is, high level tanks nearly instagib the low level ones. If high level tanks would be just as fast as the low level ones then no late joiner would stand a chance and the field would be dominated by that one guy/gal who managed to get max level first.
My suggestion would be to set the game to a fixed zoom level. Right now players can get quite an advantage by using the browser zoom function to zoom out and see further than players with standard browser settings.
If you're still willing to work on the game, then you're really still developing it!
You're getting a lot of decent feedback here. Although there's lots of feedback that is more negative than necessary, too. Don't worry too much about that.
Take the good bits of advice, and keep on polishing the game if it still interests you. Even if it didn't become a hit right away, that doesn't mean it's a failure. :)
Heck, even if it never becomes a hit, you made your first game and people are actually playing it. There are lots of games that never achieve even that. And you can take the lessons learned here and apply them to the next game you write.
And for what it's worth, I had fun playing it. It felt sort of like Subspace in tanks.
I love reading this kind of open, honest postmortem.
By the way, I think the people here saying things like, "Oh, he should've just done x, y, and z to solve his problems," are most likely kidding themselves.
Developing and releasing decent software is hard. Making a financially successful indie web game is even harder, no matter your process because a substantial parts art and luck which are inherently not predictable.
The author seemed to pretty successfully developed and released the game and did a half-decent job on marketing it despite being a complete novice in that area. All and all, a pretty nice accomplishment.
"I figured that even if the article is off by 2 or even 3 orders of magnitude, I would still be doing very well should I develop something similar."
Here's your problem. Firstly: lame motivation, in that there's no reason for a player to give a crap about this motivation. It doesn't relate to the experience of the game at all, only to 'players give me money'.
More importantly, you're fundamentally misunderstanding how internet markets work. It's always a 'viral' power-law thing where the one you're getting excited about, the incredibly profitable game or the PewDiePie youtuber etc, is unattainable. You can't have that, you're not already them, and there IS no 'second or third order of magnitude', those are also extremely tiny groups and it takes decades of work and impressive existing name recognition to even get there.
There is no correlation between merit and reward, except that 'a set level of merit is required just to get you into the zone where the power-law guys operate'. Past that point it's essentially arbitrary and governed by rules you can't affect. You don't get to turn into a PewDiePie or a slither.io, there already is one.
My advice as somebody who's in the top 3.5% of all Patreon worldwide (which is surprisingly nonlucrative, further making my point) is this: look to what you're already doing in life. For me, it's audio hacking, and so my Patreon around that 'succeeded' because I came into it with literally ten years of doing business and being known by the general audio-plugin public, with an existing brand identity and a dedicated fanbase. That got me earnings roughly a third or a quarter of what direct sales was getting me (but: much more steady and predictable and growing, which has done me a world of good).
If you haven't already been publically making games for ten years or so, the last thing you should do is look at slither.io and go 'I should do that and make a tenth/hundredth of the money. How hard could it be?'
You're fundamentally misunderstanding how internet economics work. On the internet, if you try to get 1000th as much as slither.io by making something half as good and hoping for the best, you get NOTHING.
An alternative approach to creating a game is to ask yourself a series of questions (paraphrased from [1]):
* Who are the likely players?
* What are their motivations for playing?
* What are their objectives in the game?
* What does the game world look like?
* What are the mechanics by which the player interacts with the world to achieve those objectives?
* What makes the objectives, world and mechanics compelling to the player?
This is a great example of the fallacy that if you like games and can program a game, you can be a game developer and get any traction. Programming isn't really the hard part, and it gets easier every day. It is true if you can do something technically bleeding edge you will be sought after by game companies and other companies as well.
Imagine:
I have liked movies my whole life. I read that Paranormal Activity was made by a guy with a video camera and very little money. So I thought I would get a camera and become a film maker. Surprisingly, it didn't work.
Radar is super tiny and hidden beneath my right hand, I could not see it, and I sure couldn't see any dots on it.
Upgrade UI is way too tiny to use. And hidden beneath my left hand. I tried stabbing at it a couple of times and I ended up upgrading the option above what I actually wanted.
Game Over is really unceremonious. It doesn't tell me that if I get back in it'll keep my upgrades. I buzzed around for a few minutes and have no desire to go back in.
Focusing the controls on cardinal directions and diagonals felt really really limiting when I have a virtual thumb stick to use. I never felt like I was aiming in the direction I wanted to, or moving. I have also played a LOT of twin stick shooters, I dunno if this is trying to be one or not.
No sound.
No world. I mean how about trees I can lurk under? Just an endless plain full of boxes and tanks. I guess that's more than Slither.io has, that just has player snakes, but...
No real distinction between tank levels, and what about all that tank type selection mentioned in part 3? I never saw that. I just had a tank. A tank with weird sluggish controls. And no sound. Seriously sound does more for games than art, get some sounds in there.
Or just take that super solid net code and prototype four completely new games on top of it in a week apiece. Programmer art and stub sounds.
Maybe go look at actual successful twin stick shooters. For instance playing that made me want to cleanse my palate so I pulled up Assault Android Cactus, which is everything this is not: it's a super cute game with local co-op, multiple characters with very different play styles, and a nice little selection of power ups.
Make some bots that run around in obviously non-tank skins. Weak but numerous, clearly different. Throw in some bosses that require multiple players to destroy. Those two things would make it more amusing when it's empty, AND have a reason to bring friends in. (Name the bosses, keep them down to only a few on the map at a time, if even more than one, keep track of who kills them, hand out medals for doing so)
Right now it's way too slow for this but some kind of Chain Combo mechanism always helps shooters have depth - once you have the basics down you can start chasing high chain, maybe have score multipliers, maybe start showing a visual effect for people with a chain going and offer bonuses for taking them down. (In it's simplest form, a chain combo usually starts happening when you quickly kill several enemies without taking damage; every time you kill an enemy start a timer counting down for a second or three, and if it hits zero then you lose your combo. Play a sad noise when this happens.)
Also stop making your designer draw tanks. Pay her to draw whatever the hell she thinks would be cool on top of the movement patterns you come up with for bots and for the players. Roll with whatever it is. Tanks are boring to draw and full of lots of stupid fiddly details. If you end up with a game about cute bugs and unicorns and squid running around throwing hearts at each other? GREAT. It's got something to stand out.
I mean right now this thing doesn't even have a NAME that means anything, much less any kind of visual appeal.
I tried game development multiple times and it was the reason why I started programming in the first place, modding etc. pp.
But the huge problem for me is content.
I often end up with a nice idea and implementation, but the whole images, models, animations, sound and effects stuff bores me to death.
It feels like code is only 20% of the whole thing and the rest is basically mechanical repetition.
But that's what makes it look cool, it's like... I'm done implementing and getting all the controls right and I feel like I can't see the whole thing anymore, but then it gets nice graphics and sounds and it feels like a whole new game, haha.
or even "A story about how I tried to get my game to go viral and failed".
The game exists, and it's playable. Is it perfect? no. Is it making tons of money? no. But it was developed - you only "fail" to get into game development if you stop trying to make improvements/changes/optimizations.
> you only "fail" to get into game development ...
well, it depends on the original goal too. If making the game itself was the goal, then yes. But if making the game successful (e.g., player count, or money) was the goal, then no, you can't say it was a success.
Most game devs who want to make a game probably (at least, secretly) want it to succeed with the latter definition.
I'm the guy that made Agar.io, and I personally hate that term, but I don't think we'll ever win the war of getting people to stop calling those browser MMO games "io games"
I taught at a summer camp that had a curriculum focused on playing and modding Minecraft. One of the biggest challenges we faced was getting the kids to stop playing Agar.io for long enough to play Minecraft.
Have you written any development posts like this? I'm sure everyone on HN would be really interested to hear your thoughts about this post, and how it compares to the development of agar.io. Did you sort of just get lucky with the game mechanic, or was it something that you put a lot of thought into? Was agar.io originally supposed to be a different game?
There was a post with some technical details on Agar.io a while ago back when it was released (>2 years ago). A year after Agar.io I made Diep.io, which is also fairly successful (but not nearly as crazy as agar.io), so that points to it not being completely based on luck :)
I just make what feels fun. For a perspective on development cycle: the initial version of Agar.io took 1 week, while Diep.io took less than a month too (it was released a lot more polished than agar.io). Of course, they continued receiving updates for months, but the initial version was already fun.
While the initial version for both games was coded fairly quick, there were months of thinking about them before I even started coding, and from beginning of development to first version the gameplay plans didn't change.
The protoype of my successful (non-game) software took 2 hours (though it percolated a while).
But I still haven't finshed a prototype of my recent ideas, after years of research and development. Could it be that successful ideas are simple enough to prototype quickly?
But what about complex games, like Horizon Zero Dawn, or Zelda: Breath of the Wild?
It turns out they did prototype BotW... and not the beautiful 3d graphics or physics, just a 2d top-down version.
Wow, I'm really enjoying diep.io, and I just realized it's extremely similar to the game in this post. The OP must have seen diep.io and borrowed a lot of game mechanics. But they still didn't do it right, because I only played their game for a few minutes, while I was hooked on yours. That's a very valuable lesson: the game has to be fun and engaging, and the technical details are almost insignificant compared to that.
Thanks for agar.io - it cools.
Any chance of a AMA or similar ?
Would be really interested on the technical aspects (only 1 week! to minimal viable product) ?
Also on the ad revenue ? (where it is not commercially sensitive ?)
Also the fun stopping bots playing the game ?
Your view on the great trick moves (and youtube videos), are these fake or are people really that good ?
Do you play it much yourself ?
At least you're better off than those guys who created the "pc" market category, only to have those two letters come to mean their competitor, and not them.
Or an 'i game', a game that takes only input and provides no feedback. Like waving your hands in the air and pretending you are playing a VR game; or a Karate kata.
But the problem with this name is that the 'io' part is entirely based on the url - would one still call this 'genre' an 'io game' if the url to it doesn't end in '.io'?
I think the history goes: agar.io and slither.io were surprise smash-hit games that both featured simple, drop-in-and-play multiplayer HTML5 with a dedicated .io domains. They inspired literally hundreds of copycats that each set up .io domains to signal that they were following they genre. The genre has become so popular that "io game" is now a term.
I was introduced to this by my friend's (USA) elementary school age kids last year - they showed me a lot of games on the .io TLD. mope.io was popular for a time - it's seems pretty pointless from watching people play it over the shoulder.
Isn't this just normal evolution of language? Like how terms like "uppercase" have meaning even though we don't keep letters in cases (most of us anyway!). It's not like every domain extension has to match a game genre, but if, by fluke, it became what happened for "io games" ... That's how words get their meanings. Which is a long way of saying I disagree that it's strange!
It's a specific genre of webgame though, something is or is not an "io game" it's more than where it's hosted, it's more than whether or not it's an HTML5 game or multiplayer.
A genre is precisely a collection of artistic attributes that occur and are repeated mostly as a historical accident (usually after a pioneer explores the space and follow-ups revisit) and are shared among a collection of works -- they are hard to concisely label with precise descriptive terms so their audience seeks a fairly arbitrary label to describe the collection. "io game" seems reasonable enough to me.
Just the same as (made up example) "Up-tempo minor-seventh-key highly-distorted guitar arpeggios with four-on-the-floor beats and legato vocals" gets called "wailcore" or something, the kids playing these aren't going to say "HTML5 games with an emphasis on large counts of concurrent players, with gameplay arising from emergent behavior of players instead of a large investment in story, art, or game mechanics." a hundred times to their peers -- even if they could consciously notice these attributes and articulate them that way.
They'll start saying "you know, it's kinda like agar.io" "I haven't heard of that is it like <whatever>.io?" "Yeah, exactly" suddenly you have a community of players of "io games". I don't really understand how anyone would expect anything else here.
Genre names never are any good. You can't usually distil the detail of what makes a genre into a formula, and you can't distil that formula into a short enough descriptor.
How do you describe a particular genre? The one obvious thing this particular kind of games had in common when they appeared was the .io domain, thus the name.
Go to cursors.io, agar.io and slither.io. Now find a short phrase to describe all three.
Obtuse enough not to realize that a subculture produces its own tropes. If "gg games" acquires enough of an identity, they way io has, then yes, outsiders might start referring to gg games.
I was expecting a post about business side of things, instead it was a post about how to program the game from someone who started without having any idea how it will attract players. Kind of meh. At least you got a good (but expensive) lesson: the game idea and programming is nothing on its own.
The game is well made, but imo the graphics are pretty bland. Find another designer. And why not have a tank 2 or 3 sizes bigger? Also, maybe robots were a better idea, they are new and exciting, they can shoot lasers, crush enemies, who knows. Tanks are a bit boring.
Edit:
And I think it's missing an easy enemy bot, something lower level, so even the newcomer can power up (not crates).
Addendum:
- No explosions when tank is destroyed?
- Movement is very linear, no acceleration or inertia.
- Ramming doesn't inflict any damage.
Not really. If you're doing a multiplayer shooter, solving the lag problem is basic. Otherwise the thing is too annoying to play.
The question is whether you can come up with something more fun than a top-down multiplayer shooter. It's not like there's a shortage of those.
For some reason, the latest fad in indy browser games seems to be parking games. Truck parking. Tank parking. Airplane parking. Crane parking. Maneuvering large vehicles around, slowly. This is at least not warmed-over 1980s console gaming.
Here's a nice piece of work in WebGL.[1] It's quite good visually, but the gameplay is buggy. It also takes minutes to load.
Solving the lag issue is only relevant when you do multiplayer over the network. At which point you are committed to a non-trivial engineering project that will take a few months of work to get off the ground. Prototyping the game idea should be done before committing to such a project.
It would be much easier to get a dozen friends with gamepads to the same room and play around with a prototype game. Just some rectangles and circles running around the screen. About 1000 lines of code at most so changes can be made on the fly. If it's not fun, iterate until it is. The turnaround time for feedback is much faster.
When I read the article I found this to be the biggest shortcoming. Starting work on a half year project with an unproven idea, no market research (playing other games with tanks and steal ideas) and a lot of technical hurdles that don't matter to the final product.
It's important to distinguish between premature optimization and unnecessary or irrelevant optimization. As many others have pointed out, the OP tunneled in on the details of netplay before there was anything to even play. He's doing the steps in a known bad order.
100 ms max lag is maybe OK for human vision, but you need to be down below 25 msecs between action and accompanying audio, or between action and video and audio. The human ear is much more sensitive to the time domain than the eye.
It's doable but hard. A game can be unplayable until the lags are under control, and only then can they become fun and immersive. Assume the game itself has that potential. But don't release until then.
Beyond this, I have no comment about the game itself.
First is 2 months is too long to work on a game. 2-3 weeks max. Make game -> release -> make new game.
Keep them coming. Rovio made 50+. If they'd spent 3 months on each, they'd have drowned.
That problem I think also leads to the rest. Most of which has been said.
Once I made my first app which took me ~1 month, I've pushed times to 1 week. Keep them coming.
Another issue is salivating at the money before you create the user-base. Get the users up first. The money follows them.
Honestly the two finger controls are terrible on mobile though.
I'm somewhat ambidextrous and had a hard time getting the controls to work. A lot of times I'd cross the control area wrong and end up stuck, get shot and die quickly.
You need easier controls. Maybe hold for move, tap for direction fire.
Fundamentally the game is great, smooth, has decent mechanics. I'd play it if the controls felt more natural.
I've been working on something similar for a bit as a hobby, though I haven't updated it in a while it is pretty fun when there are a bunch of players on.
to the developer/creator： i know very little about game development but here is some quick feedback:
1. fix the controls. i'm not sure if i was getting lag, but the tank was moving all over the place and never in a straight line.
2. add sound
3. enhance the graphics. pay someone to make them look really good
Getting 7k visits a day and $130 per month is overall a very good start. 80-90+% of people that attempt something like this either never launch or are getting much less traffic.
The thing that people don't realize is, there are literally hundreds of thousands of games or apps for people to occupy themselves with. No exaggeration. I am including all the different app stores and also the retro gaming. The retro gaming counts because there are plenty of people that play old games through MAME or whatever.
There are only so many famous youtubers driving giant traffic numbers. Not everyone can be friends with them, and so not everyone is going to have wildly popular games.
In terms of this .io stuff, there are hundreds or probably really thousands of other projects to compete with. The most successful ever was NOT particularly clever or new. It was a variation on a very old game. It was well executed but, I believe the main reason it became so popularwas from luck and viral social network effects. Not everyone is going to get those things on the first try.
People very rarely click on ads. Getting $130 per month is something to brag about. Its something to build off of.
Just because something does not become wildly popular does not mean it is a failure. That's just totally unrealistic given the amount of competition out there for people's attention and the tens of millions of dollars being spent to create immersive interactive experiences.
Maybe I shouldn't say this. Maybe I should hope everyone continues comparing their income and views to PewdiePie or whoever. That will make for less competition for me.
Here is what I think the dev should take away from this. They have done a great job of solving these hard networking issues. They have people coming to visit their game. Keep trying to promote it and adding small bits of functionality or whatever. Keep trying to get famous youtubers to visit. But that is the side task you work on for an hour or two every week.
The main new side task is taking this awesome engine you have built and creating a new variation. It might look like a totally different game. Or be similar. The point is this time you have more time to focus on marketing and content and other things.
If you can get it down to release a new game every 3 months and not get even a tiny bit more traction from them than that project --
- months 0 - 3 $130 per month
- months 3 - 6 $260 per month
- months 6 - 9 $390
...
- end of year 5 $3120 per month
It might take 5 years to build a successful business. Not everyone is an overnight success. But I am happy if most people want to give up after 6 months. Makes for less competition for me.
It's not a matter of giving up, it's a calculated choice.
True, the path you described is good, and if I wouldn't have any other options, I would gladly take it. However, I do have other options, and they are more effective, so I decided to go back and focus on them. Doing games at that low margin can't beat those options. Also, it would be a complete change of career path, a quite risky move.
As a recruiter, I get a fairly regular flow of job applications from people who have had a go at making money from games and decided they need to go back to jobs that pay a salary.
Well, congrats on creating and publishing your game! That alone is far further than most people get, and you should be proud of your work.
Good job on the coding side of things too. I'm not exactly an expert programmer myself, but it seems like you found some good solutions to the problems you were having with lag and what not there too. As you say yourself, they're all things you can learn from and reuse in future projects.
However, as for the game itself... I can see why it didn't quite catch on.
It's probably not the idea itself being terrible, because I feel the main game concept seems decent enough. Is it original? No of course not. It's been absolutely done to death a million times in the past, with tank fighting games being a long standing part of the medium.
But it's an idea than anyone can grasp really easily. So the potential for going viral was certainly there.
The issue was in how the game was presented and how it was marketed. For example, as much as your designer did their best, it just doesn't look very interesting as far as the art style goes. Really, it's the same old generic style I've seen in dozens of app store games nowadays. The kind that looks like it's trying to mimic the style of a Mac OS icon and not quite succeeding.
And that likely put people off. Remember, they've seen hundreds of games that look vaguely like this one. So they skipped your one thinking it just wasn't interesting enough to bother with.
So that's the first problem you had with the title. You picked a very generic looking art style, and used it with a game whose core designs had done a million times before. It just didn't stand out.
The second problem you had was marketing. Put simply, telling a few websites and setting up a social media account or two doesn't work nowadays. Seriously, unless your game is some amazing viral hit that blows up like Minecraft or Five Nights at Freddy's, you can't just rely on the whole 'build it and they'll come' philosophy.
No, what you needed to do was market the thing to YouTubers and other influencers. That's because those people have tens or hundreds of thousands of subscribers interested in the games they play, and usually in turn end up inspiring other people online to cover said games. Tons and tons of previously unknown indie projects have succeeded because they were lucky enough to have PewDiePie or the likes pick them up.
Hence you should have contacted these people (including some of the smaller channels) and tried to get them to do a video about your game. That's how a game tends to go viral now. Someone who's popular online plays it and says how great it is, and then their legions of fans and imitators give it a go afterwards.
That's just my opinion on the matter anyway. Feel you could have made the game look a bit more distinct and marketed it via YouTube influencers rather than just 'new IO game' listing websites.
Actually, we figured the Youtubers thing pretty quickly, I just didn't emphasize this stage in the blog. We did try to reach out to them for about a month. With no luck. Only one more or less famous Youtuber posted a video about the game. Another one agreed to take our money and posted a video. Others just didn't respond. I don't know how others manage to market to Youtubers.
Your product is unremarkable, in the strictest sense of the word. That's your issue. What might one say about it that would be provocative or interesting to one's fans and subscribers?
You can tackle this issue with a re-skin. The other issue is your control scheme. You need to make it configurable and you need to iterate on it until it is fluid.
Here is a quick example of how a re-skin might work. You contract an artist to make Halloween-based art. Pumpkins and witches etc.. You re-skin the game and market it as a Halloween shoot-em-up. You get seasonal income.
Same engine, different graphics for Christmas.
You've created a digital asset, albeit a flawed one. Kudos for that milestone but you've essentially stopped at the 90% done and written a postmortem.
Finish the job or at least recognize that you ran out of steam short of the goal line.
- Bottom line, the game is not particularly fun, novel, or difficult. You'll notice that games like Flappy Bird, Agar.io, Papers Please, etc. are at least one of the three. Bist.io is not the type of game that will ever go viral.
- You spent money on AdWords but didn't spend money on sponsored Youtube, Instagram, or Twitch content? To me, this just shows a fundamental disconnect with your target audience (gamers).
- You should never polish a multi-player game until extensive play-testing. Single player games are a bit different, but with multiplayer games it's the mechanics that sell it. If the mechanics aren't fun, polish doesn't matter. Case in point: H1Z1 and PUBG. Awfully optimized, and generally terrible lag, but still massively fun and massively successful.
- Too much premature optimization. Having your servers blow up is a good thing. Don't worry about preventing the blow up until you get there. In other words, you spent too much time on load balancing, etc. This is the canonical reason good engineers make bad business decisions.
Going into something (even games) to make the big bucks is perfectly fine, imo, but, in short, your game just isn't very good and you have no idea who your audience is. You added "social" buttons because it's the "thing you're supposed to do" but omitted Twitch and Steam? You're not on IndieDB or TIGSource?