Making bigger html5 games

[Gio]

I would like to hear people's view on bigger html5 games. I don't mean "big" in the sense of console games such as Bioshock, but larger scale than the current html5 standard, which is snake or bejeweled-sized games. You know, something in between - pretty much like the games that we used to play on PC a decade ago.

There is generally a lot of negativity about trying to make these bigger games, but it isn't something that I fully understand. So I'd like to encourage a constructive discussion about it.

The main argument is that a nice, polished, big game is not worth the effort, as it doesn't generate significantly more revenue than a simple and rough one - so why spend 20x time on it? You could make 20 small games instead!
I think that while this may be the case right now, because there isn't much competition with html5 games, it will change very soon - when the competition grows (as it is doing), you'll need better products to stand out. And you won't make those products overnight. It will take time, so it makes sense to start planning for them sooner rather than later.

The other aspect is a technical one - it's much more difficult to make a large scale game that runs well on a variety of devices, and it's too much of a challenge for many small indie devs.
I think that, however, that's a problem with the current set of tools and engines, that are aimed mostly at making small, simple games. With the right tools (or if you take the time to make your own tools, which is a one-off time investment), it really isn't too difficult to make a larger-scale game that works seamlessly on mobile and desktop. Having said that, I couldn't find any suitable engine to do this, and had to write my own, which was time consuming. But I think that this is changing already, as some of the more popular engines are growing into proper professional products.

And finally - how do you publish such a game? It's going to be much harder to integrate publisher-specific stuff into a large scale game that makes constant use of social and multiplayer features, than it is to just post a high score to a leaderboard. In most cases, given what publishers pay for the integration, it won't even be worth the effort.
I have no answer for this one, but my feeling is that if you're going to spend a considerable amount of time on making a product, then you might as well do the extra effort of porting it to the various platforms (as native apps) and promote it yourself, with a small advertising budget and some external help. In other words, self-publish and get some non-exclusive distribution deals on different platforms.

Sorry for the long post, but please contribute if you have any experience with this - or even just an opinion
 

[remvst]

I once made a game in ~6 months, because I had the time and motivation, and yeah, I'm not sure I'll ever do this again. The result is not that bad, but I just don't know if it was worth it.

 

I probably lack talent and inspiration for bigger games. Though, I'm currently trying to change from my basic endless scoring games to something with a bit more scenario, less random.

 

If I had inspiration for ONE great game, and enough motivation to spend several months on it, maybe I would reconsider my position, but sadly inspiration is not here very often

[Daikrys]

personally my passion is making games so sooner or later i will make a bigger one wich might only break even and no profit (as i define the indie way, no focus on profit and do what you want)

 

right now you could handle such big html5 games as "premium" titles, i dont really know if there are much publishers yet who have premium categories and pay much more for this kind of games

 

in future the devices will handle even more complex games and maybe when new distribution ways pop up. there will be a hype on html5 too, and that means that possibly bigger companies tackle the market.

this would also mean if you had done alot of small games with some nice profit and you was able to save some of the money for developing bigger games, youre in a good position to compete with any big game, plus you got some experience already wich is a great advantage as well

 

indeed with the wrapper stuff and game portals like konregate its also possible to start an advertising campaign that might generate enough traffic to make a nice profit. but thats why so much guys step back from making bigger games, it still have a high risk and will cost you money before it will generate money

 

the market will change at some point but currently its safe making easy small games and thats why so many stick with it

just make sure when the market turns around youre ready for any new thing that pops up (maybe bigger games)

 

 

If I had inspiration for ONE great game, and enough motivation to spend several months on it, maybe I would reconsider my position, but sadly inspiration is not here very often

 

i have the inspiration, every day i build new game docs with some cool ideas and working concepts, but i really lack motivation when i have to do anything on myself. and im not ready to spend a huge amount of money to outsource such an amount of work

[Chris]

