Main Project Step 1 - Describe Your Game


Now that you know some of the basics, it's time to start thinking about what kind of game you want to write.  Your goal should be to finish a playable game by the end of the course period (6 weeks from today - June 6).

Don't pick something too elaborate like a huge complicated MMORPG - you'll never finish!  Pick something you know you can finish instead.  For example, think about taking a classic arcade game and putting your own unique spin on it.  A puzzle game, a run-and-jump platformer, or a simple turn-based strategy game (think RISK, not Civilization 5!) could all be good choices as well.

Multiplayer will be a major focus of the course, so you should plan for your game to have a multiplayer element.

For next week (May 2), write a paragraph describing the game you'd like to create and share it with the group.  Break your idea down into small parts and write out what you'll need for each one - what sort of player input will you need to respond to?  What sort of animation will you need?  What about background images?  What's the goal of the game?  If it's the sort of game that has enemy characters, what will they look like and how will they move?  Will you need some sort of AI controlling them?  Are there pieces that move around in real-time, and if so, are they affected by gravity or collisions?  Etc.  Describe the multiplayer elements - is it a head-to-head game where two (or more!) players compete against each other?  Or a cooperative game where two or more players have to work together to reach the goal?

Diskutera uppgift


  • Jason   11 maj 2011 23:31

    The game I had in mind was something similar to the arcade game "Metal Slug." 

    If you are unfamiliar with Metal Slug, it is a sidescroller where you can shoot various types of weapons, for example a pistol, machine gun, or rocket launcher, and try to get to the end of a level and defeat the boss. You get a certain amount of lives and the weapons you pick up as powerups with a set amount of ammo.

    My game will have the same basic mechanics, go through a few levels while being to able to upgrade weapons and defeat enemies and a boss. I would love to be a able to do co-op, but not a necessity. Another aspect I want to eventually do (not necessarily in the time frame of the course but possibly after) is an RPG element. Where you can level up and possibly choose different powers, like extra health or damage for a small amount of time on a cool down, or have the ability to level up a weapon, after you kill x amount of enemies with the pistol you can increase the capacity of your clips, or something similar. Currently I want to implement a single level but I do want to make it extensible, so I can continue to add levels, just a matter of coming up with the content.

  • Jono Xia   12 maj 2011 16:53
    Som Svar På:   Jason   11 maj 2011 23:31

    Hi Jason,

    Cool, sounds ambitious!  For the course you should probably focus on the basics -- the first level, a couple of different weapons, and maybe a single boss fight (gotta love giant screen-filling bosses with hidden weak points, right?).

    If I remember Metal Slug there were a LOT of projectiles in the air at all times, so your biggest challenge may be getting the performance of your physics engine and hit detection to be good enough that the game remains responsive even when there's tons of bullets on screen.

    Anyway, since quite a few people seem interested in making side-scrollers, I think one of the next code samples that I put up will involve scrolling the screen in two dimensions.  You may find it of use.

  • Tiago Garcia   10 maj 2011 01:28

    My thoughts are within a game where would like Super Mario fleeing from the Boo ghosts.

    The ghosts would be alive, they would be many, on different sizes, with independent movements and so. They would go after Mario when he isn't looking at them.

    They will keep appearing at a certain number of seconds. And if they touch Mario, he will die.

    The objective will be kill the ghosts, maybe trapping them, throwing someting onto them, or even performing a power-jump over them, I am really not sure yet. 

    For each ghost killed, Mario will add some points. After a certain number of ghosts killed, the stage will be completed.

    The next stage can have a different scenario being a little more difficult in terms of obstacles and so.

  • Jono Xia   11 maj 2011 19:08
    Som Svar På:   Tiago Garcia   10 maj 2011 01:28

    Hi Tiago,

    Did you ever play the original Mario Brothers (no "Super") -- I mean the one that came before "Super" mario brothers?  Each level was only one screen and you cleared out all the enemies to advance.  The 2player mode was really fun because you could help each other but you could also get in each other's way so it required a lot of "No, i'll go THIS way, you go THAT way" coordination.  Your idea is reminding me of that.

    Are you thinking each level is just one screen, or is each level a region that can be scrolled?

    You might want to talk to Slava, who is also writing a side-scroller -- the two of you will have to solve similar problems, so you might want to share tips as you start working on your game engines.

  • Tiago Garcia   21 maj 2011 08:41
    Som Svar På:   Jono Xia   11 maj 2011 19:08

    Hi Jono,

    You gave me a nice idea. I will really try to insert the side scrolling on my game, thanks! :)

  • Rick E   9 maj 2011 08:40

    I'm planning a wilderness survival game where the player is shipwrecked on a deserted island and needs to locate the necessities of food, water, and shelter to survive. Of course the island will be unexplored at the start of the game, so the player will need to move around the island to reveal the map, and locate resources. Some items will be craftable (think stone tools, spears, vessels for carrying water, etc). Each action will cost energy, which will be restorable via eating, drinking, and resting comfortably. If the player is unable to find/catch food, strength will decrease and the downward spiral could end in a horrible wasting death. 

    I'll need to find a way to place resources (randomly would be nice, for replayability) on the map at each location. I'll need a way to reveal portions of the map once explored (and if a mountain is explored, that should reveal a good portion of the map). I'll also need to track player inventory.  Player input will be primarily through clicking on buttons for N, S, E, and W movement, but on entering any map square the resources of that square should be revealed to the player, and any options specific to that location should be presented ("Climb tree to gather bananas", "gather sticks for use as firewood", etc)

    I'm thinking the gameplay will resemble Zork (if anyone knows THAT name you're older than me!) with a graphic interface.

  • Jono Xia   11 maj 2011 19:00
    Som Svar På:   Rick E   9 maj 2011 08:40

    Hee hee, I love Zork!  I never finished Zork 3, though.  The cloaked figure in the shadowy land completely stumped me.

    Anyway, it sounds like your game is mainly exploration and resource management so it won't need fancy animation or real-time physics.  But you will need a good object model of the hidden parts of your world, and you'll need methods that modify the available interface (adding/removing buttons) in response to the square the player is on.  There's an assignment this week to plan out the objects that will make up your world model; I hope that will be a helpful exercise for you.

  • Jono Xia   11 maj 2011 19:04
    Som Svar På:   Rick E   9 maj 2011 08:40

    P.S. like I'm saying to everybody -- you should think about how this will work multi-player.  (Maybe different players start out in different places on the island, but if they meet up they can see each other's maps and trade resources?)

  • Krabat   8 maj 2011 07:36

    I came the long way from a C64 being the first computer of my own. And maybe the times were different, but there were many games which were really great. That's why I want to do Space Taxi, a simple arcade game from 1984.

    For those who don't know the game, you can take a look at the gameplay(youtube, actually starts at 0:42):



    For the parts of the game, the space taxi itself is affected by gravity, so maybe I have to include some kind of physics engine, but maybe that's just overkill... The levels should be pretty basic with some moving stuff in some levels of the original, which destroys the taxi if they collide. Also, the taxi has a fuel limit, which has to be comsumed and can be replenished at certain pads. Some sounds would be nice, the C64 game featured differently pitched speech samples :)

    All in all, I think this sort of game can be accomplished in the given time and will be fun to create (and hopefully as much fun to play).
     

  • Jono Xia   11 maj 2011 18:56
    Som Svar På:   Krabat   8 maj 2011 07:36

    Hi Krabat,

    I've never played Space Taxi, but from watching the video it doesn't look like it will be too hard to implement a physics engine for it.  ("Physics engine" doesn't have to mean something hugely complicated and NASA-worthy).  Looks like the taxi obeys gravity and inertia, and you can apply thrust in different directions which costs fuel and creates acceleration, right?  We'll cover all those techniques in Week 4.  You'll be able to do speech samples with the html5 <audio> tag, which we'll cover in Week 6.

  • Anonym   6 maj 2011 10:06

    Hi everybody,

    What i want to make by the end of this course is a version of the classic game Space Invaders. I would like it the have some good graphic effects and smooth movement for all the objects (aliens and the space ship). Additionally, i would like it to have a few levels with different level configuration and difficulty.

  • Tyler Cipriani   6 maj 2011 10:09
    Som Svar På:   Anonym   6 maj 2011 10:06

    Love Space Invaders! Check out some inspiration here: http://10k.aneventapart.com/Entry/392 this was a coding challenge to create a funcitonal webapp using under 10KB - it's called 'RGB Invaders'

  • Anonym   9 maj 2011 18:20
    Som Svar På:   Tyler Cipriani   6 maj 2011 10:09

    Hi, thanks for the link!

    I Checked it out (and played it too). It really looks good. I hope i can do something similar. However, i would like to add some bricks where the space ship can hide from the enemy fire and make the aliens move down continuosly.

  • Jono Xia   11 maj 2011 18:50
    Som Svar På:   Anonym   6 maj 2011 10:06

    Hi Shadowplay,

    Nice.  It sounds like you and Tyler will have fairly similar projects, so what I said to him applies to you too.  The two of you shoud keep in touch and share tips as you start working on your game engines!

  • Kajan Sivaramalingam   5 maj 2011 20:53

    I still donno exactly what I want. But I want to make something challenging. For the moment I got two projects in mind :

    Something like Street of Rage, a megadrive 2d action game.

    You walk in the road and have to beat villains. The scrolling is mostly horizontal, with just a little vertical scroll to emulate the depth.

     

    Or an 2d fight game, like street fighter and all those things.

     

    I would love to hear your opinions on those two projects.

  • Jono Xia   11 maj 2011 18:46
    Som Svar På:   Kajan Sivaramalingam   5 maj 2011 20:53

    Cool idea -- I haven't heard of any fighting games in HTML 5 before.  This will be an ambitious project but possibly doable.  You might want to focus on

    Key for making a fun fighting game is to have very, very responsive controls and very good hit detection.  (We'll cover hit detection in Week 4- Physics Week).  You might want to start out by making the controls for a single player character, and create a single (passive, indestructable) enemy character to punch and kick, just for testing purposes until you get the controls and the hit detection working to your satisfaction

  • Kajan Sivaramalingam   14 maj 2011 12:31
    Som Svar På:   Jono Xia   11 maj 2011 18:46

    Yeah hit detection and fluidity will be the trickiest parts of my projects.

     

    I will test something as soon as I can. For the moment I would focus on catching up my late in the course.

  • Tyler Cipriani   5 maj 2011 00:45

     

    The simplest explanation of my game is that I want to completely rip-off the classic Namco/Midway game Galaga. The game is a quintessential shoot 'em up - a single player controls a spaceship positioned at the bottom of the screen. The background of the screen is a starfield that moves from the top of the screen to the bottom. The screen at the beginning of each level starts out empty with enemy spacecraft flying onto the screen in formation. Once all of the enemies have populated for a particular level the enemy spacecraft will dive-bomb and shoot at the player. The player is allowed to shoot at the enemy spacecraft at all points of the level and once all enemy spacecraft have been destroyed the player moves to the next level.
     
    It should be noted that throughout the previous paragraph I've heavily plagerized the wikipedia page on Galaga - available here
  • Jono Xia   5 maj 2011 01:50
    Som Svar På:   Tyler Cipriani   5 maj 2011 00:45

    Hi Tyler,

    Alright, classic gameplay!

    For you I think the main issue will be to get the animation very smooth and the controls very responsive.  The type of game you're going for has a lot of moving sprites on the screen at once, between waves of enemy characters and all the bullets that the player ship is spitting out.

    How will the player control their ship in your version?  You can't count on a joystick so you'll have to settle for mouse or keyboard.  Which will it be?  Either way, you could take what you've already written for assignment 2 and modify it by restricting the y-coordinate so that the player ship can't move out of the bottom region of the screen.

    One of the assignments this week will be drawing backgrounds using Canvas.  It will be a perfect time to do your animated star field!

    Could there be a multiplayer component?  I know Galaga only had one player at a time, but I am hoping to get everyone to try writing some networking code for multiplayer features.  How about it?

  • Tyler Cipriani   5 maj 2011 09:16
    Som Svar På:   Jono Xia   5 maj 2011 01:50

     

    Player controls are going to be keyboard based since I feel you get more control that way - arrow keys and spacebar all the way. 
     
    I'm down to try a multiplayer component - it could add some interesting complexity to Galaga that wouldn't have been possible before. I think 2 ships in the bottom fixed position would be good - any 'friendly fire' elements would, I think, make the game overly challenging. The ships should be able to pass over one another with no collision - it's the vast emptiness of space after all!
  • Andrew Shindyapin   3 maj 2011 00:12

     

    I've actually started working on a game last year, but  stopped developing this game is because I got stuck on how to architect the game in a way that would allow rapid addition of levels to it.

    The game has the first 'level' or lesson completed and online here, is for pre-schoolers who want to learn the Russian language. It is a combination of starfall.com ABCs, a Russian-alphabet learning method called ?????? ??????, and other ideas. At this point, the logic is really simple, although I want to add sever other things eventually--specifically, I want to add an unhealthy amount of stats for the concerned parent, as well as the supermemo/spaced repetition method for faster, more effective learning.

    Right now, the plan is to have a slide (as in slideshow) loop that is within a lesson loop. I am working on a more comprehensive, step-by-step task list.

  • Jono Xia   5 maj 2011 01:45
    Som Svar På:   Andrew Shindyapin   3 maj 2011 00:12

    Hi Andrew,

    If you want to continue with that idea, then you won't need to worry about physics or multiplayer.  But in order to easily add more "levels", you will need to think about how to represent the contents of a level purely as data.  I am thinking that it may make sense for your client code, running as javascript in the page, to query the server using AJAX in order to retrieve more chunks of content, i.e. retrieve each level, from the server.  Then you can have your content stored on the server, either in a database or in files, broken up however you see fit, and you don't have to worry about cramming all of it into a single page!

    To do that of course you have to figure out how to represent a level's contents as a document -- either XML (for the X in AJAX) or better yet JSON (which is smaller and easier to parse in Javascript, yet capable of carrying any information an XML document can carry).

    That's all the advice I can offer at the moment since I don't know anything else about your game yet.

  • Jay   2 maj 2011 16:30

    If only I could insert some javascript here to delete that first paragraph on my previous comment... :)

  • Jay   2 maj 2011 16:28

     Break your idea down into small parts and write out what you'll need for each one - what sort of player input will you need to respond to?  What sort of animation will you need?  What about background images?  What's the goal of the game?  If it's the sort of game that has enemy characters, what will they look like and how will they move?  Will you need some sort of AI controlling them?  Are there pieces that move around in real-time, and if so, are they affected by gravity or collisions?  Etc.  Describe the multiplayer elements - is it a head-to-head game where two (or more!) players compete against each other?  Or a cooperative game where two or more players have to work together to reach the goal?

     

    I plan to make a 4 person card game called Make a Million.  There are 2 teams, so 2 vs 2.  It is a trick taking/bidding game.  Animations will be simple - moving cards from deck to the table, and maybe dealing the cards out.  Eventually I want to write an AI so you have the option to play against the computer, but I am just interested in getting the multiplayer working for now.  The background will look similar to this.

  • Jono Xia   5 maj 2011 01:37
    Som Svar På:   Jay   2 maj 2011 16:28

    Hi Jay,

    Cool!  You won't have to worry about physics like Slava will, and it's probably less detrimental to your card game if you don't receive updates from the other players for a few seconds.

    I recommend you get started by writing a really solid javascript object to represent a deck of cards, if you haven't already.  You'll need to figure out how to represent the individual cards and their order, and have methods for shuffling and drawing, etc.  If one deck is shared between all the players you'll eventually need to figure out how to synchronize the order of the cards - you don't want every player who loads the page to run a .shuffle() method on a deck, or you'll end up with four different decks all in different orders!  You may want to have the server shuffle the deck and then, when a player draws a card, have the client code ask the server code to tell it what the card is.

    I recommend writing a lot of tests to ensure that your deck-of-cards is working exactly as you intend.  Even if the tests are just appending text to the page and not doing any graphics yet, it will help you get everything correct.

    You'll also need to think about how people find partners and find opponents and get into a game session - you might need some kind of "lobby" page where players wait until there are enough of them to start a new game.

  • Slava   2 maj 2011 15:12

    I want to create a simple, yet diverse platformer. Jumping between platforms over the course of four levels, each with its unique twist of platform behaviour: (1) moving with variable speed, (2) shrinking, (3) unstable, (4) appearing periodically. Controls will be left, right and jump. Platforms will react to the amount of characters standing on them, sometimes for the better, sometimes for the worse, so both cooperation and competition will be beneficial at certain points. Bots are spawned when where's not enough players. Score will consist of achiever (finish fast), explorer (visit hard to reach parts), socializer (advance together with others) and killer (advance at the expense of others) scores. Bots will be socializers. Characters will have standing and up-in-the-air sprites, while platforms will have a single texture and will fade in and out by changes of thier transparency. Each level will have it's own background repeated along the movement direction. Nothing fancy, the most interesting and difficult part will be the last two scores' formulae.

  • Jono Xia   5 maj 2011 01:28
    Som Svar På:   Slava   2 maj 2011 15:12

    Hi Slava!

    Good idea, sounds fun!  I like that you already have a very clear idea even down to what each level will be.

    For a side-scroller, you will need a solid physics engine above all.  I want to cover game physics in week 4.  A lot of the examples will be side-scroller based so I hope you'll find that helpful.

    For a multi-player side scroller, you've got the additional challenge that data must be synchronized between the different players' browsers very rapidly to achieve real-time collaboration.  I think getting the performance good enough to enable fluid gameplay will be your biggest challenge.  You should think about what you will do as a fallback in those times when the network lets you down and you receive no updates from the other players for several seconds (an unfortunate reality that online games have to deal with!)

    Some more questions to think about -- what is the maximum number of players who can be in a game session at once?  When you join a game, do you choose whether you're joining a competitive or cooperative game, and is there a server that matches you up with like-minded players?

    We'll do networking in weeks 5 and 6, so you don't have to solve these problems just yet, but they should be in your mind.