This course will become read-only in the near future. Tell us at community.p2pu.org if that is a problem.
Learn how to make games using web standards, that will play in any modern browser, without plugins! Each week we'll investigate a particular aspect of game development -- input, animation, sound, physics, and multiplayer/networking -- and learn how to implement it using Javascript and HTML 5. Bring your own game ideas, and be ready to help your fellow learners playtest their games and figure out how to fix their bugs! I will be leading this study group for six weeks beginning April 25, 2011.
WEBCRAFT
For this week: Take the game idea you described in the previous step and begin breaking it down into objects and methods.
Figure out what the main objects in your game engine are going to be, and what sort of public methods each one going to have. Write a "skeleton" Javascript file with some constructors and prototypes -- they don't have to <i>do</i> anything yet, so you don't need to write the code <i>inside</i> them; this is more of a planning / architecture exercise.
Of course the constructors and methods you're writing now will not be carved in stone. I guarantee they will evolve as you start writing your actual game code. The point of the exercise is just to get you to start thinking ahead.
For instance: Say I was writing a turn-based strategy game where a player has some number of Units; each unit has a set of Orders that it's capable of. The player clicks on each Unit (in any order) and chooses an "Order" for each one from a menu. Once the player is happy with the orders for all their units, then they click a "Done" button. Then all of their Units will execute their Orders, the player's turn ends, and it becomes the opponent's turn.
The skeleton of some of my key constructors and prototypes might look something like this (very, very rough draft)
That the first draft of my future game engine. It's only shows the rough structure and right now the part I'm most interessted in is how to get a constant framerate, or is there no need for that?
Please feel free to comment:
Hi Krabat,
Looks like a good start! I think you've covered all of the main points in your code. One question, though -- will there be mulitple screens per level or only one screen per level? (If it's multiple, then you would need a list of Screen objects to be owned by the Level object, or something like that.) From watching the Space Taxi video I was not entirely clear on how the different screens / levels were connected to each other, but you will need some sort of function to handle moving the player from one screen to another.
As I said in my response to your post on the week 3 exercises, it's really hard to guarantee a constant framerate. But you should take a look at http://people.mozilla.com/~jdicarlo/p2pu_gamedev/example_3_4.html and http://vimeo.com/24281517 where I talk about the trade-off between slowing down animation or skipping frames while guaranteeing constant movement speed.
--Jono
I finally made a first version for my game engine. Because my code is starting to become a big mess. You can find it there :
http://kajan.siva.free.fr/game_dev/week2/gameEngine/gameEngine.js
There are still some unclear points :
- About the management of images : one image with every sprites or one image per animation or animations and image as vectorial canvas code (this one should be the coolest option).
- And my managament for keyListener is perfectible.
Waiting for your comments. Thanks
This is for your side-scrolling fighting game, right?
Doing vector graphics (canvas drawing instructions instead of image files) it will be hard to add more details beyond simple stick figures. However, the advantage is that you can get started prototyping your game without having to spend time hand-drawing so many frames of animation. So even if it's just stick figures (ctx.arc for the head, ctx.moveTo and ctx.lineTo for arms and legs), that might be the best way to do your prototype.
If you decide to use images, then I would recommend doing one image per character, with one row per animation, and each sub-image in the row being a frame of animation. The advantage here is that if you have the same frames in the same places for each image, then all the code can be the same for every character, and only the filenames have to be different.
Some things to think about:
How much code will player characters and enemy characters have in common? How about making a base class (perhaps using prototype.__proto__) to contain the shared code?
If this is one of those games where you can pick up a baseball bat or a bicycle chain and start wailing on thugs with it, you might need a Weapon constructor as well. And methods for a character to pick up or drop a weapon.
You'll need to think about how attacks are made and how to detect whether the attack connects with another character. There might need to be a Fist or Foot sub-object, belonging to the player object, with its own boundary rectangle, so you can check whether the fist/foot intersects with an enemy, and then inflict damage if it does. (So the characters will need .punch() / .kick() methods as well as a .getHit() method that inflicts the damage).
If the player can walk "forward" (down / towards the foreground) and "back" (up / towards the background) as well as going left and right and jumping, then you have a three-dimensional space even though the display is two-dimensional. When checking whether a Fist/Foot/Weapon hits another character, you will need to compare their locations in all three dimensions, not just two.
