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.
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.
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
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?
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?
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.
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.
Quote from: Nick on Jan 05, 2014, 12:54 PM
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?
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.
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.
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.
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.
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.
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.
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.
Another update - stayed home due to sick family today and had some time to work on stuff during nap time. TitleState now handles the click event and goes to the MainMenuState. The MainMenuState has menu items which have rollover effects and call javascript functions in the MainMenuState class when clicked. Menu items can be styled and positioned using CSS.
As always you can get the latest updates from the bitbucket repo.
Resolution.
I suggest using 960×640. That size will fit on mobile tablets (including iPad) and can be scaled down to 480×320 to fit on an iPhone. You can use CSS scaling to make it fit on all the other devices too.
I realize we aren't necessarily developing with the idea that a bunch of other people are going to play this but I figure we may as well try it and see if we can get it to work on a bunch of devices. Easier to show off to non-android using family members that way anyway haha.
Also I think 960x640 fits into the "big enough" category. What do you guys think?
Another question that needs answered is tile size. Something like 20pxx20px gives us 40 tiles with 160px left for ui (assuming 960px width). Any thoughts.
Also I am posting stuff to the repo most days. Check the commit log for details.
160 should be enough for the UI.
I have been reading though what code is up so far, and I am liking the state system. Reminds me of the Android app life-cycle.
State machines are super helpful for games. Let's you keep all the menu stuff out of the way. Plus for games with distinct modes (like JRPGs with battle modes and over world's) a state stack makes it easy to go to a new state and then come right back to the state where you left off.
Problem with the menu. When I centered the canvas in the browser window the menu does not move with it. I will figure out how to make a menu using the canvas, as that seems simple and a good way to get more familiar with it all. Either that or I can do the easy way of positioning the menu relative to the canvas with JavaScript.
Other then basic jquery, are there any libraries we should think about? jCanvas (http://calebevans.me/projects/jcanvas/)? Zebra? (http://www.zebkit.com/) There are a bunch of them. (https://www.google.com/search?q=canvas+library)
Dont use canvas to create the menu. You'd have to recreate the hover and click functionality of links.
The canvas container must be relative positioned or the absolute positioned menu links will be absolute based on the page rather than the canvas container.
I guess the other point is to make sure to center the canvas container and not the canvas itself.
Yeah. Never mind. I had a mistake in my CSS, the menu positions correctly now.
I'm glad you are working on it. :) This will be our first collaboration in quite awhile. Courtney is even going to set it up using require js so we can look at how that works.
You can always Google talk me if you want.
I'll try not to bother you too much :)
This is my first real game, and my first real delve into canvas stuff, so it is a bit of a learning curve. But I think it will be fun, and if nothing else educational plus good practice.
As promised -- for those lucky enough to have read access -- here is the project using RequireJS:
https://bitbucket.org/brilesb/robot-td/branch/requirejs
I just did a quick run through the files, wrapping up file contents as modules, defining dependencies, and trying not to break anything. The only functionality I saw was the StateManager showing TitleState and MainMenuState, and a few click handlers (that I had to tweak). I probably missed something, so let me know when you find something fishy.
Yay, my first ever pull request (https://bitbucket.org/brilesb/robot-td/pull-request/1/implementing-requirejs) got merged in!
I created another branch called build-tools (https://bitbucket.org/brilesb/robot-td/branch/build-tools). There are no (significant) source codes changes, but I made way for:
- 3rd-party dependency management via bower (http://bower.io/)
- Minified distributable builds via grunt (http://gruntjs.com/)
If you want to try it out yourself, get nodejs (http://nodejs.org/) and install the grunt command line utility. This is your ant-/maven-like task runner which can be made to do just about anything.
npm install -g grunt-cliThen, from the project directory, install the
node_modules needed to run grunt tasks, optionally get a fresh copy of the bower-controlled libraries, then kick off the
dist task.
npm install
bower install
grunt dist
The result is a minimal distributable build stored in a top-level
dist folder with:
- index.html
- require.js
- main.js
- main.css
I probably didn't explain that nearly well enough...so just ask
Edit: sorry if this was too radical / overwhelming. I've just been playing with this stuff a lot lately, so I was able to whip it up fast. It's in a branch, so you can always delete it easily :) It won't hurt my feelings at all.
In the latest commit I've fixed image loading with the asset manager and wrote a really simple random map generator.
Also, TileMapRenderer is working now so the map is actually drawn to the screen in the game state.
Also, Also, there is now a tileset PNG asset in the repo. So if anybody wants to contribute in a non-programming way then there is a place for working on tiles and updating them to the repo. The tiles are 20x20 pixels, the map is 40x30 tiles.
So I switched the Map renderer over to drawing to an off-screen buffer. It draws the tiles to this buffer only once, then every frame it draws the buffer to the screen. This should be much faster than drawing tiles individually every frame. Due to crappy web hardware acceleration this is necessary so the game will run smooth on weaker hardware (like phones).
Luckily we dont have any scrolling so is this really easy to do. With a bigger map we'd need to tweak the drawing to the buffer so that it would draw tiles at the edge of the map as you scroll. Maybe for next project :)
Hmm, now I'm curious how canvas handles drawing outside the viewable area. There's gotta be some optimization, similar to how browsers handle rendering document contents outside the viewport. It'd be an interesting experiment to see the performance of shifting a large canvas scene vs panning an entire oversized canvas in a clipped div. I'd assume the former to be more performant, but you never know for sure.
In general for large maps you only ever draw slightly more than the viewable area. This is done even in faster languages/systems let alone JavaScript.
Performance is always tight so why waste time drawing things which aren't on the screen. Especially since you would be drawing them 60 times a second.
For map scrolling you would just make a canvas which is a few tiles bigger than the visible map. To scroll you just change which tiles get drawn to the screen. Doing a map buffer with this approach isn't simple. But it lets you do an infinite sized map.
If the map is only a little bigger than the viewable area (bigger map equals more memory) then you could still easily use a map buffer. Just buffer the whole thing but only draw the visible part to the screen. No need for a clipped div or anything like that.
For viewing a large image on a canvas your question is totally valid and I have no idea what the answer is.
So I've started talking into a trap which often gets me when working on complicated projects. I find myself spending time programming and designing for future features which might not ever be implemented rather than focusing on the getting the phase 1 features working.
In this case it relates to rotation speed of towers. I have found myself spending too much time trying to program so that you can set variable rotation speed of towers. 95% of TD games do not even have this feature, towers just rotate to the desired direction instantaneously. Adding this feature adds a lot more complexity than you might think.
I found myself spending a bunch of time thinking about where the best place to calculate the angle to the current target and how to pass it to all the different components that needed it. Not being able to come up with an elegant solution made me a little frustrated. Even if I did succeed in adding this feature I would be complicating the game balancing process (as well as adding complexity to several different components). Currently towers have 3 variables (dps, range, health) which need to be tweaked for game balance. Should I really spend time adding a somewhat boring and complicated one like rotation speed or more interesting ones like area of effect, unit slowing bullets, emp temporary unit disabling bullets, damage over time bullets, etc...
These are the kind of traps that prevent me from completing projects. Yes, it is an interesting feature. But do I really need it? This is just a hobby project, I already have the idea for my next new exciting project. If I ever want to bring this project anywhere near completion I am going to have to try and avoid these pitfalls and keep chopping features.
I think in a tower defense you can drop rotational speed for now and add it later if it seems like a good idea. In a RTS, I would say we would defiantly need turret rotational speed.
Sorry I have been so slow to commit anything :)
Ah, good old scope creep. Toss it in a branch and forget it (for now) :)
If you're not using the "Issues" section, you probably should. It's the best way I've found to keep and prioritize ideas like these. For some reason, the "Issues" tab doesn't show up for me on the RobotTD repo...maybe only the owner gets it? Who knows...
I just moved my Raspberry Pi HTTP server over to GitHub because their "Issues" section is better. Mostly because it has milestones. I have future features (https://github.com/zourtney/lightcontrol/issues?state=open) attached to a 2.0 milestone, a 2.1 milestone, and others that are just floating in space. You can also create and assign arbitrary tags, which is helpful. Having this backlog helps me a lot because I do try -- and fail -- to keep it all in my head. (And it's 10x easier than the overblown solution we have to use at work.) So yeah.