• Content Count

  • Joined

  • Last visited

About pixelpathos

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location
    Welwyn Garden City, Hertfordshire, UK

Recent Profile Visitors

1048 profile views
  1. var blobSize = 20;var circObj = new Phaser.Circle(0, 0, blobSize);blob.body.setCircle(blobSize);It may be that Phaser.Circle takes a diameter, but body.setCircle takes a radius.
  2. Hi v0van1981, Is your Player.prototype.update() function called directly from requestAnimationFrame() as part of your render loop? If so, you've tied your player movement directly to your frame rate i.e. if the frame rate drops, your player will slow down. (I've just spotted the following in the linked article: "Once the sprite is added to the game world its update function will be called every frame.") This article describes some techniques about how to separate out sprite movement from frame rate. Thanks, Vince.
  3. I've spent a couple of weeks improving Luminarium's graphics, controls, menu and tutorials. The new version is called Planet Rescue, and I've started a new forum post (with screenshots) here. Thank you for all your feedback so far!
  4. Planet Rescue's a physics-based puzzle game. Can you help the Lumins rescue planets from eternal darkness? There's a demo version here, with all levels playable (despite showing the lock symbol). The game is a reworking of Luminarium, based on feedback. I've spent a couple of weeks refreshing the graphics, improving the menu system, making the control system (hopefully) clearer, and replacing tutorial text with pictures. I've also made improvements to the drawing code. Luminarium was previously posted here. I'd be grateful for any feedback, particularly with regards to the points I've mentioned above. Many thanks, and hope you enjoy the game! Vince.
  5. Thanks for taking time to play Luminarium, and for the kind words and feedback! I've decided to take the tap-and-hold issue very seriously, and rework the whole thing. From feedback, it seems that, generally, players don't like reading even simple tutorial text, so no matter how I reword the text, players may not notice . In an ideal world, the player controls need to be visually obvious from within the gameplay itself, so I'm experimenting with a mechanic where the player can just grab the edge of the circle (I have made the edge thicker to make this possible). I'll also add some up/down arrows to make this more obviously. TBH, I'm not sure why I didn't think of this before, particularly as the game I used for inspiration, Auditorium, does this. It's a mechanism that also works across different input methods (unlike e.g. pinch zoom). Interestingly, feedback elsewhere has suggested that the game's graphics are not cartoon-like enough for a casual game, so whilst I like the semi-photorealistic sci-fi graphics, I'm trying to rework the graphics to be more along the lines of Angry Birds Space or Planet Jumpers. I'll post a screenshot or two once I have something worth presenting. Sounds and music will be staying, as they've been well received - I got something right .
  6. To publishers/sponsors: Luminarium is now available for licensing. Please feel free to contact me: vince[at]pixelpathos.com. Luminarium demo playable here. Many thanks.
  7. @lewster32 said it . The issue isn't that collisions are being checked in update(); it's more the fact that there is a fixed relationship between the number of update() calls, and the number of collision checks (even if that's, say, one check every 10 calls). That fixed relationship means that, if the frame rate drops, players will fall more slowly, etc. (and, as mentioned previously, may also fail to collide). The so-called "accumulator" works by breaking that fixed relationship. Let's say your physics engine wants 60 updates a second to be realistic/accurate, but your update() is only being called 20 times a second. The accumulator will realise that 1/20th of a second has passed since the last update() call, and call your physics engine 3 times. A good accumulator will even deal with any "left over" time appropriately e.g. if update() is called after 1/19th of a second. Hopefully, you'll achieve 60 frames per second in the end, so an accumulator would just have to mop up any slight glitches in framerate . Best of luck with the optimisations!
  8. Hi Owen, I presume it's Mr. Goggles that you're having issues with? Just stuck the game on my Samsung Galaxy S4, and ran it through the Chrome profiler. Each frame is indeed taking around 500ms (2 fps). The CPU profiler shows a lot of QuadTree operations (especially insert()), which sounded like expensive collision detection. Sure enough, you have several tens of game.physics.arcade.collide() calls in your gaming loop, which is the cause of your performance problem. Perhaps you could use a lighter weight collision detection system, rather than a full-blown physics engine, and also make an intelligent decision about which objects really need collision detection. I believe update() in Phaser is tied to the requestAnimationFrame() render loop. In other words, you have tied your physics engine update/collision detection to your render frame rate. Physics engines tend to operate most reliably at a fixed, short time step; when the physics update rate falls (such as when you have performance issues), the collision detection can start to go wonky, as it has done in your case. If you determine that the physics engine is still best for your needs, you can use an accumulator to separate the physics time step from the framerate. A developer more familar with Phaser may be able to suggest a more Phaser-like way of achieving this. Hope this helps, Vince.
  9. Hi Tom, I haven't had experience with doing this, but I have an interest in audio, so I took a quick look. I figured you'd need to do some kind of frequency analysis (fourier transform) on the audio, and that if anything was going to manage that, the Web Audio API would. Sure enough, there is an AnalyserNode which can sit in the audio chain, analysing the frequencies, but otherwise leaving the audio alone. It has methods getFloatFrequencyData()/getByteFrequencyData(), which you'd need to call in a loop at whatever rate you choose to sample the audio at. There are various demos floating around that use this technique to create audio visualisations (graphic equalizers). When the amplitude at your chosen bass frequency exceeds a certain threshold level, you'd be triggering your tween. The tricky bit might well be finding a suitable audio file with a clear enough bass frequency, then tuning your frequency analysis to pick that frequency up. Note the limited browser support as described in the MDN link, above. I haven't used Phaser before, but after a quick look through the documentation, I couldn't see any Phaser API for accessing this rather advanced audio functionality, which I figured would be the case. However, you should be able to create the AnalyserNode directly yourself without too much difficulty. Would be interested if you manage to get this working - good luck! Vince.
  10. Update: launch direction arrows have now been added to the spaceship(s). Thanks again for the suggestion, @mentuat.
  11. @mentuat, Thanks very much for taking time to play Luminarium, and for writing up the very useful feedback. The easy one first: indication of the direction of launch is a great idea - I will try and implement this shortly. The resizing is becoming a headache! I considered a pinch zoom, but originally decided against it for a couple of reasons. Firstly, when the circles are very small (particularly on small screens) or when they overlay, it may get a little fiddly. Secondly, I needed a way for the game to be evaluated on desktop. I could support both resize methods, but I'd need to decide which technique to show in the level 2 tutorial. I've just had a quick Google, and it's surprisingly difficult to detect whether actually on a touchscreen device (as opposed to a browser that supports touch), made more complicated by devices that support multiple input methods. Definitely willing to revisit this though - I may initially implement it to see how well it actually works. If you have any other suggestions, I'd appreciate any help I can get! Well done on spotting the Auditorium link! I love that game too, particularly being a musician. I initially wanted to use the same musical techniques (play an extra track as each planet lights up), and I even had the motion trails working, but neither significantly added to the gameplay (and the latter obviously affected performance), so I decided against. Interestingly, at least on desktop, I find the resizing in Auditorium tricky also, particularly where circles overlap. If I remember correctly, you have to hover over the resize line, wait for the confirmatory resize arrows, and then drag with the mouse. Is resizing just destined to be tricky?
  12. Seems very polished. I enjoyed playing, and liked the rotation mechanic, as it minimises the chance of being stuck with a set of unusable letters. The social aspects of the game add to its appeal. I agree with JUL that there's perhaps a little too much to read to start off with. As I've found out the hard way in my own game development, attention spans seem to be quite short nowadays! (What were we talking about...? ) For me at least, the scoring system seemed self-explanatory. Some of the rest could be explained "on-the-go", rather than up front. I came across a slight glitch. After submitting, I was asked to choose between logging into Facebook, or WordBog. I chose Facebook initially, but when I saw the app could post on my behalf (in itself fine), I hit cancel, hoping to choose Word Bog instead. However, I wasn't given a second chance, and the game just started again from the loading screen, losing my (not-so-precious) score. All the best!
  13. Hi Michael, Congratulations on putting Star Survival together as your first HTML5 game! Initially played it on desktop, and it plays well. Enjoyed the sound effects, damped spaceship movement, powerups and level progression (encountered a few of the much larger enemies). It took me a little while to discover that I could just hold down the mouse button, and move the cursor around, although I suspect that if I'd started on mobile, holding down a finger may have been more obvious. On iPad Air, I encountered some resize issues. In portrait, the sprites occupy the full game area, but the background only occupies the top-left quarter, with the rest black (see 1st image below). Then rotating to landscape, everything stretches width-wise, without maintaining aspect ratio, such that all the sprites are too wide (2nd image). Frame rate was very good, though. I did not hear any sound on iPad, even after the first button press (volume was up). On Samsung Galaxy S4, I encountered similar resize issues. Frame rate was generally good, although occasionally dropped slightly when there were more particle effects on screen. Sound played fine on the S4. Best of luck with the remaining development! Vince.
  14. No worries! If you wanted something to play around with, I can highly recommend Single Cell Software's Caustic 3. It's a synthesiser/sampler/sequencer that runs on Android and iOS, but also has free Windows and MacOS versions. It's like a distilled version of its much bigger desktop-only counterparts like Reason, so it's easy to play around with, even if you're new; yet, it also somehow manages to have many of the key features of desktop software. There's also sample tracks and patches for you to mess around with, not to mention lots of great video tutorials. Let us know if you manage to create something fun .