• Content Count

  • Joined

  • Last visited

  • Days Won


ShrewdPixel last won the day on February 3 2019

ShrewdPixel had the most liked content!


About ShrewdPixel

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
  • Interests
    Programming, Linguistics, Psychology, Game Design, Machine Learning, 3D Modeling

Recent Profile Visitors

1082 profile views
  1. Play tested using Chrome on MacOS Mojave. Delightful quick-shot game. Performed well without any glitches, with a fun visual style. The difficulty is somewhat unforgiving at first, but encourages the upgrade system to advance to the next tiers of gunfights. Nice job taking a simplistic concept and creating an absorbing game from it.
  2. I'd love to hear more opinions offered on this subject; my experience on this primarily comes from setting up database applications for companies that require very strict security for large proprietary datasets and (usually) already have a rather large client base. I mainly make games for fun and to add to my online portfolio. (Most of my professional work is locked behind non-disclosure agreements, so I can't share it.) That's one reason the first game I've showcased on here was an example MMO; it's easier to integrate the database experience I know. But after our conversation I feel my experience in it has polarized my view on the subject of security and authentication, and I would really like to hear from others who have approached it from different perspectives that might be more practical from a gaming standpoint. There is a much broader range of situations that can be considered when addressing the practicality of this for the dev and the user, ranging from casual games to MMO's.
  3. It's never my intention to assume the experience level of any user on this board, nor do I ever want to come across as "talking down" to anyone(I see too many knowledgeable users doing that already); I just try to add as detailed of an answer as I can for a forum where users ask questions - please forgive me if I went a bit overboard this time since security is such a Pass/Fail subject I've seen mishandled. While I don't think either option is that secure, if I was to narrow it down to either the standard password authentication or a password-less method, I'd see the following disadvantages to password-less: 1. The user will need another tab/window open anyway for their email, so if may be more work for some users. 2. Email isn't instantaneous for everyone, so there could be delays to login. 3. In 2-factor authentication, the email verification is the weaker link, and allows man-in-middle attacks more opportunities to gain the email accounts login. 4. It could just wind up in the spam folder for less knowledgable users after too many emails. 5. If the user is on a non-trusted PC, they may not want to even use their primary email. 6. Your email provider will see every login, so Google or FB might still get tracking data anyway. 7. This is the big one for me: (related to #3 )usually most sites are secured with HTTPS, but with this scheme every login requires the authentication link to be transmitted in the clear unless you go to the trouble to send encrypted email or use another protocol. The advantages to password-less I can see are: 1. With persistent cookies the user could stay logged in on the same machine for up to 30 days if you wish (and the user consents, but this can be done either way). 2. If the user always has their email open, it could be less work for the user. 3. Much like with Omni-Auth, your site doesn't need to keep passwords in the database. 4. It's cleaner and less work for the dev to setup if done simply. I'd still stick with my initial evaluation: small sites might be able to do this since the security need isn't that high, but if your site takes any sort of payment info (Credit Card, Paypal, Bitcoin, etc for in-game purchases) it would probably be almost suicidal; if I can figure out ways around it, I'm sure someone else even more knowledgeable and motivated than I can. Here's hoping my discourse on this has been productive and helpful.
  4. I might still be learning some of the canvas libraries, but this stuff is my bread and butter. I would seriously caution any devs from designing their own authentication system, even if they are quite knowledgeable on the subject, for a simple reason: even large companies get hacked all the time and they have TONS of resources and dedicated personnel to work on these problems. The only reason smaller startups or freelancers get away with it in the short term is through "Security through obscurity", in other words they are too small to show up on the hacker radar or just haven't made any real enemies yet. ---- OK, enough warnings and on to the info. While what you are planning isn't that bad of an idea, (here's a link to a web service that does just that.) before building your own I'd read up on User Enumeration and Session fixation attacks as well as reading up on answers to this question at (link to this very question being answered here and as well here). The TL;DR for that is that you are introducing a single point of failure, and there are several different ways to exploit it that you probably have not thought of yet. It's for this main reason I use other web services for my logins; they have more resources to work out all of the possibilities -- also, if they DO get hacked it's on them and not me or my client. It's true that Omni-Auth, which is the "sign-in by third party" mechanism I use, is most popular for signing in with Google or Facebook; but it can actually use MANY different options (See list here). While in the past I've been too busy to add more than Facebook or Google for my own sites, on my next project I'll be adding Twitter, Github, LinkedIn, Instagram, and StackExchange. (If one of those doesn't work for the user or dev, there's still a lot of options.) Most notably, it's still the most secure option available for protecting users and devs. I also highly recommend watching Tom Scott's (Computerphile) videos on Youtube for overviews on "Why to never take passwords" and a few others on things like "SQL injection attacks" to get a better overall idea of what exploits can be used against a site and it's users. Watching just the exploits demonstrated on that channel should be enough to scare the hell out of anyone thinking of making their own (or bypassing an) authentication system. In summary, while yes you can very well do it, it's almost certainly a bad idea unless you've done a ton of research and thought through every potential possibility. But if it's for a very small site that really doesn't need much security, you can probably get away with it. Just keep in mind that if your site/game does get really successful or gains a huge user base, you'll be scrambling to replace it with something more robust and your users may not react well to the change. I certainly hope I've at least provided some useful information on this topic. Good Luck!
  5. Greetings! Play tested using Chrome on MacOS Mojave. The engine itself ran at a good frame rate, and it was a large map to explore. I never ran into any of the "Bat" enemies, but I did find several power-ups. I didn't figure out how to use the potions that I found in the level, so it might be a good idea to add more information about the controls. Also, the static objects (other than walls or stairs) didn't appear to have any collision. It could still use some work, but looks like a good start. Good Luck!
  6. Nice Game! I've often considered games that flip the morality of the story around to make the protagonist the villain to be more congruent in their narrative. Too often games go out of their way to explain that you are to be the savior of it's mythical land, only to then send you out on a protracted murder spree. As in "You are the hero of light and goodness, now go forth and KILL EVERYTHING THAT MOVES!" So if your character is going to be a violent war-monger, it actually makes more sense to be the bad-guy of the story. I realize you are working with what probably amounts to place-holder graphics, so I'll focus on the gameplay, which was pretty cool. The game performed well, from controls to frame rate and stability. And it was quite fun to wipe out the elves, and the nature kingdom. (I was actually disappointed to find that dwarves and humans didn't have a kingdom to wipe out yet.) The first time I played it a few days ago, the keyboard controls were VERY slow, but when I gave it another try today it was perfect. I'd say the gameplay and difficulty are pretty well balanced, and was rather fun to play. (With the occasional "Mwuhaha" of laughter.) As for what to add, there's obviously a lot. A mini-map would be a great addition to start. Higher quality sounds and more miscellaneous decorative items would be great to keep it from seeming too repetitive. Finally, a few death animations for the enemies would really ramp up the malevolent feel of wiping out the forces of goodness. I had a lot of fun with it. Good Luck!
  7. Greetings! The promo's look very good; I like the art style you have. Good Luck!
  8. I decided to do some digging into all of the talk on this forum about GameDistribution and their practices. Here's a link to the thread where I posted what I found:
  9. I decided to investigate some of the info I've been seeing on this board about GameDistribution. Here's a link to the thread where I posted what I found:
  10. I love a good online mystery. (a guilty pleasure of mine, I must admit.) So I decided to do some digging. pro style. Here's what I found: As for the origin of the company being in Turkey, there is some credibility to that, as can be seen on their LinkedIn account. (See Screenshot) They also have taken some serious liberties on their Github account, like with Phaser. (Not forked, straight up lifted- see link and screenshot) Their domains are protected from whois search for registrar info with a solid lock, so it would cost money to actually find any previous records. And the venturebeat article linked to above is valid, so they obviously are not strapped for cash in any way that would prevent them from paying devs. Finally, to address their complaint to bestgames above to not give out their personal info, maybe a better solution would be to just pay the devs that have been helping you make so much money that you can buy other companies with it? I've provided screenshots because I've noticed their account on here is actually following these threads. (You can see that on people's profile pages, you know?) I hope that helps people with their assessment of their available options for online distribution. EDIT -- February 4th 2019: I've recently noticed that they've taken a sudden interest in my online profiles after this post. (See screenshot) And I don't think it's to see if I want to submit games.
  11. has game tutorials for android, javascript, iOS, etc. It's a free site (You can also pay to get certified) that's sponsored by companies like Sony, Google, etc. I'd highly recommend to any starting dev. Link here.
  12. Greetings! As an app developer (I make games for my portfolio because my clients usually have me under non-disclosure agreements) I agree that it's pretty trivial now to add SSL to a website. I've made apps that are hosted on Digital Ocean that use LetsEncrypt for SSL, and I've been brought in to update Wordpress sites to using SSL. So I can say from experience that adding SSL to most sites has become much more accessible, and that's it's a prudent move for almost any site. Google has gotten downright militant about it recently, both for their search engine and the Chrome browser. (Something that has brought me more business as a freelancer updating sites that didn't want a big "Not Secure" message chasing off their clients.) To be fair, it's still the responsibility of any competent dev to not use the same password on every site(Hell, use a password manager already), and for sites that don't take any form of payment info the biggest drawbacks of not upgrading are the possible loss of user passwords and the cosmetics of how their site shows up in the browser. I would suggest that any site do the update to SSL, just for the bonus to reputation. But I also suggest to any of my clients that I work for to NEVER take passwords anyway; it's a huge newbie mistake to do so. But don't take my word for it; here's Tom Scott's video that's a classic on the subject.
  13. Thanks! I really love your library (I've seen your contributions on Github) and after making several HTML5 games from scratch, I'll be using it for my next project. I believe porting them to Ruby Gems will make the library more accessible to a wider range of developers, and easier to integrate with databases. This can have the added benefit of providing more security for HTML5 games made with pixi.js. (See my response to protecting games from piracy in this post.) Also, RubyOnRails has built in web-sockets, so when combined with database functions, it's trivial to build more advanced games like MMO's with it. (Here's an example of one that I made from scratch posted to the game showcase here.) It also works with Omni-Auth (Signing in with Google, Facebook, Github, etc) which is more secure and accessible for users than taking passwords for logging in. (Tom Scott has a great 5 minute talk on Youtube on why you should NEVER take passwords here.) I know that's a lot of links, but this is something I've been thinking about for quite some time, so there's a lot of planning and thought going into it. Most of all, thank you for the feedback and support, and all the hard work you've put into this library. I plan on doing a demo and Youtube tutorial in the next few days, and I'll be plugging the pixi.js library enthusiastically with it.
  14. Unfortunately, such measures could easily be disabled by searching through the code for the functions and disabling them. Even with minimization and obfuscations (like Uglifier for Javascript, which I would still use) it wouldn't be very difficult to scan for such options, because the text strings would still show up as plain text in the code. The best method I've been able to come up with, after tons of research and years of testing, is to not expose your complete dataset with the use of a database. If you have all of your code in one, easy to copy file it's trivial to copy and pirate. But if your code loads incrementally from a database that is secured with a login and is dolled out as players progress through the game, or it loads variables/values from the database at certain points the attacker would basically have to build the game themselves incrementally. (Not impossible but it would make you a very impracticable target and less likely to be victimized.) Login solutions like Omni-Auth (signing in with Facebook, Google, Github - see link here) can allow you to let users log in without having to make an account. (Link to one of my apps that does that here) You could still provide a demo with limited progress to casual visitors who wanted to try out the game, but require them to sign in to play further. This is one of the primary reasons I'm porting the pixi.js library to gems that can be used with RubyOnRails, (See post here) to provide a method of easy database integration for developers who want to protect their games. (There are others, but RoR is very easy to learn for simple apps.) I hope that helps shed some light on the situation and helps provide solutions. Good Luck!
  15. And one more for now! We now have pixi_sound available for bundling on And the links are: That will be it for now; while I really want to add pixi_ui, it's listed as a WIP so I want to do some testing before trying to compile it into a gem. I was also considering tilemap but currently it's an absolute mess when it comes to iOS performance (6-10 frames per second under the best of conditions), so I'll be coding my own tilemaps for now. As for any of the other components, I'll wait until I have my next demo built; but if anyone specifically needs one before that, just message me or comment on this post and I'll put it together. Wish me luck on building one hell of a RubyOnRails pixi.js demo this weekend!