2 replies to this topic

[cirenehc]

Hello everyone, I'm not new to programming, but I am a newbie to game development. I took an undergrad course in computer graphics (not long ago), so I have a very basic understanding of how games are made. It's been my childhood dream to create a game, and I think this is a good time for me to start chase after that dream.

The last time I've been to gamedev.net (like a few years ago), I remembered there was a subsection on the forum for isometric games. I could not find that subsection this time around, so I decide to post my question in the second most appropriate section (i.e., here).

Long story short, I have a game idea in mind that I want to implement. And I have 2 requirements for this game:
1. This is going to be an isometric-like game. I used to word "like" because I'm also fine making a 3D game with a non-moving camera, which looks similar to an isometric game.
2. I want this game to run in a web browser.
- I was thinking of using Unity3D or html5 for this, unless someone give me a good reason to use flash (i.e., it's 100x easier to make it in flash). Keep in mind that I have no experience in Flash

Can anyone give me some ideas of what technology I should use (game engines, etc)? And what are some good resources for beginners trying to make isometric-like games?

[stormwarestudios]

If you're building a game for the browser, then there are two major factors you need to key in:
1) You'll have to master JavaScript
2) Putting all your logic in the front-end makes your game significantly more hackable.

There are alternatives to #1 (ActionScript being one of them; I feel this is a technology which is losing traction to HTML5 so can't recommend going this route). Google's Native Client would also be a good bet, since C code becomes reusable; this, however, is even more bleeding-edge than HTML5 game development, and its future is highly uncertain.

As for #2, the main option is to put game logic in the back-end, and link the browser game client via some means like XmlHttp requests, WebSockets, and the like.

I've gone the Canvas+WebSockets client/server route, upon which I'm basing TGE's development (link in sig). Game development in this fashion is in its infancy at best, meaning there aren't complimentary libraries (higher-level network messaging, stateful machines, sprite animation, level formats or generators, user interface widgets, and so on), but I'm slowly working on them.

Flash/AS, obviously, give you a neat little black-box SWF, user interface, and (probably) established game engines (see these 11) already, but the trade-off is (what I refer to as) a dying technology (YMMV). It's really a matter of what you want to accomplish moving forward.

Drop me a line if TGE interests you.

[cirenehc]

If you're building a game for the browser, then there are two major factors you need to key in:
1) You'll have to master JavaScript
2) Putting all your logic in the front-end makes your game significantly more hackable.

There are alternatives to #1 (ActionScript being one of them; I feel this is a technology which is losing traction to HTML5 so can't recommend going this route). Google's Native Client would also be a good bet, since C code becomes reusable; this, however, is even more bleeding-edge than HTML5 game development, and its future is highly uncertain.

Native client currently supports Unity3D, that's why I'm looking into this as well. I'm also quite proficient with Javascript and other web technologies (canvas, websocket, etc). FYI I'm currently doing a PhD in web security

Secondly, I've looked into HTML5 game engines, and non of the free ones look "visually" appealing to me. I am very interested in TGE, so please give me some details on this. Thanks