current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 1 down vote favorite
2

So I have some free time this winter break and want to build a simple 2d HTML5 canvas game engine. Mostly a physics engine that will dictate the way objects move and interact(collisions, etc). I made a basic game here:

http://caidenhome.com/HTML%205/pong.html

and would like to make more, and thought that this would be a good reason to make a simple framework for this stuff. Here are some questions:

  • Does the scripting language have to be Javascript? What about Ruby? I will probably write it with jQuery because of the selecting powers, but I'm curious either way.

  • Are there any great guides you guys know of? I want a fast guide that will help me bust out this engine sometime in the next 2 weeks, hopefully sooner.

  • What are some good conventions I should be aware of?

  • What's the best way to get sound? At the moment I'm using something like this:

    var audioElement = document.createElement('audio'); audioElement.setAttribute('src', 'paddle_col.wav'); audioElement.load();

I'm interested in making this engine lightweight and extremely efficient, I will do whatever it takes to get great speeds and processing power. I know this question is fairly vague, but I just need a push in the right direction.

Thanks :)

share|improve this question
    
Browsers can only interprete Javascript. When you want to use another language, you need to use a transcompilation tool to turn it into Javascript code so that the browser can understand it. There are languages like Coffescript or Google Dart which were designed explicitely for that. –  Philipp Dec 18 '12 at 9:52
    
These are actually four unrelated questions and not one. You should maybe ask them as separate questions. –  Philipp Dec 18 '12 at 9:53

3 Answers 3

up vote 4 down vote accepted

Q. Does the scripting language have to be Javascript?

A. Yes. There are other somewhat supported scripting languages, but JavaScript is by far the easiest to get into, most widely supported, and most widely documented. In terms of JS toolkits available, jQuery is certainly an option. So is Dojo Toolkit; with its AMD design scheme, it's (arguably) the better choice if you're looking to develop long-term. It's the toolkit I decided to go to when developing my own game engine, TGE.

Q: Are there any great guides you guys know of?

A: Yes! The Mozilla Developer Network is a great guide on all things HTML5. It will provide you with the basic skills necessary to manipulate HTML5 DOM elements. However, game development theory is still king; you'll at least need to understand things like separating the physics and animation loops, sprite animation, scene management (yes, PONG has a scene, and there are objects in it which need management). Then there are paradigms like event-driven (vs. function-driven) programming, callbacks, the execution context stack, and so on. I'd suggest reading through The Good Parts, The Definitive Guide (if you've got time), and Patterns.

Q: What are some good conventions I should be aware of?

A: I chose the "do everything in JavaScript" path, and avoid authoring DOM elements in HTML where possible. I'm not sure if this is highly desirable, but it makes the most sense to me to keep as much in JS where possible. YMMV

Breaking down your game into Modules ("singleton"-esque interface-style, uh, interfaces like Graphics and Network and Audio) and Factories (which produce Objects like Sprites and Bullets and ParticleEmitters and PowerUps) is crucial for debugging, and important for organizing your code, especially as your project grows. A toolkit like Dojo (and to some extent, RequireJS) trumps jQuery in terms of usefulness in this regard, which is why I highly tout it.

Develop using Google Chrome, and use Chrome Developer Tools (CDT) to debug your application. Seriously. Firefox+Firebug is nice, but Chrome+CDT beats the pants off it.

Use requestAnimationFrame in your render loop.

Write your game such that it will function in all browsers which support the bare minimum elements you're planning on using. That does not mean supporting IE6, but it does mean making sure your game functions in IE9/10, Firefox, Chrome, and possibly Safari and Opera. You'll learn a lot on making your game compatible with different browsers. Don't waste your time on backward compatibility (or "progressive enhancement"), as people who are using old browser (aside from, say, your parents) won't even be looking at your game.

Trailing comma of death is your enemy.

If you're developing in Windows, Notepad++ is a great editor, and XAMPP is a great web-server stack.

If you're going to eventually write some server-side code, PHP, C#, are great options for server-side scripting languages. Other very popular languages include Ruby, but my experience is limited to the two former, so I won't comment more than that.

Q: What's the best way to get sound?

A: Support OGG and MP3, and you'll cover the bases you need to enable playback in the Big Three browsers. Create your audio tags once at application startup, keep the audio elements around a long time, and reuse them as often as you can, to avoid manipulating the DOM excessively.

Good luck, and happy JavaScripting!

share|improve this answer
    
Thanks, I've started development, I'll be referring back to this every now and then. –  Scriptonaut Dec 30 '12 at 20:27
up vote 2 down vote

The scripting language has to be Javascript or something which compiles into it. I recommend that you do use Javascript. There are a lot of problems with Javascript - such as its lack of a single standard way of "doing things". Defining classes, inheritance, modularity etc, all have multiple approaches which different authors do differently (or even a mixture).

However, if you don't use Javascript, you'll have to use a language which compiles into JS, and debugging becomes more difficult (because the in-browser debuggers can't see your original source code and therefore won't be source-level debuggers). It is likely to be difficult to debug any Ruby code which is compiled to Javascript.

I recommend you don't use JQuery because I don't like it, and it provides few useful features for game developers. Most games will use only a few DOM elements and they're unlikely to change much (if you mostly use a canvas).

As far as audio is concerned - I think you're best to test it on your intended target platforms and choose the approach which best works for you. Things change quickly, and when your game is ready for audio, there may be better platform support for different APIs.

share|improve this answer
1  
I've built the graphical user interface of my game in HTML and I found jQuery to be really helpful for that. One very nice feature is the drag&drop functionality of jQueryUI. –  Philipp Dec 18 '12 at 22:43
    
@Philipp Great if it works for you. I still feel that it's more suitable for the majority of games to just create a canvas rather than using discrete HTML elements. –  MarkR Dec 20 '12 at 13:47
    
Well, it depends on what requirements you have for your GUI. When you just need to draw the score value, doing it on the canvas would be sufficient. But in my case I require an advanced GUI with moveable and resizeable windows, scrollable text boxes, text markup, drag&drop between windows, text inputs and many more. I could have implemented those myself in canvas, but why should I when I can get them for free from the HTML engine of the browser and jQuery? –  Philipp Dec 20 '12 at 14:19
up vote 2 down vote

I'm not attempting a complete answer, since there are already two that cover the bases rather well. I'll just add the following:

  • jQuery is not a scripting language. It's a JavaScript framework/library for easing DOM manipulation and some other things, but it plays no big part when drawing things to canvas. And you want to be drawing things to canvas, maybe even with WebGL, (instead of DOM manipulation) if you want to get good performance (although CSS3D could potentially perform better than 2d canvas on some platforms). In addition, if you want to "do whatever it takes to get great speeds and processing power" you don't want to add another processing layer (jQuery) between the calls to DOM API.
  • With regards to sound effects, you want to preload them and have multiple copies of each so that you can have the same sound playing multiple times at the same time (think of a machine gun that makes the shooting sound again before the previous bullet has yet finished playing).
  • Game engines themselves are useless. You should be making a game. Only by actually creating a complete game you will know what is actually required from the engine. Then make another. After that you will notice which parts are reusable, which need refactoring etc. and the engine starts to take form. Afterwards, you can also show that your engine was capable of making these games, which will be a huge marketing point if you ever want anybody else using the engine.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.