Robot - TD

[Nick]

Html5 "Canvas" tower defense game. Made using Java Script and 'Component-based' programing practices.

This project is currently in the initial design phase.   Please feel free to contribute any way you like.


This space reserved for actual information later.

[Brad]

Currently working on a Google presentation document I figure we can use for our design doc. It ahould allow us to draw stuff out as well as including any necessary text or pictures. Starting with program flow then going into each of the different screens, drawing out all the features and listing all of the possible user interactions.

I will edit this post in a few with a link to the document. Plus I will send an invite through gmail to everybody.

[Brad]

If you would like to learn more about the entity/component model here is a good article about it http://www.gamasutra.com/blogs/MeganFox/20101208/88590/Game_Engines_101_The_EntityComponent_Model.php

[Brad]

Another good thing to be familiar with is jQuery. We'll be using it for handling user input because it is easy and cool.

On a gameplay note: For ease of uh... everything, how about having the units be able to shoot in a direction not related to their movement? The top half of the enemy would rotate allowing them to aim and shoot in 360°. This is the same behavior as units in Total Annihilation had.

For graphic assets this means that all the units (and towers) must be made up of two sprites: base and turret. You could reuse a lot of the sprite assets. A base with tank treads could be used on many different types of units with different turret pieces.

What do you guys think?

[Nick]

Are going to let shooting units fire while moving? All attacking units will have a weapon, or will some be utility units (carriers or wall-breaching ramps?) If some units can shoot while moving then having then rotate their top/turret is good. Perhaps heavier guns will need to stop before firing (rockets, mortars, cannons)

Will the players towers be destructible?  Or only the walls be? How will be stop players from blocking all access with towers if they are not destructible?

Walls being too cheap will make it too easy (slow build?) Walls being too costly will make them worthless as towers would block paths better. Perhaps some towers can only go on walls? Some towers are not blocking (they can walk between two next to each other.)

Ideas? 

[Cody]

Personally I'd say you would have attacking units and utility units like you said. Certain units (like the ones with rotating tops) could shoot while moving and heavier units must stop and be facing what they are shooting at.

As for the towers...I'd say they should certainly be destructible. If you want to keep the player from walling themselves in with towers perhaps you could make it so that there cannot be another tower directly next to it. At least one space between towers..for walls or something.

[Brad]

To make it less annoying for players I would consider having towers have a destroyed state which is passable by enemy units. They can repair the tower with a slightly lower cost of placing a new one and performing upgrades.having to do a whole bunch of extra work when a tower is destroyed would be less fun. Unless we are doing a rogue like/tower defense hybrid lol.

I think for simplicity's sake all units should be able to rotate and fire independent of their movement direction. Most real-life military units can do this. Whether they can fire while moving is a design decision I think we can determine on a per unit basis.

Utility units and other more unique units are definite phase 2  constructs. That will be the phase when we take a working game and try to make it more interesting.

[Brad]

Walls being too cheap will make it too easy (slow build?) Walls being too costly will make them worthless as towers would block paths better. Perhaps some towers can only go on walls? Some towers are not blocking (they can walk between two next to each other.)

You are right, resource cost and time-to-build balancing is going to take a lot of work. Walls are going to have to be cheaper than towers... but no so cheap as to make it so you can fill the map up with them. Maybe a slow build time or perhaps a maximum limit on walls? Thoughts?

[Cody]

The first thing that comes to mind is that you can only build so far from the center of your 'base.' Of course that might be kinda lame or limiting. Ideally I'd say walls can only connect end to end and not be against another wall block on their front or back. That would keep someone from at least filling the entire map with walls. But that sounds way too complicated for what you're planning at this point.

[Nick]

Resources should limit you from doing that. If the player wants to fill the space with walls and not purchase any towers, they will lose. All walls will do is slow the enemy down. 

[Brad]

Yep, resource scarcity should solve that issue. Walls are just cheaper towers that dont shoot back. We will have to do a lot of play testing to get the balance right.

If walls become too much of an issue we can do something like introduce flying units which are not affected by walls.

[Brad]

Also a lot of discussion and design is going on in the Google doc. So dont forget to check that out if haven't lately.

I will try and get a hello world version up on the repo soon so you can mess around in the title game state if you want.

[Nick]

Too bad there is no simple way to get notified when the document gets updated. Google has said they are working on that feature for more then a year (2012).

I like where this is going. Most of the suggestions are too complex of ideas for starting with (I am guilty) but are nice to keep the ideas flowing and the hype alive. And they may be useful later.

I want to get started coding, but I don't know where to start. I could easily make a title screen and such, but I fear it would not mesh with the whole state-driven design we will go for, as I have never worked with something like that.

[Brad]

I will make the base structure today with lots of comments so you will know where to add stuff. That should give you a good idea where to start.

To get the title screen done you will have to use jQuery to catch the click event. Well technically you dont HAVE to use jQuery but to keep all the event code the same you should.

For the main menu we can just place <a> links using relative positioning. Make sure the onclick event returns false so they dont cause you to leave the page though haha.

[Brad]

OK the hello world using the statemanager is now up on the repo. Download it now and try it out. Featuring non-amazing text animation that looks like a bad version of Windows 95 screen saver! Yay!

If you'd like to play around with it you'll need to edit the TitleState class. Especially the update and draw functions. To change to a new state you must pop the current state and then push on the new one.

You can have more than one state on the stack at once (you would do this for things like the pause menu where you can go back to your previous state with no changes) but I'm not sure that works yet as it hasn't been tested.

EDIT: Google doc has been updated as well.