Bikas

Members
  • Content count

    13
  • Joined

  • Last visited

About Bikas

  • Rank
    Member

Recent Profile Visitors

281 profile views
  1. Added game link: http://html5games.vooxe.com/a90bd3f1fba643828ccfb0109b41a252/index.html Also i was wrong about Pixi.js. The major cause of lag spikes was actually large update function and splitting into smaller ones solved the issue.
  2. Same issue with Samsung Galaxy S3, did work well with Pixi though.
  3. Thanks. Monetization plan was the usual - selling exclusive or non-exclusives to websites. Always wanted to make a moving defense game with zombies and to try out HTML5 market - hence this game.
  4. Found the issue. I was adding Sprite via container.children.push and it threw an error while doing preUpdate. Can't do that. Must use Phaser Groups throughout.
  5. I didn't enable or add physics at any point, yet i received errors from PhysicsBody.preUpdate. So i assumed that physics are enabled by default. Maybe the better question would be how to create Phaser game without physics?
  6. Is it possible to disable or remove physics completely? No bodies, no collisions, no updates.
  7. Thanks for the response. Yeah, i get your point about trade-offs regarding devices. I want to make more complicated games, so i would like to get the right approach from the start. With arrows/zombies i already use texture instances and pre-generate sprites to avoid lag spikes in the actual game. Adding/removing was the main issue.
  8. Thanks for the tips! I was not aware of "clearBeforeRender" and "preserveDrawingBuffer", i will have to try it out. In my game, background has very few bitmaps while foreground has tons. Do you find worth splitting in that case? Wouldn't that increase GPU calls or cost in some other way? Regarding cache as bitmap, wouldn't that spam GPU memory? Which could be a problem in older devices.
  9. Lots of good content. Bookmarked!
  10. Glad you found something useful. The game should be released soon.
  11. Hi, I am not an expert on Pixi, however i noticed that scenes with lots of nested containers and sprites causes more of internal Pixi updates (transformations and probably WebGL related stuff) which may eat few milliseconds of CPU time. As far as i am aware, adding/removing stuff is most expensive. That's why re-used arrows and zombies in this game. As far as app store, i have not tried any of these wrappers. However i did look into Intel XDK and it seems pretty good choice. I would expect that they value performance and have good profiler and debugger.
  12. Hello everyone, Recently i finished my first medium-sized HTML5 game - Medieval Defense Z. I came from flash background and developing for HTML5 presented with some new challenges. So i would like to share what worked and what didn't. This is more like review/tutorial type of thing, so hopefully someone will find something useful. • Goals: • 60fps. • Smooth gameplay and animations. • Quality comparable to flash games. • Tools: • Language: Haxe. Strictly typed programming language, similar to ActionScript 3.0. Compiles to all major languages, including javascript. • Editing: HaxeDevelop IDE. Freeware, great code completion and very fast compared to everything i tried. • Debugging: Chrome. Has console, debugger and profiler. • Rendering library: Pixi.js. Uses display list concept like flash. Works well. • Sound library: Howler. Good enough, the id system is a bit weird though. • Bitmap font exporter: http://kvazars.com/littera/. Free and web-based. • Sprite Sheet Packer: https://spritesheetpacker.codeplex.com/. Freeware and very simple. • Graphics: • Scaling will look ugly if you use many small png files for textures. • If you want nice scaling, fast load times and fast rendering - pack everything to 2048x2048 spritesheets (include bitmap fonts too). • Resolution of assets: 1024x768, background can extend to 1382x768, so it covers most aspect ratios in horizontal orientation. • To get proper native resolution in mobile browsers i scaled up renderer and scaled down canvas by window.devicePixelRatio. • Sounds: • Library: Howler. • Sound formats: ogg for Chrome and Firefox, m4a for Safari and Internet Explorer (note: mp3 has licensing issues with play count). • ffmpeg: because of licensing issues and whatnot can't convert to m4a, unless you recompile ffmpeg with m4a, which is a pain to setup. • I used MediaHuman Audio Converter (freeware) to convert from wav to ogg and m4a (64 bit). • iOS Safari: keep in mind that before any sound could be played, user must first tap on the screen. • Mouse Events: • Used pixi.js API to open links. • iOS Safari: window.open under "touchstart" event won't open links in new tabs, use "tap" event instead. • sprite.on("mousedown", callback) for desktop. • sprite.on("tap", callback) for mobile. • Performance: • Reuse frequently used sprites. • Avoid creating too many objects every frame. • I would recommend looking up data-oriented programming to get more juice out of Javascript. • Record timeline with Chrome profiler to find performance bottlenecks. • Masks are slow. Use trim if you only need a simple cut. • Very large functions may cause lag spikes. My best guess is that browser is trying to optimize the function. Splitting big function into several smaller ones solved my problem. • Game Debugging: • Simple CSS + DOM side menu. • Basic field view/edit. • Simple buttons with callbacks. • How to debug html5 game on android (mobile) with desktop chrome (PC): 1. Upload game to your website. 2. Go to (desktop) chrome: chrome://inspect 3. Connect Android device with USB and run your game on android chrome (your android device must be enabled for development). 4. Open Command Prompt and enter: adb devices (must have Android Debug Bridge installed). 5. To quit debugging enter: adb kill-server • Conclusions: • Programming in Haxe instead of pure Javascript probably saved hours and hours of debugging. • Would have liked more automated solution for spritesheet and sound stuff. • Poor performance bites sooner or later, so be prepared to do extensive profiling. • Stable 60fps is very hard to achieve, even if you keep your code below 1-2ms per frame. • Overall i am happy with the results, however it took longer than expected to make this game. Any feedback is appreciated. Game Link: http://html5games.vooxe.com/a90bd3f1fba643828ccfb0109b41a252/index.html Trailer: