Map Builder v2

Fixed the scale vertically. Scott, with the backgrounds that we currently have there's very little detail down around the bottom, so we should probably try to change that so that the screen isn't just filled with a solid color and there's something interesting there to look that.

I'm going to start creating tiles for 1 bit and 8 bit that are 64x64 pixels and act as tileable landscape. I know you've got some big ground tiles but I'm not sure they'll work, I'm thinking we'll have to go with a repeating tile that can be used for all major landscape. I'd suggest sticking to one 64x64px tile throughout all of the 16 Bit phase and then use a 32x32px tile to make bridges and platforms.

So basically you need one 64x64px "landscape" tile, and one 32x32px "platform" tile (no end caps, unfortunately - I'm thinking of time consumption and how long it's going to take the programmers to lay all this out inside of Python, even with our help).

EDIT: Thinking more about this and the tile engine that we have in place, I am not sure that the 32x32px tiles will work. It might be safer to make a second set of 64x64px tiles to act as platform tiles.

Reinventing Yourself

Funny that you did that little poster, Scott. I've been working on something myself... dramatically different though.



The writing under the silhouettes of the sprites is Latin because I was suggesting evolution, hence the "Charles Darwin" signature in the corner. The Latin simply translates to "Bit Square", "Bit Knight" and "Bit Fat Man".

I'm still laughing at my own joke.

Robo'Erotica ?

Arousing your interest?

Map Builder

I posted measurements as to the sort of space we'll need for gameplay, and have been working on sizing down the scale so that we can accurately create maps for the Programmers to use and implement into the game engine. I've finally got it together now.


This is only an example image, the full-quality PNG is here.

Now mind you, even if the speed does change in our final build, this should be much more than enough for the levels to work functionally. Given the speeds I recorded, every two lines should be one level of the game. The way I'm expecting it should work is simply loading in new textures every 100 seconds over the map, so there's no major issues with us building out every level of the game altogether rather than separating the levels into specifically 1 bit, 8 bit and 16 bit maps.

What I'd like to do is assign specific roles later on to do two lines of this document each, to get split up and swapped around in the end document so a fair bit of ideas are separated and it doesn't work out to be "this level was made entirely by so-and-so", so there's no major distinctive differences in each part. We can work that out once we get back to class, but for now, feel free to play around with it and save anything you do so that we can possibly use it later.

The little blue box in the top left was just to see how much exactly will be on screen when the game first starts, but it's incorrect. The actual height of the screen vertically would only be 7 of the 64x64 blocks. I got my math wrong (most likely because it's 2AM, heh). This means that the vies will never "ascend" despite my intention in making the map, I can edit it at a latter date as it was my intention, rather, to have the map be twice the height vertically of the actual screen resolution. You can play around with that yourselves if you're so inclined, I'll try to get an appended map up in the coming days.

my keyboard is working again!!

Hey Matt,

sorry for not posting an update but my keyboard stopped working.

Firstly we only have 6 more weeks of production left, after that we will enter a debugging phase in which no new concepts can be introduced.

Last week we figured out how we were going to do collision, using 32x32 grids we will map out each levels layout and assign collision by filling grid boxes with red and no collision with white.

the grid size can be as big or small as you wish aslong as all grid blocks are uniform for each individual level.

(example of the grid to be mapped out under the level)

As far as the art goes we need full level maps in one large image, and now if you wish you can have seperate backround tiles so that they move at different times and in directions, for example i will be putting all the clouds into different images so that they move at different paces.

Ben M is making his floating head monster and Ben R has missed the last two friday classes. Llew and Matt are working on the heads display for bits and points, Peter and James are working on collisions and gameplay for the 16-bit.

I'm having a major blocking issue with how long should the 16-bit level be? especially in reference to how fast the scrolling will be? i've been working on some idea's in paint but still need someone elses opinion on how the map should flow conserning platfroms and the multiple direction choices.

so i hope that brings you up to date, if you've got any questions just ask me. hope you feel better soon man.

~Scott

Updates

So I haven't been to TAFE for the last two weeks because of a chest infection, could somebody please fill me in as to where exactly we are in regards to the game? The coming Friday is Easter Friday, so I won't be able to catch up then as I had hoped I might be able to.

Main reason I need to know is to update our Scrum Cards, which are likely well out of date by now. I saw that Andy uploaded some reference material for a tile engine, but I'm not sure if we have that implemented in our own code yet. And I'm pretty sure our art is still well on track, but if we've done anything else there that I could know about, that would be awesome.

An Interesting Read

I've been pretty sick with a really bad chest infection so I apologize for not being around. But I found something I thought you guys might find an interesting read (and Brad and Andy might want people to have a look at, too).

It's basically the steps taken to make a game for XBOX Live, it's pretty interesting stuff. You can read it here.