<strikethrough>Well, yes. Because mobile is such a walled garden of anticompetitive language and platform wars, it's hard to write portable applications. They eventually came round to Unity, which has a cost, but does let you deliver to all the platforms.</strikethrough>
Besides, it's only 2D tower defence. The artwork probably took longer than the game, and at least that's portable.
Then there's the question of which platform is most profitable. I've heard that the profitability order is iOS > Android > Web > PC for this kind of game. Maybe others have experience of this.
Edit: well, I guess there's no quicker way to get correct information than to post incorrect information!
C works just fine on all of the (non-web) platforms you mentioned. It might be a little long in the tooth for some, but it still gets the job done.
In my spare time by myself in the last 4 years I have built a complete cross platform engine from scratch for Desktop and Mobile. If one person can do it their spare time in 4 years, a couple of programmers working full time could do it a lot more quickly (I also deliberately reinvented the wheel in a lot of places I did not need to).
We have a game written in C++ that compiles to, and runs on Wii/WiiU/PS3/PS4/X360/XOne. Every one of those uses a different compiler, but all build from one IDE(VS2012). But then it was built by close to a hundred people,so it's not really the same.
Oh yeah, of course there are big engines that also do that (with much more platform support), I was just using my own experience as an example to show that you don't even need a huge team supporting it. I remember back in the day working on a PC/Wii/X360/PS3 engine, that was fun but definitely a lot more effort.
I develop with GCC rather than VS, but I have much the same setup with a single makefile that can build for different targets instantly, e.g.
> make (for PC)
> make android (builds and deploys to a connected android device)
There's this thing called C++ which happens to work on all mobile platforms. I could understand having difficulty making a cross-platform app that needs deep OS integration but a game is the very definition of cross-platform.
C++ also happens to be the quasi standard language of game development. Even the typical scripting languages (Lua, JavaScript) are supported on the major platforms.
If they settled on Unity, why not make a PC version? It shouldn't involve ground-up rebuilding of everything. In fact, they've already targeted the most restrictive environment, so it's relatively downhill to produce. They could easily get it on to the Playstation and Xbox platforms as well.
"We never had a Unity port for Frontiers. Origins is coded in cocos2d, like all the other KR games. By the time Unity became known to us, we gave it a try with the Steam version of Kingdom Rush. This was mid 2013... Frontiers was almost ready by then.
Early 2014 we started working on Origins and we used the old engine out, sine the effort of adapting the old games to new platforms wasn't exactly good to us.
Origins is the last game that will use our old and loyal cocos2d engine. As we define what our next game will be, we are very much aware that it must be multi-platform."
Not really. Going from Mobile back to PC is very very easy (PC to Mobile is another story). If your game already works on mobile, it will 99.9% work on PC. The amount of platform specific Unity bugs is actually quite small, in my experience. Especially with 2D games that aren't using crazy shaders (in my experience, most of the platform specific bugs are GPU shader crashes, especially on Android. And again, that's only on Android. PC has far less buggy GPU drivers than Android).
You might need to adjust some screens so they work better with a mouse instead of with taps, but this game doesn't use multi-touch or anything that can't be done with a mouse so I don't see an issue with that.
You also need to write platform specific IAP and notification code, but again, going to desktop you won't have notifications, and writing platform specific IAP code is not that big of a deal, especially compared to porting your entire game.
Short story is, these guys chose their engine very poorly. They had already experienced cross platform issues in the past, and seems like they just decided to ignore them until it was too late.
I found a bug in Unity which happens on Linux on XFS partitions larger than 1 TB. Such kind of bugs are clearly system specific and hard to debug / support unless you have that configuration set up. Responsible developers take obligation to support their product. If someone intends to produce something and forget about their users - that's close to garbage.
In my case I bought one game and was hit by this bug. I contacted developers with strace data and got no response. Then I contacted Unity developers and they actually got back to me and confirmed that it's indeed the case with large XFS partitions (they had to set up that test case to verify it). They produced a custom build of Unity player of the same version with patch backported, and I was able to run the game.
Now, those game developers obviously don't care about supporting such cases, yet they sell the Linux version. I don't appreciate it on one hand, on the other hand may be it's better than not having that version at all. But I can see a point of some being exhausted and trying to avoid bug reports for systems that they can't properly support.
That's unfortunate that the game developers did not get back to you. They should have at least given you a response. There is no excuse for that.
The proper response from a Unity game developer who wants to sell a Linux version but not support it is pretty simple- just offer refunds for anyone who has problems. 0 work and problem solved.
Also, good Unity developers know there are platform specific issues (and how to solve them). I'm not saying platform specific bugs don't exist. They're just rare. When they happen, post on the Unity forums or Unity Answers site. Unity employees will read it, and get back to you. The support is great. This is why you use Unity. Let Unity do this work for you!
Origins is another Kingdom Rush and being made with the same base mobile engine we allways used, not Unity. It will be released for iOS and Android probably at the same time [0]
They wrote Kingdom Rush first in flash, then ported it to iOS, then ported it to their own proprietary mobile engine that's portable across iOS and Android. Earlier this year, they also ported it to Unity.
This blog post is talking about their newest title, Kingdom Rush: Origins, which isn't built on Unity but still on their own proprietary mobile engine.
Game co's often hire out the porting, so they can still exploit a platform without splitting their focus. Aspyr has made a living porting popular games to the mac.
This seems potentially very shortsighted, as difficult as it must be to measure exactly how much of their success on mobile was due to the free advertising on Armor Games, in and out of game.
As an anecdotal data point, I own the last few versions of the Kingdom Rush game on iOS, and I'd never even realized that they had a flash version until I read this post.
Do you recall how you found the first version that you purchased? What I'm wondering is if the free marketing on sites like Armor Games was a key part of the initial push to be discoverable on the app store rankings. Of course, the existing mobile user base may all the captive audience they need to accomplish that at this point.
This was a few years ago at this point, so my memory is fuzzy. I have a sense that I may have seen someone reviewing it (the iOS app specifically) and decided that it sounded appealing.
I looked into 2D engines for iOS a couple of years ago and I remember reading on one of their websites that I shouldn't worry about porting to other platforms before the game has reached popularity. The context was probably Android and not PC, but still, this seems to be exactly what was going wrong here. If they would have chosen Unity (or any other cross-platform engine for that matter, e.g., Cocos2D-X) over Cocos2D-iPhone, there would be a PC version today.
This seems to be a bit of a recurring thing where we evaluate technologies wrong very early and punish ourselves in the long run. The fact that Twitter once was a Rails app comes to mind.
I can't recommend enough to write software for the best case scenario. You shouldn't have to replace your entire toolchain once the thing you dreamt about happening actually happens.
I kind of agree with their original thought, if the game can't succeed on one large platform then being portable is irrelevant. If it does succeed then porting is an additional cost but it's a cost you can weigh up and choose to do or not do, you have the choice. That seems like a better option than over encumbering yourself to begin with by adding in effect a bunch of additional cross platform requirements.
Hindsight is 20/20. It was 2011 when they ported the Flash version to iOS, so Cocos2D-X had just been forked and Unity had just released its Android version. Cocos2D was what all the hit games were using at the time.
The game's popular enough that Activision did them the honor of cloning them for their recent Duck Dynasty game, so it's hard to say they screwed up that badly.
Another way to look at it is that the requirements changed. When the requirement is multiplatform then you pick the best multiplatform solution, when the requirement is simply the best engine for a single platform, that's a totally different requirement.
It's not that the picked the wrong tool for the job, it's that the job changed.
I want to reply to all three of you, so I'm just gonna do it like that.
sehugg kind of got a point, but I think there were really good cross-platform solutions available back then. Just not the ones used today. Marmalade has been around for a quite while and it was/is used by a lot of big studios.
The other two comments I don't agree with.
> It's not that the picked the wrong tool for the job, it's that the job changed.
If your tool can't adapt to new requirements an argument can be made that you did in fact pick the wrong tool in the first place. That's my point exactly.
> That seems like a better option than over encumbering yourself to begin with by adding in effect a bunch of additional cross platform requirements.
I think this is a bit of an exaggeration. They don't write their own engine, so the overhead for going cross-platform is really, really small — so small that I have a hard time coming up with examples right now. Not hard coding screen sizes and that kind of thing might be one, but that's about it. There's also some irony in saying that's the better option given the blog post we're talking about.
Weird. They should be sitting now on a wealth of experience to allow them to write the next version in a more-or-less portable fashion.
My guess would be that the actual reason might be the lack of reliable distribution channels and/or rampant piracy. Though there is Steam, which seems to work just fine for a lot of game devs...
Trying to be the 102nd competitor. That's tough. I can see the disinterest. Can you split a very old market 102 ways while making a profit? Frankly, probably not.
In theory KR is a TD game. In practice though most of TD games is such a crap that Kingdom Rush pretty much sits in its own category. They should have no problem whatsoever getting to the top spot on Steam.
Kingdom Rush is totally separate calibre of Game. I've played probably 20-30 Tower Defense games, and KR keeps you coming back because of the incredible attention to quality, details, balanced game play, etc...
Do these games have a large following? I tried to play one once and found it to be a pretty typical "You've played a few levels, now you have to pay to win."
Definitely not necessary to pay to play these games. Makes it easier, sure, but they don't have timers or super high difficulty spikes to overcome, except maybe the last level.
That wasn't the case with the flash version, I never paid a nickel and completed most of the challenges and the game. I recently bought Frontiers for Android and while the game has "heroes" and "gems" for sale, I havent had to buy anything to beat levels.
Definitely not the case. I have played through all the Kingdom Rush games, fully and doing all the bonus objectives, without spending a dime beyond the initial purchase. I had a great time too, and I have a pretty low tolerance for grind. I think the KR games are exceptionally well designed in this regard.
This game is definitely not pay to win. In my opinion, the challenge level is perfect. With a bit of practice, you should be able to beat every level. Then, going back and 3 starring every level will take more skill and practice and maybe some light item usage (which you can earn via playing, since you only need to use them occasionally).
If someone is really that bad at the game that they can't even win without using a ton of items per level, then yes, it's pay to win. But if it wasn't pay to win, they would just be stuck and couldn't play at all.
The game isn't freemium either, and it's not designed to be pay to win (I'm a successful freemium game developer).
> Do these games have a large following?
It's widely considered to be one of the best tower defense games on iOS.
This is why I am such a advocate of Unity, I know it didn't work out for them, but if you stage it right you can easily port to about anything worth porting to. I tend to start out with Desktop since it has the highest curve for quality and performance, and go from there.
The great thing is that there are a ton of good cross-platform options available now, not just Unity. From commercial alternatives like UE4 to solid open-source libraries like SDL2, or just using OpenGL ES.
If you have even the slightest inclination to release on multiple platforms, you should be building it as cross-platform from the beginning. There are very few reasons not to.
I've heard this a lot in the games industry -- "For each version, the programming was done from zero. We can’t stress this enough."
That seems so wasteful and challenging, anyone from the industry care to comment on how a studio would get itself into a situation of effectively zero reuse of their code?
The main issue is a lack of money/long-term survivability for most studios, which leads them to cut many corners in order to release the game before running out of cash. This means that code is written to ship the game out of the door, rather than for the future, so there often isn't time for proper engineering. Then if that game does OK they get to work on the next one, throw away all the hacks they did last time, and start again...
It also doesn't help that due to the structure of the industry (e.g. work hours, low pay etc.) they have trouble retaining developers and instead replace them with fresh grads. A huge percentage of people I know left the industry before they hit 30 (myself included). This leads to a lack of experienced engineers.
I'm going to preface this post with a note that, yes, there are surely good developers in game development, this is not a universal thing, etcetera etcetera.
Ass properly covered, I'll be real: I'm never surprised to see this because "code reuse" is generally the sign of reasonably advanced developers and I don't know a single person in game development I would hire for a role outside of it. It's not just NIH--that's a problem but one slowly going away. It's more just a fundamental lack of understanding of software engineering and building Good Code. As time goes on I've seen gamedev acquaintances poorly reinvent most of the wheels that the rest of the world takes for granted--even something as simple as serialization for save data and network transport (but no schematic validation, because "schemas suck") was trumpeted to me as this Big Crazy Great Thing. Which contextually it may be, but I kind of feel like the state of the art for stuff not involving pointer munging is about a decade behind everybody else.
Well there's a difference between code reuse, and cross-platform code reuse. If you're porting a Laravel project to Rails or vice versa, you should be reusing logic, not code.
I worked in the gaming industry for a couple of years and after I worked in the RTB industry and lately in the forex industry. I am not alone, and I have a lot of friends coming out of gaming that work very well in other industries.
The problem is not whether or not game developers know how to reuse code but whether or not it makes sense or are allowed to reuse it. One big challenge when you are going to reuse code is not having a stable set of requirements (which in gaming is almost non existing even in the late stage of a project) and when you take that and join it with tight and unreasonable schedules you would have a huge mess as result.
The state of the industry is very unhealthy in my opinion and I wouldn't be surprise if there is another dark age for videogames coming up.
I agree with what you said with my limited experience. I hope it's anecdotal nature is good enough.
I worked in a company that went from doing software gigs in general to be full mobile gaming company. Before it was quite standard Agile style company: Scrum, code reviews, TDD, cross-functional teams (front end devs knew how servers works in general), focus on quality over quantity (one dev, rotated weekly or biweekly, focusing on fixing bugs), separate concerns.
After going full game-oriented, company hired couple of people from gaming industry into higher positions - tech leads, project managers etc. Over couple of months, people with many years of experience in those big companies dismantled what was standard for me, using combination of two arguments:
- big names don't do it, so it must be wrong
- it's a waste of time
Before I quit, there were no longer code reviews (waste of time), all testing was to be handled by QA team (waste of valuable dev time), ship with issues (waste of time to fix minor bugs when can add features), single system responsibility (one dev to write code for client server protocols, one dev for UI, one dev for assets etc, that's gow big names do it).
At one of the last talks with "industry veteran", when I mentioned those things - and how negative, in my opinion, those changes are, his response was "so you are saying that whole gaming industry dev practice is wrong". At that point I thought he's right and I sound full of crap, now I believe that yes, AAA companies are simply bad development practises shops.
My guess as to why is because AAA is very strongly driven by deadlines and marketing, where you cannot simply delay release (Christmas shopping spree is coming). This idea I saw articulated on HN first and I agree with it.
If the AAA practices had been so bad then, by now, we had Agile-TDD-etc shops taking their lunch and driving them out of business. As of now there is just one studio practicing Agile, Blizzard. If it is not known, Blizzard is also famous for incredibly long projects and missing deadlines. I had personally observed collapse of two Agile AAA studios, who, while doing pretty well by the industry standards, did not have the super-profitable titles to hold them up during 5+ years of development cycle. So I believe we have the AAA practices not because game programmers are stupid but because studios that don't use them are not around for long.
The answer is fairly simple here, is that software quality is not everything in this space. The systems are not mission critical, and PR, marketing, money and a good "property" (eg: star wars) can pave over quality issues.
For example, look at Assassin's Creed - will the bad launch cause people to avoid AC in the future? Maybe, but probably not.
there isn't any reason to suspect that a small company doing one thing better will walk all over AAA, that's hyperbole. AAA's culture is good enough and their other large advantages give them their market share.
What are the advantages AAA studios have? There are no patents or secret know-hows, there is only reputation they have built themselves. If you have a superior process why cannot you do the same? For example, a small company id Software started developing games in C when everyone else had been doing Assembler and pretty soon not just established itself as a AAA studio but effected everyone else to switch to C as well. This is how a superior process works in the games industry.
Shitloads of money. Massive institutional knowledge of public relations and marketing. Direct lines to Sony and Microsoft. Every kind of benefit of economy of scale you could want.
You seem to be confusing publishers and studios. If you are so good with development practices you can sign the same contract other AAA studios do and get the same access to the benefits of economy of scale you attributed to studios.
Um. Publishers own the majority of these studios (or they self-publish, generally after a spinoff or long working relationship under a publisher). That's why those advantages apply to them. Otherwise, how exactly do you propose to "sign the same contract" without having money in the first place to build the infrastructure and already having spent a shitload of money to be in a position to be considered for it?
It's not like the idea of a barrier to entry is a new concept.
Some studios are owned by publishers, some are not. The statement I argued was made about every AAA studio, BTW. But if you cannot compete with a publisher owned studio then go after ones that are independant like Epic or Bungie or Insomniac or Arena or Telltale or Riot etc. etc. If you want how it's done look no further than Respawn. The studio was just founded in 2010 , signed a publishing contract without long relationship with the publisher and infrastructure, shipped a game already. It is how almost every AAA studio started (there are few studios that had been seeded by publishers, but as far as I know, none if them exist now).
It's pure meritocracy here, if you are good then getting a publishing deal is not a problem.
So you have a list of studios that all either got big when the barriers to entry were much, much lower than they are now (Insomniac did not spend a hundred million dollars on Spyro the frigging Dragon) or were founded by people with significant industry contacts and kicked off with direct lines to Sony and Microsoft and to publishers right in hand because of who they are? Are you sure you're proving what you think you're proving?
The core of an "AAA studio" is a big fat wallet. It's essentially definitional. You're not actually saying anything with respect to them in any of your posts.
So who were Riot's founders? Who were Media Molecule founders? Did the barriers for entry suddenly rise between 2008 and now? From what I see it's much easier to publish a game even for consoles. There are tons of indies doing that regularly. In 2008 you had to have a secured office and 20K in cache to get a devkit, today you can get a loaner at home if you cannot manage 2K price.
AAA do get a lot of money but it's the effect of them making games that sell well. There are dozens of startups in SF that cannot make even mobile games with their piles of cash and hundreds people. Money do not make you a AAA studio.
I was not implying that game programmers are stupid, sorry. I meant that they way it was told in the company how AAA do it sounded similar to what I learned about how big companies done it 10 or something years ago. Coming from agile workplace, I think there were things that could have been kept in place to improve quality of life for developers and art teams. I'm not sure if I can express what I mean correctly. For example, why the dreaded "crunch time" in gaming is treated as norm, while in modern web/mobile shops its believed that something like this is going to result in worse quality over time?
I could see arguing here with myself that AAA games are usually "ship and forget", with some bugfixes only. Maybe because company I was working in was not AAA, but small (by industry standards) f2p mobile shop, where applying AAA ideas is not that great (in my opinion). I mean that's where your product is more along lines of web apps - you are going to constantly add content, update code base, refine features, so focusing on quality in long term is better. This, thought, I was not able to articulate clearly and properly to AAA veterans.
I feel like not all ideas from current practises can be applied to big gaming studios, but saying that I believe it can be improved. This may need time and risk that companies that are big enough to be called AAA are not willing to take.
Why two companies you mentioned failed? I think we can assume there might be more reasons to that than only being Agile, maybe their games were just not that good, or IP was boring? Still you sound like you have more experience than me here, I'm trying to wrap my head around whole AAA industry thing. I'm ranting about it so much because making games was way more entertaining than web/mobile, but the industry is so poisonous for pure developers that I had to quit to regain my sanity :)
I am not sure people outside game industry do not crunch. A brief search shows that the term existed long before the modern game industry or any game industry at all. Same goes for "overtime" - the term is even codified in laws. I assure you nobody treats crunch as a normal mode: even people who are forcing unnecessary crunch understand that it's something unordinary and often do it just because it is not something normal (to show how good they are at management, to extort a bigger budget, to undermine their political rivals etc).
>This may need time and risk that companies that are big enough to be called AAA are not willing to take.
Infinity Ward, the original home of $1B+ games, had about 100 people at the time of the split from ATVI and founding Respawn. It's about the same size now as well as the Respawn. Media Molecule is just a few dozens. Size does not make a AAA studio.
And you don't even need to show the best practices right at the AAA level - start small and if it's any good people will copy you or, at least, you should be able to grow yourself.
>Why two companies you mentioned failed?
>I think we can assume there might be more reasons to that than only being Agile
Indeed, it would be naive to blame Agile on destroying multi-million businesses. Agile seems to be just a symptom. It could be that the management sees that the development process is failing and tries to improve it with a well advertised technique, for example. Or that some Agile enthusiast gets too much power due to the weakened culture. What I was trying to say is that very few AAA studios practice it now and the ones that did in the past are not in the business any more.
Also, there is no single AAA development way. For example, Valve's practices are very different from Bungie's, which are different from the R*, which are different from ATVI's COD teams etc.
This seems unsurprising, given the game industry's notorious reputation for developer burnout. The developers don't know how to write good code because by the time they've learned they've burned out and left the industry. They're then replaced by clueless young people, and the cycle repeats.
Almost all the graphics, audio, net, event, ui, system calls and data structures are generally tied to the low level frameworks without any level of virtualization.
Add to that that each framework has its own standard and way of doing games (event-base, component-base, etc.). The worse part I think is the game logic is generally enclosed in framework-specific objects like events in as3, components in unity, etc.
Virtualizing that would be expensive, tricky and costy in terms of performance.
The problem is not that the Flash game is so tightly coupled to the hardware, it's that it is tightly coupled to the Flash runtime. (Mainly because Flash forces a certain structure on your code, but also because Flash's idiosyncracies are so bad that you have to bend over backwards to get good performance from it.)
In the way back times, when the Amiga was a hot machine, I hung out with folks who were games people and they were always trying get one more erg of power out of the machine because, as they put it, "Every cpu cycle spent on the game makes it that much better." Which was clearly true in the Amiga, and the PC/AT and Macintosh II, but for a modern machine with 4 cores and 8GB of memory and a GPU that fills a 1080p screen with triangles almost without thinking about it. It seems like 'bare metal' is suddenly a hindrance and 'moving to multiple platforms with minimal rewrite' would be the thing evolution would push into game studios. Where did that message get lost?
The difference between engine optimized for certain platform is simply massive. We're talking at in the worst case 10x the performance difference.
Why is this? Let's take modern console game for PS4. It uses mantle like API where you can simply spam drawcalls like no tomorrow. Port that to DX11/OpenGL and you'll choke.
Or move a simple OpenGL game from PC to mobile, it does nothing fancy and uses ES2.0 subset of OpenGL so it should work nicely? Not quite. All your scenes are built using effects that cause massive performance penalty in tile based renderers. Sure it works fine on Tegra K1 but everywhere else it's horrible.
On the other hand there is a way of doing multiplatform development. It means using Unity (or other multiplatform engine), limiting yourself to a common subset and leaving the optimization part to be the headache of the engine developers. However even if you use Unity you have to manually consider the effects you are using on per platform basis.
> 'moving to multiple platforms with minimal rewrite'. Where did that message get lost?
After the Amiga/Atari/Commodore/etc era when games were ported on every platforms came the PC age (which was relatively divided from the consoles during a long time). Now heavy crossplatform is back again.
The game industry grew up in the 80's where the only suitable language to write games on was Assembly and everything computer was completely different, even between revisions.
Basic, C and Pascal were the Python and Ruby back then.
So porting studios appeared, specializing in porting the games to specific platforms. The porting industry came to life.
Fast forward 30 years, you still need to write quite hardware specific code if you wish to squeeze out every possible ms out of the machine, which opens the door for all kinds of shortcuts.
Let's say it's 2011 and you want to port your Flash game to iPhone. You can try packaging your Flash game using Adobe's tools, but it'll probably be very slow, and Apple might change their mind again about allowing Flash apps on the platform. There aren't very many well-supported C/C++ frameworks for iPhone yet -- you search the forums for each and only find unanswered questions. You're worried about it working well on the new iPad.
So you do the safe thing everyone else is doing, Cocos2D and Objective C. You'll worry about porting later, if the game does well. Maybe you'll just pay someone else to do it.
I'm going to paraphrase a friend of mine who is a great mobile developer.
They could have used AIR on mobile to re-use the AS3 codebase. Alternately, they could have done c++ on cocos2d-x instead of objective c, so that would have been pc portable.
They would just have to write it twice, in that case. However, if you are a group of AS3 devs jumping to mobile, they probably picked the best sounding thing at the time - which was cocos2d.
Keep in mind android wasn't really a game platform in 2011, so choosing cocos2d in obj-c over c++ wasn't really a bad call.
While I think it's sad that PC support is finished I certainly get their point about feeling exhausted.
On the other hand, the use of bold and non-bold was driving me nuts. I feel it's up to the reader to decide what is important in the text, not the making of certain sections of bold, it was hard for me to read.
After awhile, as I wanted to read the whole thing, I copied into a text editor to read.
100% Agreed. They had already been bitten by cross platform issues in the past, and instead of deciding to address them and choose a cross platform game engine for their new game, they just ignored them.
Short story is, they chose their engine poorly, and are now making excuses. Very disingenuous blog post.
To me this post reads as "We were really surprised by our success and have been running in circles." They've foolishly made a ton of versions instead of learning how to write cross-platform or at the very least how to port from the beginning. Crazy.
Meh. I always assumed mobile game companies ported to PCs just to squeeze more product out of their creation. You might as well complain about your favorite Game Boy game not being ported to the SNES (with 4 shades of olive green graphics).
I do wonder why more people don't make use of a C physics engine (portable everywhere, including browsers via asm.js), and code the logic in a higher level language which can compile down to C (like Python via Cython.)
I guess the problem is that you need different rendering code? OpenGL works on PC and mobile, but you'd need to mock it out for WebGL. Has someone already done this for asm.js?
Presumably there is some other huge hole in my thinking...
Haxe looks really cool, but the last time I looked at it, the documentation left a lot to be desired (most of it assumed familiarity with the Flash drawing APIs).
It does look like the situation has improved since then, but I'm guessing that documentation is a big reason for Haxe being so underappreciated.
I've never played Kingdom Rush, et al, but I've read reviews of some games that were ported to the PC and the keyboard / mouse control were almost unplayable.
I don't think that's the whole story. Most likely the numbers just don't add up for IAP-less Steam versions. Kingdom Rush Steam sells for $9.99 (and was available for less if you pre-ordered). I don't know about Origins, but Frontiers has obscene IAP price-wise. Purchasing all heroes costs $40 or so, plus there is always the opportunity to buy gems for items which make it easier to progress. (Gems also accumulate as you beat levels). In fairness, this is all optional and you can beat the game without it. They kept adding increasingly difficult post-game levels though, which no doubt have tempted many to buy stronger heroes.
PS. I think they should fix the bugs in KR Steam first anyway, which was pretty much abandoned.
I've completed everything in Frontiers, mostly through Origins. It's a lot of fun (after settlers, my most favorite iPad game) - and it never even occurred to me to do an IAP.
I like the Kingdom Rush games a lot, and wish Ironhide Games nothing but further success.
That being said, this letter is cloying. A letter where you tell someone you care about that you don't have it in you to be with them isn't a love letter, it's a "Dear John" letter (http://en.wikipedia.org/wiki/Dear_John_letter). For the recipient, those two types of letter are very different!
It would have been 100% fine to just say "look, it would take a huge effort to bring Origins to PC, and we don't have the money or the energy for that." There's no need to dress it up in shiny happy "we love PC!" platitudes.
102 comments
[ 2.5 ms ] story [ 321 ms ] thread> In three years we had made five versions of our two games. For each version, the programming was done from zero.
Besides, it's only 2D tower defence. The artwork probably took longer than the game, and at least that's portable.
Then there's the question of which platform is most profitable. I've heard that the profitability order is iOS > Android > Web > PC for this kind of game. Maybe others have experience of this.
Edit: well, I guess there's no quicker way to get correct information than to post incorrect information!
In my spare time by myself in the last 4 years I have built a complete cross platform engine from scratch for Desktop and Mobile. If one person can do it their spare time in 4 years, a couple of programmers working full time could do it a lot more quickly (I also deliberately reinvented the wheel in a lot of places I did not need to).
I develop with GCC rather than VS, but I have much the same setup with a single makefile that can build for different targets instantly, e.g.
> make (for PC) > make android (builds and deploys to a connected android device)
There are way better criticisms of Xamarin than the price.
EDIT: Here's what they are saying about Unity:
"We never had a Unity port for Frontiers. Origins is coded in cocos2d, like all the other KR games. By the time Unity became known to us, we gave it a try with the Steam version of Kingdom Rush. This was mid 2013... Frontiers was almost ready by then. Early 2014 we started working on Origins and we used the old engine out, sine the effort of adapting the old games to new platforms wasn't exactly good to us. Origins is the last game that will use our old and loyal cocos2d engine. As we define what our next game will be, we are very much aware that it must be multi-platform."
I guess they are too exhausted at this point. Even with Unity there are bugs specific to each platform and supporting that takes time.
You might need to adjust some screens so they work better with a mouse instead of with taps, but this game doesn't use multi-touch or anything that can't be done with a mouse so I don't see an issue with that.
You also need to write platform specific IAP and notification code, but again, going to desktop you won't have notifications, and writing platform specific IAP code is not that big of a deal, especially compared to porting your entire game.
Short story is, these guys chose their engine very poorly. They had already experienced cross platform issues in the past, and seems like they just decided to ignore them until it was too late.
I have no sympathy.
In my case I bought one game and was hit by this bug. I contacted developers with strace data and got no response. Then I contacted Unity developers and they actually got back to me and confirmed that it's indeed the case with large XFS partitions (they had to set up that test case to verify it). They produced a custom build of Unity player of the same version with patch backported, and I was able to run the game.
Now, those game developers obviously don't care about supporting such cases, yet they sell the Linux version. I don't appreciate it on one hand, on the other hand may be it's better than not having that version at all. But I can see a point of some being exhausted and trying to avoid bug reports for systems that they can't properly support.
The proper response from a Unity game developer who wants to sell a Linux version but not support it is pretty simple- just offer refunds for anyone who has problems. 0 work and problem solved.
Also, good Unity developers know there are platform specific issues (and how to solve them). I'm not saying platform specific bugs don't exist. They're just rare. When they happen, post on the Unity forums or Unity Answers site. Unity employees will read it, and get back to you. The support is great. This is why you use Unity. Let Unity do this work for you!
They wrote Kingdom Rush first in flash, then ported it to iOS, then ported it to their own proprietary mobile engine that's portable across iOS and Android. Earlier this year, they also ported it to Unity.
This blog post is talking about their newest title, Kingdom Rush: Origins, which isn't built on Unity but still on their own proprietary mobile engine.
[0] http://www.ironhidegames.com/forums/viewtopic.php?f=5&t=5950...
(At least, that's how it sounds to me.)
This seems to be a bit of a recurring thing where we evaluate technologies wrong very early and punish ourselves in the long run. The fact that Twitter once was a Rails app comes to mind.
I can't recommend enough to write software for the best case scenario. You shouldn't have to replace your entire toolchain once the thing you dreamt about happening actually happens.
The game's popular enough that Activision did them the honor of cloning them for their recent Duck Dynasty game, so it's hard to say they screwed up that badly.
It's not that the picked the wrong tool for the job, it's that the job changed.
sehugg kind of got a point, but I think there were really good cross-platform solutions available back then. Just not the ones used today. Marmalade has been around for a quite while and it was/is used by a lot of big studios.
The other two comments I don't agree with.
> It's not that the picked the wrong tool for the job, it's that the job changed.
If your tool can't adapt to new requirements an argument can be made that you did in fact pick the wrong tool in the first place. That's my point exactly.
> That seems like a better option than over encumbering yourself to begin with by adding in effect a bunch of additional cross platform requirements.
I think this is a bit of an exaggeration. They don't write their own engine, so the overhead for going cross-platform is really, really small — so small that I have a hard time coming up with examples right now. Not hard coding screen sizes and that kind of thing might be one, but that's about it. There's also some irony in saying that's the better option given the blog post we're talking about.
My guess would be that the actual reason might be the lack of reliable distribution channels and/or rampant piracy. Though there is Steam, which seems to work just fine for a lot of game devs...
Google for steam tower defense
click steam web page link
"Showing 1-10 of 101 results"
Trying to be the 102nd competitor. That's tough. I can see the disinterest. Can you split a very old market 102 ways while making a profit? Frankly, probably not.
The game is definitely not pay-to-win, although there is low flexibility in strategy. (You must use all 4 types of base units.)
All three of these games are great fun and a great way to kill an hour while, e.g. waiting for a plane.
If someone is really that bad at the game that they can't even win without using a ton of items per level, then yes, it's pay to win. But if it wasn't pay to win, they would just be stuck and couldn't play at all.
The game isn't freemium either, and it's not designed to be pay to win (I'm a successful freemium game developer).
> Do these games have a large following? It's widely considered to be one of the best tower defense games on iOS.
If you have even the slightest inclination to release on multiple platforms, you should be building it as cross-platform from the beginning. There are very few reasons not to.
That seems so wasteful and challenging, anyone from the industry care to comment on how a studio would get itself into a situation of effectively zero reuse of their code?
It also doesn't help that due to the structure of the industry (e.g. work hours, low pay etc.) they have trouble retaining developers and instead replace them with fresh grads. A huge percentage of people I know left the industry before they hit 30 (myself included). This leads to a lack of experienced engineers.
Ass properly covered, I'll be real: I'm never surprised to see this because "code reuse" is generally the sign of reasonably advanced developers and I don't know a single person in game development I would hire for a role outside of it. It's not just NIH--that's a problem but one slowly going away. It's more just a fundamental lack of understanding of software engineering and building Good Code. As time goes on I've seen gamedev acquaintances poorly reinvent most of the wheels that the rest of the world takes for granted--even something as simple as serialization for save data and network transport (but no schematic validation, because "schemas suck") was trumpeted to me as this Big Crazy Great Thing. Which contextually it may be, but I kind of feel like the state of the art for stuff not involving pointer munging is about a decade behind everybody else.
So, code reuse? Gotta make good code first.
The problem is not whether or not game developers know how to reuse code but whether or not it makes sense or are allowed to reuse it. One big challenge when you are going to reuse code is not having a stable set of requirements (which in gaming is almost non existing even in the late stage of a project) and when you take that and join it with tight and unreasonable schedules you would have a huge mess as result.
The state of the industry is very unhealthy in my opinion and I wouldn't be surprise if there is another dark age for videogames coming up.
I worked in a company that went from doing software gigs in general to be full mobile gaming company. Before it was quite standard Agile style company: Scrum, code reviews, TDD, cross-functional teams (front end devs knew how servers works in general), focus on quality over quantity (one dev, rotated weekly or biweekly, focusing on fixing bugs), separate concerns.
After going full game-oriented, company hired couple of people from gaming industry into higher positions - tech leads, project managers etc. Over couple of months, people with many years of experience in those big companies dismantled what was standard for me, using combination of two arguments:
- big names don't do it, so it must be wrong - it's a waste of time
Before I quit, there were no longer code reviews (waste of time), all testing was to be handled by QA team (waste of valuable dev time), ship with issues (waste of time to fix minor bugs when can add features), single system responsibility (one dev to write code for client server protocols, one dev for UI, one dev for assets etc, that's gow big names do it).
At one of the last talks with "industry veteran", when I mentioned those things - and how negative, in my opinion, those changes are, his response was "so you are saying that whole gaming industry dev practice is wrong". At that point I thought he's right and I sound full of crap, now I believe that yes, AAA companies are simply bad development practises shops.
My guess as to why is because AAA is very strongly driven by deadlines and marketing, where you cannot simply delay release (Christmas shopping spree is coming). This idea I saw articulated on HN first and I agree with it.
For example, look at Assassin's Creed - will the bad launch cause people to avoid AC in the future? Maybe, but probably not.
Shitloads of money. Massive institutional knowledge of public relations and marketing. Direct lines to Sony and Microsoft. Every kind of benefit of economy of scale you could want.
It's not like the idea of a barrier to entry is a new concept.
It's pure meritocracy here, if you are good then getting a publishing deal is not a problem.
The core of an "AAA studio" is a big fat wallet. It's essentially definitional. You're not actually saying anything with respect to them in any of your posts.
AAA do get a lot of money but it's the effect of them making games that sell well. There are dozens of startups in SF that cannot make even mobile games with their piles of cash and hundreds people. Money do not make you a AAA studio.
I could see arguing here with myself that AAA games are usually "ship and forget", with some bugfixes only. Maybe because company I was working in was not AAA, but small (by industry standards) f2p mobile shop, where applying AAA ideas is not that great (in my opinion). I mean that's where your product is more along lines of web apps - you are going to constantly add content, update code base, refine features, so focusing on quality in long term is better. This, thought, I was not able to articulate clearly and properly to AAA veterans.
I feel like not all ideas from current practises can be applied to big gaming studios, but saying that I believe it can be improved. This may need time and risk that companies that are big enough to be called AAA are not willing to take.
Why two companies you mentioned failed? I think we can assume there might be more reasons to that than only being Agile, maybe their games were just not that good, or IP was boring? Still you sound like you have more experience than me here, I'm trying to wrap my head around whole AAA industry thing. I'm ranting about it so much because making games was way more entertaining than web/mobile, but the industry is so poisonous for pure developers that I had to quit to regain my sanity :)
>This may need time and risk that companies that are big enough to be called AAA are not willing to take.
Infinity Ward, the original home of $1B+ games, had about 100 people at the time of the split from ATVI and founding Respawn. It's about the same size now as well as the Respawn. Media Molecule is just a few dozens. Size does not make a AAA studio.
And you don't even need to show the best practices right at the AAA level - start small and if it's any good people will copy you or, at least, you should be able to grow yourself.
>Why two companies you mentioned failed? >I think we can assume there might be more reasons to that than only being Agile
Indeed, it would be naive to blame Agile on destroying multi-million businesses. Agile seems to be just a symptom. It could be that the management sees that the development process is failing and tries to improve it with a well advertised technique, for example. Or that some Agile enthusiast gets too much power due to the weakened culture. What I was trying to say is that very few AAA studios practice it now and the ones that did in the past are not in the business any more.
Also, there is no single AAA development way. For example, Valve's practices are very different from Bungie's, which are different from the R*, which are different from ATVI's COD teams etc.
Add to that that each framework has its own standard and way of doing games (event-base, component-base, etc.). The worse part I think is the game logic is generally enclosed in framework-specific objects like events in as3, components in unity, etc.
Virtualizing that would be expensive, tricky and costy in terms of performance.
That's amazing.
The difference between engine optimized for certain platform is simply massive. We're talking at in the worst case 10x the performance difference.
Why is this? Let's take modern console game for PS4. It uses mantle like API where you can simply spam drawcalls like no tomorrow. Port that to DX11/OpenGL and you'll choke.
Or move a simple OpenGL game from PC to mobile, it does nothing fancy and uses ES2.0 subset of OpenGL so it should work nicely? Not quite. All your scenes are built using effects that cause massive performance penalty in tile based renderers. Sure it works fine on Tegra K1 but everywhere else it's horrible.
On the other hand there is a way of doing multiplatform development. It means using Unity (or other multiplatform engine), limiting yourself to a common subset and leaving the optimization part to be the headache of the engine developers. However even if you use Unity you have to manually consider the effects you are using on per platform basis.
After the Amiga/Atari/Commodore/etc era when games were ported on every platforms came the PC age (which was relatively divided from the consoles during a long time). Now heavy crossplatform is back again.
Basic, C and Pascal were the Python and Ruby back then.
So porting studios appeared, specializing in porting the games to specific platforms. The porting industry came to life.
Fast forward 30 years, you still need to write quite hardware specific code if you wish to squeeze out every possible ms out of the machine, which opens the door for all kinds of shortcuts.
This of course only matters when doing AAA games.
So you do the safe thing everyone else is doing, Cocos2D and Objective C. You'll worry about porting later, if the game does well. Maybe you'll just pay someone else to do it.
They could have used AIR on mobile to re-use the AS3 codebase. Alternately, they could have done c++ on cocos2d-x instead of objective c, so that would have been pc portable.
They would just have to write it twice, in that case. However, if you are a group of AS3 devs jumping to mobile, they probably picked the best sounding thing at the time - which was cocos2d.
Keep in mind android wasn't really a game platform in 2011, so choosing cocos2d in obj-c over c++ wasn't really a bad call.
On the other hand, the use of bold and non-bold was driving me nuts. I feel it's up to the reader to decide what is important in the text, not the making of certain sections of bold, it was hard for me to read.
After awhile, as I wanted to read the whole thing, I copied into a text editor to read.
> Should we make a PC version? Absolutely!
cool.
> Can we make it? Nope.
should have been Yes.
> Are we focusing solely on mobile from now on? Not at all.
Nice misdirection. The question should have been:
> Did we decide to focus solely on mobile? Yes.
Then the rest of the article explaining why.
Short story is, they chose their engine poorly, and are now making excuses. Very disingenuous blog post.
https://en.wikipedia.org/wiki/Super_Game_Boy
I think a lot could be done to make the core of the game more portable. It's just not being done for one reason or another.
https://news.ycombinator.com/item?id=8678936
I guess the problem is that you need different rendering code? OpenGL works on PC and mobile, but you'd need to mock it out for WebGL. Has someone already done this for asm.js?
Presumably there is some other huge hole in my thinking...
[1]: http://haxe.org/
It does look like the situation has improved since then, but I'm guessing that documentation is a big reason for Haxe being so underappreciated.
BTW IGN is giving away Kingdom Rush Frontiers promo codes for iOS, limited availability.
Or they highly recommend you play with a gamepad.
PS. I think they should fix the bugs in KR Steam first anyway, which was pretty much abandoned.
That being said, this letter is cloying. A letter where you tell someone you care about that you don't have it in you to be with them isn't a love letter, it's a "Dear John" letter (http://en.wikipedia.org/wiki/Dear_John_letter). For the recipient, those two types of letter are very different!
It would have been 100% fine to just say "look, it would take a huge effort to bring Origins to PC, and we don't have the money or the energy for that." There's no need to dress it up in shiny happy "we love PC!" platitudes.