Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Oct 2009
Offline Last Active Oct 22 2016 07:10 PM

Posts I've Made

In Topic: Let's talk on how to make a product builder game?

01 March 2015 - 11:05 AM

html5, canvas2d, webgl and SVG


Pretty much what I would suggest, based on the description of the kind of thing you're looking to build.


Assuming you only need 2D, you can also consider using a framework such as paper.js, which sits on top of canvas but also provides some abstractions for scene management.


If you need 3D, you might want to look into babylon.js or three.js.

In Topic: Can someone give me a quick code review for HTML5 site?

23 April 2014 - 05:04 PM

You didn't include the .sln or the .csproj files as part of your commit - so it's impossible for anyone reviewing this to actually be able to compile and run your project. Without that, we're limited to just looking at the code and guessing at what it's supposed to do and how it's all supposed to fit together.  I suggest you grab the .gitignore file from here:




Save it to your project root, and then commit anything that it doesn't filter out.


Also, are you using ASP.NET MVC proper, or are you using ASP.NET WebForms but with an MVC-like architecture?  I can't really tell because you got .a cshtml file with what appears to be Razor syntax, and you're calling it the "controller" (slash "code behind").  Controllers should have a .cs extension (they're classes that inherit from the Controller class, and have methods that return ActionResults), and they shouldn't have Razor in them - so that really looks more like a view. Also, there is no concept of "code behind" in ASP.NET MVC.  So I'm guessing you might be using WebForms?  But then you would have .aspx files, not .cshtml.  So in short, I'm a bit confused - you seem to be mixing or misusing frameworks here.  Or maybe it's me who's losing my mind.  (Please inform me immediately if that appears to be the case.)  If you're intending to use MVC, then I strongly suggest you work your way through some tutorials first.

In Topic: Looking for guidance for web-based game/platform development

05 December 2013 - 07:43 PM

So, to clarify, are you looking to make an HTML5/WebGL game engine (along with a proof of concept game)? Or something more like GameMaker, where people can design games using a simple drag-and-drop style interface without code, but web-based?  Or are you just looking to make a basic proof-of-concept game that's open to expansion?


As far as game engines go, you should check out Babylon.js.


I'm sure there are good examples out there of something closer to GameMaker, but perhaps someone else could speak of those - I haven't tried any.


As far as proof of concept style games, check out BrowserQuest.  There's a forkof it on GitHub that's still under active development.

In Topic: Progress Bars

25 April 2013 - 01:58 PM

There is an art to making good progress bars.  It takes a lot more time and effort than anyone is ever willing to put into it, and as a result they are often overlooked.


There is something inherently pleasing about watching a good, well-designed progress bar load to completion.  I've thought about this quite a bit before, and for some time, I've become rather obsessed with them.  I would download and install a bunch of things I didn't need just to watch progress bars.  I share my conclusions below.


The motion of an ideal progress bar should resemble the plot of a novel.  It's not terribly interesting to watch a progress bar zip right through to the end without encountering a hint of difficulty along the way.  Would you enjoy reading a novel that didn't have a plot or an antagonist?  That would make for a boring novel!


The progress bar should start off confidently, ramp up some speed, but slow down around 15-30%.  It doesn't mean stop - you don't ever want a progress bar to stop entirely - but it should start to visibly struggle. It should not stutter or jump around violently or go backwards or anything like that, but its progress should become unsteady.   It should come in waves.  These waves should build up overtime.  It you got some things you need to load that you're uncertain about time-wise, the 30-80% range is the ideal time to load those things.


The climax portion is the most important part.  This is where shit gets real.  You should slow that sucker to a crawl (but don't you dare stop it entirely or I will find you).  If you're printing out any sort of details about what's loading, this is the part where you start spitting them out rapid-fire.  Make it up if you have to - write you're "Reticulating splines" for all I care - if you do it right, I won't have time to read it anyway.  If you're thinking about writing to the hard drive, this is the time to do it - make some noise with it.  If you don't have anything you need to write, implement a hard drive stress test algorithm and run it during the 80-95% range.


Don't you dare let me down in the last 5%.  There is nothing more disappointing than a progress bar that just disappears when it reaches 99%.  If you do this, I will go to your house and tear out the last page of every book you own.  If you get nothing else from my rambling, at least remember this, because it should be relatively easy to implement, but it needs to be done deliberately: Pause - for just a brief moment, pause when you reach 100%.  Will you promise me that you will do this the next time you implement a progress bar?  Just put a Thread.Sleep(500) in there once you get to a 100%, that's all it takes - but it makes all the difference in the world.  Don't make it too much shorter than 500 ms, or it will look like it just disappeared, but not too much longer, because you never want a progress bar to hang.  A half-second delay to give some closure to the ordeal, that's all.  Please do it.


So there you have it.  I hope we can all walk away from this being slightly more attentive to these finer details of the user experience and give progress bars the attention they deserve.  Thanks for reading.

In Topic: Have I missed anything?

30 March 2012 - 01:14 PM

Sounds like Mozila though came up with an HTML 5 / JavaScript MMO called BrowserQuest. Perhaps we could leverage that to make the hockey HTML MMO Posted Image

We should do this! Then, we should dig up that legendary old thread (does anyone remember the username of the guy who wanted to do this?) and tell him he's not crazy after all.