Messages

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

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.

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

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.

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.

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.

Your server facility doesn't have generator backup yet? Tsk tsk. You should bring that up in your annual networking and facility services board meeting.

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.

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.

Sounds like you are ready to start on the robot TD project haha

Yeah and you miss out on data typing too. You can do variables, functions and objects though. Dont even try to understand what scope is in JavaScript. Because holy crap is it awful.

When you've done some JavaScript stuff and are getting reasonably comfortable you'll want to get into something like C# to pick all the stuff you can't learn in JavaScript.

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?

Awesome! Programming is a skill that opens up a lot of possibilities. Whether it is creating nifty lightweight web apps or building a robot with spinning blades of death in your backyard the basic programming concepts apply.

The best way to learn programming is by doing it. I can give you a bunch of ideas for simple projects but you'll have a more fun time if you pick something you are interested in.

Personally I always chose games, even back when I was just starting to learn. Just find something you are interested in and try to make it. Keep it simple. Take the most simple project you can think of and then simplify it more.

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.

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.