• Content Count

  • Joined

  • Last visited

  • Days Won


KyleNau last won the day on September 6 2014

KyleNau had the most liked content!

About KyleNau

  • Rank
    Advanced Member

Contact Methods

  • Twitter

Recent Profile Visitors

1900 profile views
  1. Sure, I'll be the voice of dissent Canvas is probably the worst target for interactive fiction. The majority of features that you are looking for a framework to provide are offered by default in the browser itself. The reason we even needed JS game frameworks is because the Canvas element requires you to recreate from scratch the functionality that the browser DOM gives you for free. I'd even argue that unless you plan to support IE 6 or old Android browsers, compatibility is a non-issue, so even something like jQuery isn't required (but can be useful). PROS Text is exponentially easier to manage on the DOM. Word wrap, inline styling, scrolling, selectability, input, etc. are all native browser features and don't require canvas hacks to recreate. Your game can be responsive, conforming to the end user's device in ways more meaningful than simply scaling. The DOM will repaint more efficiently and do it only as needed. Complex text effects, styling, animation and tweening are easily added with CSS and will automatically update with the screen refresh. The entire browser window and all its features can be your playground - break out of the canvas box paradigm! You're just changing the presentation layer. The rest of your game logic (event listeners, etc.) is still plain JavaScript. Your game should be more lightweight since half of the code you would need to get canvas to work is already taken care of for you in the browser. CONS CSS can be a bit tricky if you're not familiar with it. You sacrifice some control of your presentation. The browser useragent can override your styles and increase text size and contrast for accessibility / visually impaired users if they want it to. I'd urge you to consider just using the plain old DOM for an IF project. Simply start with a test. Pick a very thin vertical slice of your game with the features you are looking for and try to mock it up in both canvas and DOM and see which works better for you. My 2 cents.
  2. Not many browser 3D games, I'm afraid. If they existed BabylonJS and ThreeJS would be crowing about them on their homepages. In terms of a contractor skillset (say, you do freelance web / interactive dev work) it's not a bad skill to have. But there isn't any direct money in it. You could theoretically make a game and seek sponsorships but that's also, effectively, no money. Your engine decision should revolve around the platform you want to target. If you want to be on the web then you're using one of the JavaScript engines. Any other platform and you should be using Unity or Unreal.
  3. We all want to be HTML5 evangelists here but I feel like in your particular case webGL isn't suitable and you are heading for a painful dead end by doing so. This is all just my opinion, so make of it what you will (TLDR - it's technically possible but likely a fool's errand): 1 ) Is possible to create big complex and demanding games like... Graphically, for the most part yes - the visual style being almost completely determined by the art, not the engine - but anecdotally webGL isn't going to perform as well as native. Even in wrapping the game in an EXE you will always have the performance hit of a browser engine that isn't optimized for games running in the background. Furthermore my understanding is that none of the current engines are ready for webGL 2 (and only two browsers support it) so technologically you will be behind the curve. You could make them in webGL but the question would be why? The result would be more difficult to develop and wouldn't perform as well. 2) If you use a html wrapper to create a .exe, .apk etc. ... While I'm not a hacker, I'm going to go out on a limb and say "no", your source isn't protected. My understanding is that in most cases the compile process is just for packaging files together, they aren't being converted to native code or anything like that. Somewhere in that node-webkit EXE there is still a javascript file being interpreted by the webkit browser at runtime. And, no, you can't compile for consoles. 3) I have read that you can code in c++ and compile it to javascript is that functional? Yes-ish. There's ASM.js. That process is unnecessarily convoluted for your purposes though; writing in C++ to compile to JS, only to then compile to a desktop EXE. JavaScript is an unnecessary middle language that is going to eat away at your performance and complicate your entire pipeline. If you're writing in C++ or C# and have no intent on targeting the web, then just compile directly from that language. 4) How does it come that i can not find any big games made in webGL... The HTML5 game community started out of the gate being obsessed with mobile games. webGL has been functioning on phones only fairly recently and even still its performance leaves a bit to be desired. Might as well ask why there are almost no complex and graphically rich Canvas games. 5) When i looked around this forum i dident saw any three.js based games. Why is that? See above. Also worth reiterating that these are *web* tools. No one has really figured out how to monetize games on the web since Flash died so the wider gamedev community is focused on apps and desktop games. The incentive to make something complex and cool on the web (from a commercial standpoint) isn't there. 6) Is webGL for my project a smart choice? No, it really isn't and that's why I logged in and replied to this post (I haven't frequented the HTML5 community in a while). I feel like efforts to steer you to various webGL tools are being disingenuous. It is absolutely not the best tool for the platforms you are targeting. 7) What is the best engine to use for a 2d/2.5d with some nice light effects? Most likely Unity. Not because of any spectacular 2.5D / lighting toolset (although it has them) but because of it's ability to easily and reliably target the platforms you are after as well as the overwhelming amount of learning and development help available. You can barely google any game programming questions without being swamped in Unity specific advice. You can code in C#, which it sounds like you'd be more comfortable with, or you can purchase visual scripting tools like PlayMaker that make it even easier. 8) Does the steam SDK for achievements, joining friends, steam controller etc. work well with webGL? Clarification - those things have nothing to do with webGL, they are JavaScript, HTML5 and apply to Canvas based games as well. The Greenworks library from Greenheart games will get you most of the way there as far as basic Steam integration goes. The controller would be reliant on the HTML5 gamepad API. I hope I didn't come across as too negative. I am an HTML5 fanboy but only because I'm an open web fanboy. If your target is strictly desktop and consoles then you are creating extra unnecessary work and cluttering your pipeline if you use HTML5 / webGL over any of the engines that were specifically built for that task. The fact that the landscape of webGL is littered with nothing but tech demos and very few actual games should be a red flag that you're about the spend months bashing your head figuring out how to apply a GLSL shader to a spinning torus knot and wrap it in Electron. IMO if you want to develop games then go with the platforms that indie and professional game developers gravitate towards. Kyle
  4. I've complained before that the mobile HTML5 market is largely overstated and that targeting it has become the entrenched conventional wisdom. I think it's ready to be proven wrong. The challenge is that you need a way to monetize your game despite everything in the HTML5 market being angled for mobile. However, millions of people are monetizing traffic to their websites just fine. There is no technical or market-size reason that you couldn't be successful. Look at how to monetize web traffic, not specifically game players. Then again, if you're already developing in Unity you might as well make a downloadable game where the potential upside is exponentially larger than anything you could make with web games.
  5. My main point - going back to selling a game versus sponsoring - is that there is no one true business model that all HTML5 developers need to follow and I worry that "sponsorship" is the only business model being discussed (and sold) on this board. The success model exists for direct-selling games as well, if you want to check out Lost Decade Games' or Greenheart Games story. In fact, I wish those guys were active on this board just to offer a counter the sponsorship message.
  6. All successes are outliers, in any business or creative endeavor. Developing games is a stupid way to try and make a living, let alone get rich, so the assumption I make is that most of us got into for creative reasons and, if so, I think it's smarter and just as likely to produce success by staying true to that. The difficulty curve is the same regardless.
  7. I think this is a problem of tunnel vision where most HTML5 game developers automatically think in terms of sponsorship for their games. People have been monetizing web content for decades and there are a lot more options for generating revenue. In fact, the more unique and interesting the game the greater the number of options available to you but it changes the approach to development (both what and how) significantly. Licensing is a business-to-business transaction, the audience (for both parties) is pretty much an afterthought but you can always take your game directly to the audience. Examples: Dwarf Fortress is free, ugly and devastatingly hard to learn - but earns over $4,000 a month in Patreon (and was doing so for years before that using regular PayPal donations). John Battagline has a Casual Connect talk about building his business (and going full time indie) with freeplay Solitaire and Mahjong websites. And quality isn't the metric here as much as niche is. It's worth remembering that Minecraft started as a bare bones Java applet posted free to the public. Spelunky was a Gamemaker game, posted for free with its source code. We've all been in the sponsorship game and seen how... resoundingly unimpressive the sponsors are. If you're making something special, something interesting, you would be a fool to trust it to them for the pittance they offer. Had any of the above examples taken a sponsorship (allegedly the Dwarf Fortress devs turned down a six-figure offer) they never would have been the successes they came to be.
  8. I'm surprised no one has mentioned it yet but the "Pomodoro technique" ( has saved my butt so many times that I now build my entire workday around it. It adds structure to the idea of working in small focused increments. You work in 25 minute intervals (a "pomodoro"), in which you are focused solely on the task at hand. No e-mail, no grabbing a snack and no interruptions. In fact if someone comes in and starts talking to you, that pomodoro has failed and you're supposed to reset the timer and start over again. It's as much about training the people around you to respect your focus as it is about training yourself. After 25 minutes, you break for 5 minutes and engage in something other than your work (preferably get up and move around). Every third or fourth pomodoro you take a longer 25 minute break. It sounds like it shouldn't work, such small increments of productivity but once you get used to short bursts of intense focus you can be insanely productive. I get more done in a 6 pomodoro day (technically only 3 hours of work) than I used to in an entire 8 hour workday. I've also found it helps me schedule better since I've gotten pretty good at breaking projects down into 25 minute tasks / chunks. Lastly, I've noticed it helps fight procrastination. No matter how stuck I'm feeling I can always take 25 minutes to at least get started. Sometimes I break the task down as small as "This pomodoro I'm just going to set up the file folders for my new project". By the time I'm done that small task I'm "engaged" and ready to do more work. Anyways, hopefully I didn't oversell it too hard. Just Google Pomodoro, there are plenty of timer apps for iPhone and Android. I used a web based one:
  9. I always felt like we shot ourselves in the foot by focusing on mobile-first with HTML5 games. We let the opportunity that the death of Flash presented pass us by We were all so in love with the idea of our games on phones that we targeted the weakest, most fractured platforms to develop our games on (using an unfinished spec)... and then couldn't understand why monetization didn't take off! Given a do-over I think I would have focused first on delivering top quality non-casual games for the desktop browser and then extended that into a mobile presence. Now the implementation of the HTML5 spec has finally caught up on mobile but the market is almost completely unchanged. Apps still rule and there are very few players (almost all small / regional) paying low fees for casual-ish games. Most (all?) of the HTML5 gaming tech startups that were initially shoveling out money to developers have withered and died. For better and worse, not much has changed on the business side. It's still trench warfare to make any money but it's also still wide open for opportunities.
  10. It's important to mention that in the current environment you will still make much more doing contract HTML5 game development than you will licensing games. True Valhalla can correct me on this but I think in his income reports he lumps both contract work and licensing into the same heading of "HTML5 Games" revenue but a good chunk, particularly in the big ~$10,000 months, comes from doing contract development. I was never able to license a game for more than $500 and even that only after months of back and forth e-mails in broken English. Contrast that with $3,000 to $6,000 per game doing contract work locally, so that's the route I went. However contracts are a one-time payout for hours worked and it's hard to build a sustainable small business on that alone. Looking back I wish I had stuck with licensing on the side, because even a small passive income (no extra work required) of $300 to $500 a month can make a real difference in sustainability.
  11. A bit of a loaded question considering this board is owned by the guy who created Phaser Even still, between Phaser and LimeJS go with Phaser. Just checking LimeJS's github and it hasn't been updated in a year. Their site hasn't been updated since 2013.
  12. Clickteam Fusion and a number of games and source files are now available in a Humble Bundle. This just after GameMaker was in the bundle. I guess Fusion is still a thing? There are so many "game makers" out there it's hard to keep track but this also has an HTML5 export if anyone is interested.
  13. +1 for GitHub pages.
  14. Hey, I got a notice from DropBox that they will be disabling HTML rendering for public links as of October: Just a heads-up for anyone hosting their games portfolio on DropBox. You will likely have to find another hosting solution. Kyle
  15. If you're looking at web browser based games then you are developing in HTML5. However, Flash (now Animate) claims to let you author HTML5 games through some voodoo with CreateJS. They say it maps 1:1 your AS3 source code with HTML5 Canvas. I can't substantiate that, though. If you are looking for native app or desktop development then just go to Unity. By a wide margin it's the leading game development platform for indies.