I think a big reason why we are not seeing "bigger" games so far is also the limitation in bandwith for the most potential players.

The most big games are installed offline and store their huge amounts of data on your harddrive. For a browser based game, the assets have to be re-downloaded again and again (yes, there is theoretically a browser cache, but... meh). And the problem is: users await those games to perform like native ones: you start the game and it runs! Not have to wait an hour to have 100MB+ of assets to be downloaded...

 

But thats also a question of architecture, since you may be able to load the game assets in a clever way during the progress of the game so that the user doesn't need to wait for long times until he's able to play.

Another approach that has been used by some browser games in the days of 56k and ISDN was to offer a downloadable asset package you had to extract in a specific folder of your harddrive for the game to use it. Clever, but a bit tiresome for most users.

 

The other "big reason" why we only see so many small games in HTML5 is that the technology and tools have to be formed around that platform. We also need MUCH better performance here to build serious stuff. Remember the early days of PC games? There were only minigames, too...

[@99golems]

it's completely doable, of course. I made a game in about a year and i'm not sure it really fits with my dev style. I like making rapid smaller games, and financially smaller games make more sense for me.

 

If you have the patience and attention span to make a bigger game then by all means. Technically speaking I've heard the capabilities of browsers and html5 games be compared to PS2. Make a game, throw it on kongregate, and be proud that you made a cool game.

[rich]

I think there are 2 issues here:

 

1) It's not financially sensible, unless a client is paying for it

 

2) Mobile devices are so limited you can't really make a 'big' game anyway, and if you want to actually make money then mobile is where you need to target, not desktop (where you could easily create a 'big' game).

 

Having said that we're finishing the build of our biggest game yet for the BBC, it's a fully mobile title but still has a large game map to explore and 19 different mini-games within it, definitely our biggest undertaking to date. And actually we're having real trouble getting it not to crash mobile browsers on low-end devices because they run out of RAM so quickly. I wouldn't be doing this if it wasn't client work though, that's for sure.

[NewDisplayName]

And finally - how do you publish such a game? It's going to be much harder to integrate publisher-specific stuff into a large scale game that makes constant use of social and multiplayer features, than it is to just post a high score to a leaderboard. In most cases, given what publishers pay for the integration, it won't even be worth the effort.

 

I think you - and Rich - touched on the most important point. How do you monetize a larger game? This is especially important given the fact your budget will be likely be much higher than a smaller game.

 

The established model is that players will pay a one off fee and get a copy (or license) of the game. Steam has thrived using this model and for good reason - players and developers like it. It might be more tricky to implement such a system on the web, however, because players will have to sign in or otherwise prove that they own a copy of the game. 

 

I think a different model would be more effective - In App Payments or IAP's. I don't mean ruining the balance of your game with a gem currency or something similar, I mean allowing a large portion of your game to played for free and then charge for the rest. League of Legends offers aesthetic costumes for characters and has become immensely profitable. Imagine how many more players league of legends would have if it was on the web, and you didn't have to spend an hour downloading and installing it.

 

Alternatively, some games have put up 30% of their game on Kongregate and then allowed players to instantly play the rest of the game with Kreds - Kongregates currency. This way you utilize Kongregates massive fanbase and get paid by people who love your work, not some rubbish advertiser.

 

These solutions seem to fit our market of web games much better than the existing one off payment model.

 

Hope this helps,

Sondar

[benny!]

There are already a lot of bigger browser games written in HTML5 on the frontend side. Of course - those games use the freemium model to monetize, All games require a persistent game play (ie. server side code) though. That said - such bigger games requires more resources to develop & maintain (server structure, team, marketing, payment etc).

[Gio]

I guess it all comes down to what you mean by 'big'. But I would personally disagree that it isn't possible to make larger-scale games on mobiles. It's challenging, for sure, but doable - for example, think of any of the current html5 puzzle games, and add some context, a story, characters. Not that it would necessarily be a good idea, but there's no technical reason why it wouldn't work on mobiles.

 

