• Welcome to Randomland - The Forum. Please login or sign up.
 
Apr 28, 2024, 09:40 PM

News:

Get Out, See Green!


Robot - TD

Started by Nick, Jan 03, 2014, 01:07 PM

Previous topic - Next topic

zourtney

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.

Brad

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.

Brad

For viewing a large image on a canvas your question is totally valid and I have no idea what the answer is.

Brad

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.

Nick

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 :)

zourtney

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 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.