How I tried to get into game development and failed
enterprisecraftsmanship.com
enterprisecraftsmanship.com
- 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?
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.
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!
It shows an iterative development model, focusing on gameplay features step by step. The big take away "focus on making the character do something":
http://www.gamasutra.com/blogs/TommyRefenes/20130107/184432/...
There can be only one!
Anyhow, glad you liked it! I still regularly get email about Empire 40 years later.
The key though is that I have a steady job so I have the free time to work on it without worrying about funding.
That is on the 2nd part of the presentation, because he had some issues initially.
EDIT: Here is the Empire demo, https://www.youtube.com/watch?v=vjaKFTHQSxQ&index=4
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.
1. Something you'd *love* to play
2. Prototype: are you right?
3. is it feasible (for you) to make?
4. is it worth it?
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.
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.
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 is a common problem to look at what successes do, and ignore what failures don't. See the Watson selection task[0]
'virality' is a very ... particular thing to be clinging to. many things 'go viral' then fall off a cliff.
Everyone wants to be the guy who wrote Flappy Bird in a weekend, and then wound up making so much money so fast that it actually scared him.
And there are those unlucky ones who always find what they need done by others... :(
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.
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 all over. 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.)
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$.
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.
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.
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.
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.
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.
Cash flow can solve many, many problems.
This is pretty likely to share code.
> Madden YYYY+1
This may or may not.
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.
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 :).
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.
At some point, you have to question whether the 'real' game is going to be delivered!
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.
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.
(This problem may very well be addressed later in the post, still working my way through it. It's an interesting article.)
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'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.
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.
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.
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 what you are arguing is for people to just be honest with themselves.
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?
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.
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.
Dealing with the lag is part of the MVP, not polish.
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.
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!
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.
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 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.
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.
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.
Not to start with the development stack…
[1] The Art of Game Design, by Jesse Schell
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.
No sound. Really that kills it right there.
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.
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.)
I mean right now this thing doesn't even have a NAME that means anything, much less any kind of visual appeal.
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.
A more apt title: "A story about how I tried to get into game development and didn't finish yet"
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.
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.
Is TagPro a "gg game" now, because they use the "gg" domain for their main site? I mean, how obtuse can we get..
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.
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.
Also it's just a bad name in general, since those style games can be hosted anywhere.
"Rock" for instance.
And what about now after its success? Did it provide enough income to pursue whatever you want full time?
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.
:)
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.If anyone here is curious about game development, go do Ludum Dare 39; it starts in 10 minutes as a matter of fact!
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.
Heavy Truck Parking.[2]
There are lots more.
[1] http://www.y8.com/games/airplane_parking_academy_3d [2] http://www.unity-3dgames.net/3d-car-games/Heavy-Truck-Parkin...
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.
Ports of Call springs to mind immediately. But that was Amiga gaming, always a bit more sophisticated than consoles.
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.
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 think that getting the controls right is what will matter the most in the end. Until then the game will go no where.
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.
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.
Sad but true.
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.
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.