Search the Community
Showing results for tags 'howler.js'.
Found 4 results
Hey yall - my friend and I have been working on GORILLA TOWN for about 4 years off and on as time permits. It started as a way to teach my friend how to code but also make it fun - so we aimed at making a clone of the old Qbasic Gorillas game for MS-DOS. Little by little it warped over time into an action oriented artillery game where you have to battle robots and escape said town. You blow up blimps and use power ups through 22 levels. The art, story, music, and voice overs, and UI was inspired by the jazz age and 1920s-30s Art Deco movement, but with a dash of weird humor. There is also a local multiplayer turn-based mode where you can play 1 on 1 or 2 on 2 - similar in fashion to the original Qbasic game. We have a fancy marketing site with more screenshots and features of the game that uses the same tone of voice and writing style we use in the game http://gorilla.town And of course a trailer and a Steam page! https://store.steampowered.com/app/1217560/GORILLA_TOWN/ Background I was responsible for most of the graphics, animation, UI design. We have a custom animation library, particle system, and time scaling game loop - we ended up basically with a small engine with Paper.js and PIXI.js for graphics, with howler.js for audio. We originally started with just using Paper.js, which has an AWESOME api, but keeping the game as vector based over canvas was just too slow - so we switched over to using PIXI.js and little by little migrated many of the techniques and graphics that were procedurally generated in Paper.js to sprites. Later on we used PIXI's Spine runtime plugin to so we could create our game characters. We ran into to many challenges along the way since I was so unfamiliar with the necessities of game development, I build web apps for my day job in both JS, C#, and SQL server, and very little of the usual patterns used there make sense for attempting a real-time interactive application. Object pooling, optimizing collision detection, full keyboard based navigation, etc, etc. A series of problem after problem, that could have probably been solved by not practically starting from scratch. While I learned a lot about the necessary components and the inner works of what a game engine needs - I don't think I have the time or patience to try and tackle it again, and will probably use a full fledged game framework or engine like Godot or Unity, where I can focus on the act of creating a game, and not the performance challenges with trying to make something 60fps in JS. My friend went from no programming experience at the start to tackling complex bugs and implementing many first version features as well as gamepad support. He's also responsible for a lot of the great ideas for the game, that at one point seemed impossible for us to implement. Not to mention, the original soundtrack, sound effects, and voice overs are all his doing. I highly recommend, if you are attempting to go it alone on a game, to try and rope a friend in to the process - having someone to be accountable to and generate ideas with made the difference between quitting years ago, and pushing each other to build a polished game we think we could put up on Steam. So, the game is a smattering of different graphics and audio libraries with custom written glue to turn it in to a game. We started with require.js using the revealing module pattern and migrated to ES6 and transpiled with babel. Then, in the last few months, since chrome/electron support nearly all of ES6 features, use babel only for transpiling to AMD modules so we can use require.js. So, we started with a lot of JS tools that were popular 4-5 years go but have fallen to the wayside. The web dev world these days would be using TypeScript and webpack, but we didn't see the return on investment for overhauling everything we'd already built. We did most of our day to day development inside of Chrome, but the end-goal is to release as a packaged desktop application. We started with NW.js when that was the more popular and easy to start with option, but have since migrated to Electron and all the amazing build tools created by the open source community that make it a snap to create installers for different platforms. We are planning to release on Windows first, then MacOS, and then some flavors of linux down the road. The PIXI.js forum helped us tackle some problems we couldn't solve out of the box. A very special shout-out to Ivan P who lurks on the PIXI.js forum for constantly answering our question almost as soon as we post them 🙂 Request for Feedback So, we are in beta now, and trying our best to reach people who are willing to play our game and give us some honest feedback. We have an open beta program were we are requesting feedback, and in turn, we will give those who participate a free copy on Steam upon release this April. We've had a lot of downloads, but very, very little in way of that turning in to feedback. I'm hoping a few of your here can try the game out for at least of few minutes and give us your general impression. We wan' to make our little game the best we can. You can download it for windows from: http://gorilla.town/beta.html And, for the curious, he's requirements: OPERATING SYSTEM Windows 10 64 bit PROCESSOR Intel Core i5 2.0Ghz MEMORY 2 GB RAM GPU Dedicated GPU with 1Gb VRAM or better: AMD Radeon R9 / Nvidia GeForce 650 *sorry, integrated Intel graphics chips just won't do* STORAGE 430MB available space Thanks for reading this lengthy post and we're eager to hear any feedback! - Sean
I've started using Howler.js for audio in some simple games. It takes care of loading sounds, but doesn't seem to have any preloading mechanism to fetch files before a Howler (sound clip) is created, i.e., in-game. Does anybody have any thoughts on how best to preload for it so sounds are ready to go as soon as the action starts? At the moment I'm leaning toward having Howler figure out which codecs to use, and then downloading the appropriate files so they're at least in the browser cache. Possibly I'll rework Howler a bit to use a cache internally. Is anyone aware of such a thing already? Thx
using the fantastic howler.js - all works dandy on desktop and iOS 6 but plays like a dog on android (tab 2 android 4.1.1 chrome) using the sound sprite approach, performance is woeful - it's seemingly random if it will even play a sound and there is a noticeable lag when a sound is triggered regardless of whether it plays it or not! looks like there are plenty of reported issues with android and html5 audio around - but wondered if any of you had found a better solution/library/approach to playing sounds on android specifically when making a game.