Regarding the bandwidth, I agree that if you're looking at 100MB+, that's out of the question. But still, there's a lot you can do while being under 10MB (assuming that you don't want to do crazy high-resolution graphics for tiny retina displays). There are many compression techniques and tricks that aren't used very often (I suppose because it takes time to implement them), but could help significantly with the size, such as procedurally generating part of the game sprites.

 

Sondar: yes, I think that IAP are a good way forward for large-scale projects. You have to implement the IAP system several times - once for Kongregate, once for the Windows App Store, and so on. Sadly, they're all different, but that's still doable. The main problem with that though, is how do you monetize the non-paying users? I mean, you're still sending them some data - not just the game files that could be done by a free host to some extent: in a multiplayer environment there will be more data to send, so non-paying users will still cost you money. What yo you think of the model where you display adverts, and get people to pay for a "premium" version with no adverts, and a couple of extra features?

 

I suppose that if you have lots of money to invest, you could do something on the scale of Ikariam, like benny just said. But that's getting a bit too big (too much money!) for small devs.

 

Most importantly, rich, I'm curious to know why you're saying it isn't financially sensible. Is it something that you tried and didn't work? Is it something that you didn't try, but wouldn't know how to monetize because you've been using a different business model so far? Or maybe is it something that you would consider too risky an investment for a small dev?

 

I have been planning to release a few games of different sizes, to see which ones make the most financial sense (a 1 month project, a 2 weeks project, a 1 week project, etc.). In the realm of AAA games, only the ones with the longer development time (i.e. the bigger investments) actually stand a chance of making any decent profits. I know that this a completely different market (and that's why I find it quite exciting), but I've been finding it hard to find some real figures to use a starting point, to make a sensible business plan.

 

So if anyone has first-hand experience with larger-scale projects and their monetization, would you mind sharing some figures? I appreciate that we all know that very small games do sell and, depending on your expectations, they may be enough to sustain a small business. But how do we know that the bigger ones don't sell?

[rich]

It's not that they don't sell, that isn't the issue - the issue is that most portals have a fixed amount they will pay for a game. It doesn't matter if you take them Skyrim or Sokoban, the money is usually the same. Except with one you'd make a loss and on the other potentially a profit. The only time it might make a difference is with mobile ads, but again I've yet to see anything that proves more long-form games do better than quick hits right now.

 

I don't believe that IAPs work well in mobile browser games yet. I've never seen ANY evidence to suggest they do. Lots of companies talk it up and have asked I make them games with IAPs in the past, and every single time I've asked them for stats to prove it's worth my effort and every time they've failed to give them, which to me means they're hiding the fact that the money is terrible. I fully expect this as IAPs on mobile are a pain in the ass, certainly not the friction-less experience of native apps, far far from it.

 

Also to me what you describe (re: "story" etc) isn't making a bigger game, it's just adding window dressing to a still simple mechanic. To me a true 'bigger' game would have a bigger scope in the first place, i.e. a proper full style RPG, an RTS game, a shmup with multiple levels/baddies/bosses, etc.

[NewDisplayName]

Also to me what you describe (re: "story" etc) isn't making a bigger game, it's just adding window dressing to a still simple mechanic. To me a true 'bigger' game would have a bigger scope in the first place, i.e. a proper full style RPG, an RTS game, a shmup with multiple levels/baddies/bosses, etc.

 

Yeah we should probably start narrowing down exactly what 'big games' are. 

 

The game that I think is a really good role model for monetization is Defenders Quest.

 

They made a significant portion of their revenue from direct sales and sales through kongregate - both methods which have no (or very few) gatekeepers. In addition I think this system would work well with HTML5 Desktop games - Kongregate supports HTML5 Desktop and you could build a website for players to log in and play as well.

 

The benefits you can provide by being web based are obvious: instant and easier updates, no downloading etc. This would mean more players (Who wants to spend 2 hours downloading and updating a game? Not me) and players would spend more time playing. 

 

I agree with Rich however on IAP's on mobile. The only reason players currently use IAP's on mobile is because it's through Apple/Google, and players trust those companies. Those aren't available for web. Also, I expect mobile HTML5 games to have shorter game times and less repeat plays than apps, because apps sit on your devices home screen, and your web games don't. I don't see widespread adoption of a third party IAP system for mobile taking off anytime soon.

 

Hope this helps,

Sondar

[Straker]

In the realm of RTS, there are a few decade old games that have been remade for HTML5, such as Command and Conquer and Dune. For FPS, they have remade Doom and Quake (still in the works). There is also an MMORPG style game called BrowserQuest done as an HTML5 experiment. There are even games that started out as native mobile apps that have remade their game using HTML5, such as Cut the Rope, Angry Birds, and Contre Jour. So I think 'big games' can be done for HTML5, however, they are mostly done by big companies (Google, Firefox, IE, etc.), and only a few are done by indies.

 

What is interesting to note is that all these games are free to play (even the ones remade from mobile apps). The remade mobile apps make their profit from the app store, and not from their HTML5 counterparts. So I agree with what has been said concerning monetizing an HTML5 game. Either you make it a mobile app and charge for it or make it free and have IAPs.

 

IAPs have thrived in Facebook, even for mobile browser games (Zynga has shown this). However, if you do want to charge for an HTML5 game, you almost have to go through a 3rd party, such as the Chrome Web Store, so that they can regulate who can play it or not. Games like Bastion I think have done well in this regard.

 

I think the reason for this is primarily because HTML5 game development is still a relatively new frontier and everyone wants to see its capabilities and where it goes before they invest in it. This means creating games that have already been done before just to test the limits. In time, I think HTML5 can be a good competitor in the game market, but first the technology has to get there and the people have to want it. When Steam was first launched, people were very skeptic of its success and its business model. Now everyone loves it. Once HTML5 games get a similar business model, I think the market could take off.

[GoldFire]

We've been working on what I would consider to be a "big" game using the Isogenic Engine for almost a year now. The game is an open, persistent multiplayer game. It has elements of role playing, city building and tycoon. It is 100% on the canvas, and while we've run into many technical challenges, we've found solutions for everything so far. The game is in private beta right now and we are getting a lot of really positive feedback (average play session is around 2.5 hours through the first month of beta testing).

 

We are taking a different route on the publishing side. We built and launched a social gaming platform (http://goldfire.me) early last year, which currently hosts some of our past games. This is where we are hosting, launching and monetizing our new game (and will eventually do the same for 3rd party devs as well).

 

PS: if anyone is interested in testing out the game and sending us your thoughts, shoot me a message or tweet me @GoldFireStudios and I'll send you a beta key.

[rich]

What is your approach to mobile GoldFire? From what I've seen of your game so far (as a Kickstarter backer) it seems mostly desktop focused. Which is perfectly fine, but it's an important split.

[GoldFire]

What is your approach to mobile GoldFire? From what I've seen of your game so far (as a Kickstarter backer) it seems mostly desktop focused. Which is perfectly fine, but it's an important split.

 

Our focus is on desktop and tablets. We are going to offer support for mobile, but at least for what we are working on right now, desktops and tablets offer enough screen real-estate for a good experience.

[rich]

Yeah that's what I thought, thanks for clarifying that. I think most people are struggling with the 'bigger' games on mobile right now (as that is where the majority of the money seems to be). We constantly hit issues for example with Safari crashing because we fill-up too much memory I really wish I could focus just on desktop, I really do. So much less painful than mobile!

[Solidus]

What would you consider a 500 dollar game, and what would you consider a 1000 dollar game?  If you have an example or two of each, that would be great.  If it's too general a question, I understand and can elaborate if you desire.