scoots

Members
  • Content Count

    46
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    scoots got a reaction from HTML5console in PBS KIDS HTML5 Dev work for hire   
    I work for PBS KIDS Digital, and we are looking for some individuals or companies to work with us on some HTML / CSS / JS / Canvas / SVG stuff. The homepage of our PBSKIDS.org portal has some fun interactive elements we call "themes". If you look at the PBSKIDS.org homepage today (31/3/2014) on a modern desktop browser, the "theme" is the desert area with animated cars. We have a couple of others that rotate daily, so if you look on another day it could be different. The area these themes reside in could hold any number of experiences that have nothing to do with what you see right now. We want to collaborate with people who enjoy making fun web experiences to expand our library of themes. Here's some info about the gig:
     
    Who we are: PBS KIDS is the kid focused wing of the US public television broadcaster PBS, which is similar to BBC, CBC, NHK, etc. My team does the game, web, app, streaming video and other digital work.
     
    Type of themes we're looking for: We have a ton of ideas and are open to hearing new ones. We've prototyped things like sticking our characters in spaceships then putting them in a JS physics engine and letting them bounce off the page elements. The main thing it needs to do are: be useable by kids, feature our characters, scale down to static elements on low powered devices and be fun.
     
    Payment: We're open to discussing this on a project basis or as hourly work with a predefined number of maximum hours. We can work with international developers, though there are some requirements we have for payment we'd have to check on.
     
    When: We want to start right away. We have immediate work that needs to be done, but this relationship would hopefully extend over a long period of time as we are constantly improving our site.
     
    Technologies: HTML, CSS, JS, Canvas and SVG are the basics. We're open to whatever JS libraries best fit the need at hand and have experimented with physics engines and game engines on the homepage. 
     
    Devices: This page gets around 60 million views per month, so the list of devices people visit on is basically endless. We target as many as we can for testing, including all major desktop browsers, iOS Safari, and a selection of Android browsers. We always specify our testing needs with developers ahead of time.
     
    Responsive Design: Our homepage adapts to the browser size and technology of each user. 
     
    Source control: We use Git and prefer to work with that. 
     
    Deliverables: HTML, JS, CSS and assets for themes that are ready to be integrated into our custom CMS. The code has to be clean and easily expanded as we're constantly improving our site and fixing new bugs introduced by browser makers.
     
    Working with us: We take pride in pushing web technologies to make awesome stuff for kids, and love working with people we can learn from. The primary people on this project are myself, Chris and Miguel. The team works in 2 week Agile style sprint cycles, and does code reviews often. If it works out that this project could work in sync with that process that would be cool.
     
     
     
    If you'd like to find out more send me a note!
     
     
     
     
  2. Like
    scoots got a reaction from Derek in PBS KIDS HTML5 Dev work for hire   
    I work for PBS KIDS Digital, and we are looking for some individuals or companies to work with us on some HTML / CSS / JS / Canvas / SVG stuff. The homepage of our PBSKIDS.org portal has some fun interactive elements we call "themes". If you look at the PBSKIDS.org homepage today (31/3/2014) on a modern desktop browser, the "theme" is the desert area with animated cars. We have a couple of others that rotate daily, so if you look on another day it could be different. The area these themes reside in could hold any number of experiences that have nothing to do with what you see right now. We want to collaborate with people who enjoy making fun web experiences to expand our library of themes. Here's some info about the gig:
     
    Who we are: PBS KIDS is the kid focused wing of the US public television broadcaster PBS, which is similar to BBC, CBC, NHK, etc. My team does the game, web, app, streaming video and other digital work.
     
    Type of themes we're looking for: We have a ton of ideas and are open to hearing new ones. We've prototyped things like sticking our characters in spaceships then putting them in a JS physics engine and letting them bounce off the page elements. The main thing it needs to do are: be useable by kids, feature our characters, scale down to static elements on low powered devices and be fun.
     
    Payment: We're open to discussing this on a project basis or as hourly work with a predefined number of maximum hours. We can work with international developers, though there are some requirements we have for payment we'd have to check on.
     
    When: We want to start right away. We have immediate work that needs to be done, but this relationship would hopefully extend over a long period of time as we are constantly improving our site.
     
    Technologies: HTML, CSS, JS, Canvas and SVG are the basics. We're open to whatever JS libraries best fit the need at hand and have experimented with physics engines and game engines on the homepage. 
     
    Devices: This page gets around 60 million views per month, so the list of devices people visit on is basically endless. We target as many as we can for testing, including all major desktop browsers, iOS Safari, and a selection of Android browsers. We always specify our testing needs with developers ahead of time.
     
    Responsive Design: Our homepage adapts to the browser size and technology of each user. 
     
    Source control: We use Git and prefer to work with that. 
     
    Deliverables: HTML, JS, CSS and assets for themes that are ready to be integrated into our custom CMS. The code has to be clean and easily expanded as we're constantly improving our site and fixing new bugs introduced by browser makers.
     
    Working with us: We take pride in pushing web technologies to make awesome stuff for kids, and love working with people we can learn from. The primary people on this project are myself, Chris and Miguel. The team works in 2 week Agile style sprint cycles, and does code reviews often. If it works out that this project could work in sync with that process that would be cool.
     
     
     
    If you'd like to find out more send me a note!
     
     
     
     
  3. Like
    scoots reacted to scoots in PBS KIDS HTML5 Dev work for hire   
    I work for PBS KIDS Digital, and we are looking for some individuals or companies to work with us on some HTML / CSS / JS / Canvas / SVG stuff. The homepage of our PBSKIDS.org portal has some fun interactive elements we call "themes". If you look at the PBSKIDS.org homepage today (31/3/2014) on a modern desktop browser, the "theme" is the desert area with animated cars. We have a couple of others that rotate daily, so if you look on another day it could be different. The area these themes reside in could hold any number of experiences that have nothing to do with what you see right now. We want to collaborate with people who enjoy making fun web experiences to expand our library of themes. Here's some info about the gig:
     
    Who we are: PBS KIDS is the kid focused wing of the US public television broadcaster PBS, which is similar to BBC, CBC, NHK, etc. My team does the game, web, app, streaming video and other digital work.
     
    Type of themes we're looking for: We have a ton of ideas and are open to hearing new ones. We've prototyped things like sticking our characters in spaceships then putting them in a JS physics engine and letting them bounce off the page elements. The main thing it needs to do are: be useable by kids, feature our characters, scale down to static elements on low powered devices and be fun.
     
    Payment: We're open to discussing this on a project basis or as hourly work with a predefined number of maximum hours. We can work with international developers, though there are some requirements we have for payment we'd have to check on.
     
    When: We want to start right away. We have immediate work that needs to be done, but this relationship would hopefully extend over a long period of time as we are constantly improving our site.
     
    Technologies: HTML, CSS, JS, Canvas and SVG are the basics. We're open to whatever JS libraries best fit the need at hand and have experimented with physics engines and game engines on the homepage. 
     
    Devices: This page gets around 60 million views per month, so the list of devices people visit on is basically endless. We target as many as we can for testing, including all major desktop browsers, iOS Safari, and a selection of Android browsers. We always specify our testing needs with developers ahead of time.
     
    Responsive Design: Our homepage adapts to the browser size and technology of each user. 
     
    Source control: We use Git and prefer to work with that. 
     
    Deliverables: HTML, JS, CSS and assets for themes that are ready to be integrated into our custom CMS. The code has to be clean and easily expanded as we're constantly improving our site and fixing new bugs introduced by browser makers.
     
    Working with us: We take pride in pushing web technologies to make awesome stuff for kids, and love working with people we can learn from. The primary people on this project are myself, Chris and Miguel. The team works in 2 week Agile style sprint cycles, and does code reviews often. If it works out that this project could work in sync with that process that would be cool.
     
     
     
    If you'd like to find out more send me a note!
     
     
     
     
  4. Like
    scoots got a reaction from haden in Android audio issues?   
    Here is a tool for generating audiosprites and the associated time data in an automated way. I've found it quite useful.
     
    https://github.com/tonistiigi/audiosprite
  5. Like
    scoots reacted to ashakiba in Chrome Apps Can Be Submitted to Google Play Store   
    Anything which can work with sprites and 2D Canvas can use it.
     
    I have also made a library, CutJS, which works with FastCanvas, it can be programmatically used directly or be used as renderer for other game frameworks. (Feel free to cantact me if you need help using it.)
  6. Like
    scoots reacted to ashakiba in Chrome Apps Can Be Submitted to Google Play Store   
    There is a 2D Canvas to GLSurface plugin (FastCanvas) for Cordova on Android, it can be used for HTML5 game dev on Android, but I don't know if it is available in this Google service.
     
    Anyway great news!
  7. Like
    scoots got a reaction from tackle in Please help test the Phaser 1.1.4 release   
    This is a tough one. While most tile map implementations probably don't need it, some do. For instance, I've written a digging game where the dirt tiles can take an arbitrary amount of damage, meaning I needed to track dirt tile "health" for each and every tile. The framework I used tracked tile properties on the tileset tile only, so I had to implement a tile data solution myself. Callbacks on the individual tiles would have made this much easier for me, data for the indivisual tiles even easier than callbacks.
     
    I don't think that most tile maps will need this, so if you think the overhead will hurt performance, I would not add this for every single tile. That said, if it could be something you could optionally turn on if needed, that might be a nice compromise if people think this is necessary.
  8. Like
    scoots reacted to dev in 7 reasons why appstores are doomed   
    Interesting and very true on a number of points but pretty one-sided (which is okay, sometimes).
     
    For the other side, my comments below:
     
    1° the download / access flow is just bad:
    Yes, via an email, sure. But can you remember the last time you obtained an app solely through an email? I've never been emailed an app link. Appstores are great for the user because there's one single place to get all your content specifically made for your device. The general internet (or e.g.) email just doesn't offer that level of filtering. Steam or an Apple Appstore are succesful because they actually hugely improved the download/access flow. Comparing it to a web-app is fair, but then we've already got web-app stores, so the comparison isn't fair. It's just another native vs web discussion that's not really just about app stores, it blurs the discussion sadly.
     
    2° updates are a pain in the ass
    Absolutely not for the user. Yes, for a developer updating can be a pain and I fully agree, I don't have anything to add here. But for a user? Apps are curated, tested for security and in part stability. Updates are given more weight and thus more attention. What's more, *I* can choose whether I update or not, the user has choice, the developer can't force the user by changing the web-app (potential security problem, too). And updates are only installed once, whereas web-apps need to be downloaded over and over again. Especially for mobile devices on mobile internet connections (3g in a building / subway / at my friends' room that somehow acts like an internet-free cave?) having to download content on every playthrough is a pain and requires a proper backend for any developer that builds a popular web-game on any scale, something appstores handle for you. There's huge benefits for both users and developers in this space, too.
     
    3° discovery is terrible
    100% moot argument because app-store discovery is not mutually exclusive to anything else. So, appstores are an extra way to discover apps, not the only exclusive way. Look at a popular game like Kingdom Rush and you'll find *huge* amounts of appstore installs being generated through traffic from their Flash versions or Webapp versions. But all these stores point to the appstore version in the end for the premium content, which is where the developers want users to go. I wonder why? Discovery is not perfect, but any developer (as many have) can drive discovery outside the appstore to the appstore.
     
    4° 30% transaction fees are a steal
    This I think is a valid point for the future. But at the moment we're still seeing developers who built a web and native version of their game send all their users to the native version. It's probably because of one thing. Appstores have *much* better payment ecosystems. Something that a lot of people don't understand is this. Apple has more than half a billion creditcards on file. That's absolutely insane and it's a big reason its generated so much revenue from content. As a developer you can very easily tap into that, a user only has to write their own password once. The bounce rate on payments on webapps is much higher because a user has to go through all kinds of hoops to make the payment. That's why a 30% margin is fine because 70% of something is better than 100% of barely anything. This will likely change in the future as mobile web services (e.g. for payments) will mature, but at the moment there's no comparison. Try to get someone to pay upfront for a Flash or HTML5 game, or for in-game content, it just barely happens compared to the native version. This will change, but not next week.
     
    5° native doesn’t equal quality.
    Don't think this argument holds much weight. I'd say the average quality of webapps is not as good as native apps, for one. You can look at an app, see screenshots, reviews, and seeing it in the first place usually means it was featured/trending. Webapps don't have a repository for apps that is mature the curation, metadata, screenshots, reviews etc of a native store. Not even close.
     
    6° most apps need the web anyway
    What? Ridiculous argument. Because an application users the internet, it's inherently a good idea to build it in an internet browser? No. 
     
    7° why would you wrap your app in a web viewer?
    Yeah, why would you? Ugh. I think a better question at this point is why do I bother with someone throwing nonsense reasons around who obviously has vested interests in web apps because he has a company that allows you to build webapps.
     
    Anyway there's a lot of reasons why appstores are annoying and what the future of customer-software on desktop/mobile devices will be. It's very interesting and I'm personally a big fan of web applications. But let's be serious about this discussion.
  9. Like
    scoots got a reaction from dev in Downgrading iOS versions   
    Sorry, I need to give a clarification here as I was mistaken on exactly what is possible. 
     
    If you have an iOS dev account and have a device you have managed iOS versions of using iTunes and XCode, you can reset the iOS device os to an older version of the OS only if you haven't upgraded it to iOS7. If you have a new iOS 7 device or an old device you've upgraded to 7, you have to jailbreak. The way they currently manage iOS versions at my work is by not upgrading past the point of no return.
     
    So, for new devices or older ones that have already been upgraded to new iOS, it looks like you might have a tough time doing it. Sorry for the confusing answer, last time I did it was a while back before Apple took away this capability.
  10. Like
    scoots got a reaction from tackle in Downgrading iOS versions   
    Yes, I have done it, though it has been over a year. The guys at my work do it all the time and confirmed it is still possible, and pretty simple
  11. Like
    scoots got a reaction from dev in Downgrading iOS versions   
    Yes, I have done it, though it has been over a year. The guys at my work do it all the time and confirmed it is still possible, and pretty simple
  12. Like
    scoots got a reaction from tackle in Downgrading iOS versions   
    Have you used the iOS device management Apple provides in XCode?
     
    If you have an Apple Developer iOS Account ($99/year) you can manage the iOS version of your device using XCode. You do it from the Organizer window https://developer.apple.com/library/ios/recipes/xcode_help-general/AbouttheOrganizerWindow/AbouttheOrganizerWindow.html#//apple_ref/doc/uid/TP40010548-CH2-SW1 (sorry, couldn't quickly find the guide on installing old iOS versions)
  13. Like
    scoots reacted to priling in Mine Rescue   
    Hello!
    I finished my game today and want to show it to people.
     
    (Sorry my english is not good.)
     

     
    The game title is "Mine Rescue".
    A mine has collapsed. Many miners trapped in the mine.
    You are a demolition expert, you are the only one can rescue them. 
    You can beat a path to the trapped miner with your bomb.
     
    This is kind of puzzle game and inspired by many other games.
     
    PLAY => http://bit.ly/minerescue1
     
     
    As an indie developer, I want to make a living with HTML5 game and this is my first try.
     
    Any feedback about this game will be appreciated(bug, difficulty,... anything)
     
    Thank you!
     
     
    EDIT: If you play the game with keyboard, you can use arrow key to move the hero rather than virtual key. In that case, click mouse left button around the hero to lay down a bomb.
  14. Like
    scoots reacted to gaelbeltran in New official Phaser Tutorial   
    Awesome tutorial! It really explains how Phaser works. You should make a tutorial about the Scene Manager
  15. Like
    scoots reacted to headwinds in Box2D physics editor with Box2DWeb importer   
    here's something to watch too... FizzX a Box2D editor (Adobe Air app) that exports json. After playing with it for a few minutes, it looks like a good start as an early release and it does allow one to quickly construct a scene.
     
    It's developed by Allan Bishop, who has an awesome Box2D tutorial site.
  16. Like
    scoots reacted to dhaber in Box2D physics editor with Box2DWeb importer   
    After writing the above message the RUBE developer contacted me to ask for more details.  He said that he develops on Linux, and so was surprised that there were problems.    I wrote him a couple notes of what I could remember about past issues.   I also retried RUBE, and found it to be glitch-free.  I don't know if anything changed with RUBE.  It could also be that I was on an old Debian install last time, and this time I was on a recent Ubuntu install.
     
    Here are a few notes from my experiments today.   The UI feels slightly odd at first with all the various modes and shortcuts for different actions, but the contextual help makes it easy to learn quickly.  Without too much effort I was able to build a scene involving several objects, a polygon shape built around an image, and some modifications to Box2D object properties.   Once I got the keys down it was very fast to work with.   
     
    I guess whether RUBE is the right choice depends on your needs.   If you need to build and test scenes with lots of physics, I can see RUBE being very helpful.     There is a box2dweb loader, and even without that the JSON format looks clean.
     
    Of the full-scene editors, it seems to be the best.   Other tools like Physics Body Editor and PhysicsEditor are good for setting up the collision map for a body, but not as oriented around putting together complete scenes.  Each of those (I believe) can auto-trace images to create the collision map, but I'm not sure if RUBE does that.   TS4 is fine for very simple things, but overall is pretty rough.  I've made lots of use of TS4, mostly out of convenience since it is web based and simple.
     
    My usage and knowledge of RUBE is mostly limited to a little bit of playing around, but I like what I'm seeing.  I'd recommend trying out the demo and coming to your own conclusions. 
  17. Like
    scoots reacted to Ezelia in Javascript game to Phone application   
    if your game is 100% canvas then use coccoonjs, if you are using DOM then coccoon will not work (or you need to reimplement all what you do with DOM in canvas)
  18. Like
    scoots reacted to Gustavgb in Javascript game to Phone application   
    The performance was "fine" about 33 fps, but not close to as good it is in the browser
  19. Like
    scoots got a reaction from soybean in Javascript game to Phone application   
    Have you tried this yet? I'm wondering how performance was for you. I used PhoneGap to wrap a canvas platformer game in and the performance on Android was horrible, but that's really the default Android webview's fault, not Phone Gap.
     
    We're looking into wrapping canvas games in a Chromium webview that's included in the app at the moment. Currently I'm getting Android Studio set up for a test run of this: https://github.com/davisford/android-chromium 
     
     
    If you all have any experience and advice to share that'd be awesome!
  20. Like
    scoots reacted to dhaber in Box2D physics editor with Box2DWeb importer   
    I actually tried RUBE.  It looks pretty good, and the UI feels nice.  Unfortunately, I found the Linux version to be frustratingly glitchy, and so I gave up.  It does have a real nice list of features though and only cost $30, so it could be worth considering.
     
    EDIT:  I retried RUBE and found it to be glitch-free.   See my reply below.
  21. Like
    scoots reacted to AshleyScirra in 2d pixel-perfect collision detection with rotated graphics   
    I'm a little late to this thread, but we wrote a pixel-perfect collision engine for Construct Classic (in C++) that supported rotation and stretching. It was one of the most difficult bits of software I've ever worked on (and bug prone - it took ages to make it bulletproof! But maybe that was our relative inexperience).
     
    I don't think you can really use the GPU for collision tests in general. If you have to read back pixels from the canvas you'll stall the rendering pipeline which will hit the framerate pretty bad, and the GPU<->CPU bridge tends to be pretty slow on some systems as well.
     
    Our approach was:
    - make a bitmask in memory for the base unrotated unscaled collision mask (1 bit per pixel, so each byte covered an 8x1 row of pixels)
    - upon testing collisions, lazy-generate a new bitmask with that object's scale and rotation. This is really hard, since if you want pixel-perfect accuracy you have to get some fairly subtle details like rounding to match what's rendered. Even allocating the right size buffer is non-trivial, since if the object width is not a multiple of 8, you need to deal with a right-hand gutter.
    - each instance of an object caches a single scaled/rotated bitmask. If its rotation or scale changes and it needs to test a new collision, it will throw away the mask, regenerate a new one, and then test with that. If its rotation or scale is not changing, it can keep using the same mask, removing the need to keep regenerating.
    - object intersection is tested by bitwise AND on the areas of the scaled and rotated bitmasks that intersect. Again, non-trivial since you're forced in to byte alignments, and for best performance you need to use 4, 8 or even 16 byte alignments. However the benefit is if you can get it working, you can perform the tests as ints and therefore check 32 pixels for collision per iteration, or 64 pixels on a 64-bit machine, or even 128 or 256 if you get in to SSE/AVX. The larger sizes are pretty cool because for medium sized sprites you can basically check an entire row of the collision per iteration, which is so fast it's practically negligible. I don't think we actually went that far in Classic though.
     
    The collision check itself is so simple (one bitwise AND per 32 pixels, check if not zero, repeat) that the bottleneck is by a long margin the generation of the scaled/rotated mask. If you have a continuously rotating sprite continuously checking a collision, it will generate a new mask every time it tests for a collision. This is far harder to optimise; unlike the collision test itself it's difficult to get it to work with more than one bit per loop iteration. If you're working in Javascript, you will have an even harder time; I doubt it will perform well unless your game does not need this case, or you compile it down with something like asm.js.
     
    tl;dr - don't bother, use collision polygons - that's what we switched to in Construct 2!