Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Feb 2005
Offline Last Active Feb 19 2016 09:55 AM

Posts I've Made

In Topic: Is HTML5 a legit language for developing game?

24 January 2014 - 10:24 AM

I actually just wrote a blog post about this. Simply put, HTML5 is definitely legit, but write HTML5 games for that purpose. Intend them to run in browser. Don't try to replace an otherwise native app or try to make the next CoD in JS. I'm mainly a C++ guy, but I wanted to give it a shot, so I'm currently writing a small JS game with pixi.js. I'm impressed, but it's definitely different.


I saw some engine says it can port its game to html5 and even put it in Android/iOS wrapper. The boast seems quite questionable but also brought me some hope...

Don't do this. The performance of UIWebView is not the same as the browser. Chrome for Android is amazing though.


HTML5 for game development is something to stay well clear of, unless you're ready to waste a bunch of time and meet with frustration. I have developed many games in Flash and some in HTML5/JavaScript, some of them being direct ports of each other, so I've had lots of time to experience the broken promises of the HTML5 "standard".


If you're just looking to play around, HTML5 and JavaScript are probably the most accessible (you need a browser and a text editor), but I would highly recommend taking those skills and transferring them to something like ActionScript or even Java. C++ is a great language for sheer performance but it requires a learning curve.

It sounds like your attempts haven't been very recent. Even in just the past 6 months HTML5 support has grown. It is just as much capable, if not more, than Flash now, and it's going to continue to grow.

I reccomend playing around with all those languages regardless, though! biggrin.png


As to the original poster, HTML5 is OK for simple interfaces but once you get to "real" game development, it could be cumbersome. Keep in mind that a ton of people are stuck at IE9 which has problematic support for HTML5 and (as we found out) WebSockets. 

IE has always been a problem to web developers in general. I honestly wouldn't even worry about it. Anyone using IE9 (or IE at all) probably isn't looking to play web games, and if they are, they should upgrade. That is like supporting iOS1 when releasing iOS games.


HTML5 is okay for basic games with minimum animations for Desktop. Its mobile support is very poor and kills mobile battery as fast as Flash did. If you want something really performant, cross platform and as easy to develop as JS - you always have Flash here. Stage3D and ability to make as performant as native games on mobile due to underlying OpenGL-based rendering system is astounding. It won't go anywhere anytime soon, despite everything doomsayers have been telling us for 10 years.


The bottom line for me is that after a while, HTML5 Audio will be sorted out and HTML5 games will work fine on mobile, whereas native Flash is basically banished from mobile now that their last major hold-out, Android, dropped native Flash support a while back. HTML5 is going to continue to get better and better, but Flash isn't coming back to mobile outside of AIR packaging. Is Flash "dead" or "dying"? Of course not, and it likely won't be for decades. But the days of 95%+ installbase on all Internet-connected devices is long over. 

I forgot about AIR and Stage3D. I've always been an advocate of "Flash is here to stay," but I'm on the other side now. You bring up good points, but Flash in browser is definitely on the way to retirement. If you're new to either at this point, and trying to decide between HTML5 and Flash, I vote HTML5. wacko.png

In Topic: The great GD.net collaborative coding horror experiment? (...and the results...

02 December 2013 - 07:14 PM

It was fun! Would definitely try to contribute more if there's another one.  As for why I didn't contribute more (I wanted to do more than I did), the biggest issue was I personally didn't have enough time (I would assume similar for others as well). I know that's not what you wanted to hear, but it also ties in with any "structural" problems I noticed. If I had infinite time and less other priorites, I would've done way more regardless.


I mostly agree with swiftcoder, see my comments below.


I hope i didn't alienate anyone away with some of the contributions i made, i know a couple of them were rather large compared to other people.

Not to call you out slicer, but your large commits were part of the reason I didn't do more later on. They were great! =D Just too much at once. There were some others as well, but towards the end you were doing most of the commits (which were rather large lol) with my adding some effects. I didn't have much time to put into it as I would've liked, and anytime I checked back it was a huge change. More to absorb and think about, rather than just playing for a few minutes and making some small updates.  Although I guess this would be just as much of a problem for someone only checking every few days or once a week. unsure.png




Anyone want to chime in with  any structural reasons why they ended up choosing not to contribute despite earlier enthusiasm. By structural, I mean reasons related to the running of the experiments and not on personal reasons such as free time, etc.

I think the specific framing of the competition discouraged me from contributing more than trivially:


- Managing the source code via the forum was a tremendous hassle compared to using git, and it just wasn't worth going through. In particular, making a change, refreshing the page, and discovering that you needed to manually rebase your changes on someone else's was just untenable. Anyone on this forum should be able to use/learn git, and I don't think we should be ignoring the right tools for this sort of thing.


- The competition was pitched more as a coding horror than as an effort to develop a complete game, so I was caught off guard when people started taking it seriously.


- The rules favoured very small incremental changes, and I didn't see a path to adding features that way. Major changes seemed against the spirit of the competition, so I didn't add any features in the end.


I didn't really have a problem with the forum commits, and someone did start a repo (though it wasn't really maintained). I wouldn't have a problem with git being a must for the next one though.


As for the horror aspect, I think the horror was more supposed to be the mashup of code snippets, not the game itself. Either way it was stil fun! 


Going back to the commit size, I think smaller commits should be more enforced. Anytime I'd check with an idea of something to add, when I had time to later to do it someone had added it already. I was going to do a surprise physics update near the beginning but I was beat to it. Then I wasn't sure what to do next, and my ideas would get behind. I was going to add text support before that update was rolled out lol. I thought to add these things because they were small and quick, but essential systems. All the while, each commit adding these features would change gameplay as well. I ended up mainly just adding effects systems that weren't there yet. I think it should be limited to adding a single feature or small amounts of changes. I'm not picking any names this time tongue.png but a lot of updates would add some subsystem as well as update gameplay, change some previous functionality etc. Just made it harder to keep up with in the time I had. I feel if commits are more limited, even with more activity, less will change with time. This would obviously take longer to complete something playable and fun, but I think it would give more chance for people to contribute what they can. Plus more contributers with small changes + different coding styles = lots more horror! =]


Also, with larger updates, a lot of gameplay is more the result of one person's idea. This only allows further building on it, and that can only be done so much for any game, really. You also have to "adjust" to that thinking to come with further good ideas as well. Not that this is necessarily bad, but if more people contributed smaller gameplay elements, I think it would be able to evolve more with less effort from each contributor.


It was fun though, and everyone did an awesome job! biggrin.png

In Topic: Coding horror experiment in C++

27 November 2013 - 12:23 PM

Quick question: Anyone have this stored in a version control system, like Git or SVN? It may be possible that within 2 posts, there may be many additional edits/changes that we may not know of.



It hasn't been updated recently though... sad.png


Are you talking about splitting the code and resources in two?

In Topic: Coding horror experiment in C++

20 November 2013 - 05:34 PM

This seems to have fallen to just you and me slicer (mostly you haha).


Anyone else gona add more?

In Topic: Coding horror experiment in C++

16 November 2013 - 12:50 PM

Getting post too long for the resources...


So i uploaded the resources as a txt, and the whole file like slicer did.