Saturday, June 13, 2009

Thursday, May 28, 2009

What we are working on

1. mat fix floating bug

2. mat to get enemy spawn code and detect and play out death

3. colab with peter for a way to signify this

4. james to animate enemies and walk along platforms

5. peter to work on state system to handle levels, dead, intro blah

6. Col map for level 3 will be worked on by Mat and Scott

7. bit art to show in game (llew's done code)

8. ben r to do splash screens title polish

9. ben m polish victory

10. matt to do death screen Peter/ART Team screens- title- transition (fade to black)- victory for whole game (score)- death (score)- help screen

Saturday, May 23, 2009

Arrows and Go

Andy asked for some directional arrows so that the player doesnt get lost in the massive gaps of jumping from island to island so i made some.


GIFS:

Friday, May 22, 2009

Update for Matt

Ok,
we've all started finishing our work so that i can be given to the programmers to build a running version of the game;

I completed getting the death sequence "game ready". also working on the last 8ooo pixels of 16-bit art work and collision. when I finish this task I will merge all the 18-bit art work into one map.
Ben R,
finished his portion of level art and assigned the enemy spawn, bit spawn and character spawn points for the 16-bit artwork (now that I think about it i should have gotten him to do it for each level). afterwards Ben and i worked on idea's for splash screens.
Ben M,
also finished his portion of the first 8ooo pixels of 16-bit level, he is working on a volcano for the end of the level. Ben also worked on some concept for the game over screen.
Programmers,
sorry to lump the programmers into one but i didn't have much time to look at what they were all doing**
We need to work on some transition screens for level changes, the programmers would prefer we made some art work for that asap. they are also starting to import c enemies into the game and working on a damage system. Llew has the HUD working and corresponding to bit collection.
also double jump is being refined from the infinite jump we have at the moment. James and Andy are making a lot of headway and are working from 16-bit backwards development wise so we need to finish the 16-bit maps asap (that's my fault and it will be done by next Friday).

Art jobs:
we still have a few left,
Credits: peter and i were talking about whether they should be graphical or code based and now thinking back on it i believe we(the Artists) should create it as peter has some pretty vital role programming.
End Screen,
we need the game to have some sort of closure and i feel this should be achieve with a victory screen, you're very good at coming with ideas concerning underlying plots and themes of the game so if you can think of anything for this screen i would love to hear them as i am stumped.

I think that is all but there is a lot to be wrapped in the testing phase, our first major bug is that we don't have a running version of the game, so we gotta bring it all together.

~Scott
(and for the record, duke nukem 3D... best game ever)
oh and do you have illustrator i'm killing for one that isnt a virus.

V2

trying to make it a look like you looking down on a console that has 3 screens on the case.


Splash

Ben and I were fleshing out ideas for the splash screen,

and this is the basic layout we had and i just put some finishing touches on it.

Thursday, May 21, 2009

What needs to be done

things to do for the completion of the game


  1. death will be worked on by Mat and Scott
  2. Rudmenty will be worked on by James
  3. Double jump cap will be worked on by Mat done
  4. Slow Falling will be worked on by Mat
  5. Col map for level 3 will be worked on by Mat and Scott
  6. Enimies spawn point will be worked on by Ben R done
  7. 16 Bit Art will be worked on by Ben M done
  8. Bit Spawn Point will be worked on by Ben R done
  9. No Title/ end screens will be worked on by peter
  10. sporn bits on screen will be worked on by llew

Death Sequence

here is the gif of the death sequence.
i'll have to make this into a png tomorrow.
~Scott

Tuesday, May 19, 2009

next 8000 pixels

we need to do another 8000 pixels of 16-bit art.
this is what i've done so far.

Thursday, May 14, 2009

1, 8 and 16 Bit Era Layout's

these are the mock ups of whats been done by the art team.
the rest of the 16 bit level will be made asap and uploaded.
the actual monster and bit layout will be indicated on the collision maps that are given to the programmers.

~Scott


(1-Bit)

(8-bit)

(16-bit)

Wednesday, April 15, 2009

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.

Monday, April 13, 2009

Robo'Erotica ?


Arousing your interest?

Friday, April 10, 2009

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.

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

Sunday, April 5, 2009

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

Saturday, April 4, 2009

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.

Wednesday, April 1, 2009

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.

Tuesday, March 24, 2009

updates

just post an updated walk cylce.. i just smoothed out the kinks in the arms and legs.


http://i80.photobucket.com/albums/j200/scott_higg/El_Nudeo_COMPLETE.gif

Sunday, March 22, 2009

Blazing Goblin's

made this for 8-bit, they could fall from the sky.

<>

(Animated Version)
http://i80.photobucket.com/albums/j200/scott_higg/FireGoblin.gif

Triple Head Sprite

i've been having heaps of trouble with this one, he doesn't translate into a sprite all that well but i made a few up.

tell me which one you prefer.


matt if you could tell me what sort of role you want him to play in the game.

and any ideas on what sort of movements he should have ie. walking, jumping, shooting, pooing, running, etc..

thanks

feeling pretty inspired

made up an enemy for the 16 bit from the original concept images i did,
he's a tiny bit strange but i think thats a part of his charm,
tell me what you think.

http://i80.photobucket.com/albums/j200/scott_higg/El_Nudeo_FINAL.gif
http://i80.photobucket.com/albums/j200/scott_higg/march1.jpg

think we need to start mapping out the terrain now that we have a good idea of what it looks like aswell.
i've got in mind for the 16 bit that it should be very platform oriented, more risks involving falling of the level n such.

1 Bit And 8 Bit Art

Just a bunch of art I did over the weekend. I think I need to work on the 8 Bit colors a little, but they are intentionally gaudy.

I'm also using a weird art style to make everything look blocky, reducing the file size down a quarter from that required (so I actually made the 64 x 64 px character sprite in a 16 x 16 px file) to get the kind of Atari look I wanted.

I also took Bens 1 - Bit enemy Bit and reduced the pixel count on it to see what it might look like with that sort of sytle.

They're all on the repository now along with sprites, mockup poses and such.

Comments? Thoughts?

Thoughts

So I did some more math and thinking about how exactly the game is going to play out. I think our best bet to keep gameplay flowing is to have transitioning from one phase into another at a specific time. Split evenly, that would mean that there would be a transition into a new look every 100 seconds (or 1 minute 40 seconds).

This way we can make the difficulty curve scale pretty well, too.
If 1-Bit lasts for 100 seconds and you have to collect 8 bits, that's 1 bit you have to collect every 12.5 seconds.
If 8 bit lasts for 100 seconds and you have to collect 16 bits, that's 1 bit you have to collect every 6.25 seconds.
If 16 bit lasts for 100 seconds and you have to collect 32 bits, that's 1 bit you have to collect every 3.125 seconds.

It also gives us some room for mistakes and the ability to really play with the "story" that gets told. We could put 10 bits into the 1 bit phase (or 8 bits and 1 bit cluster) so that the player could end out lagging behind in 8 bit or being ahead. In 8 bit, the bits might be easier to come by, but require a bit more jumping/enemy dodging in order to get them. In 16 bit we could have much more than 32 bits in there so that if players lagged behind they could catch up. I'm thinking that we can safely put in a LOT of bits into the 16 bit phase, as we want the end result to be a game that you play to try and beat your previous score in 5 minutes. We don't want it to be impossible to finish. So the sense of being rushed becomes more and more prominent the further through the game you get, and you face more and more enemies as you try to collect more and more bits.

I was also considering how we can make the transitions work, and I think with this layout we can make it happen really quite easily. At 100 seconds into the game, the background, platforms and enemies transition into 8 bit. At 200 seconds into the game, the background, platforms and enemies transition into 16 bit. At 300 seconds into the game, the game ends. This way we can create a play area that takes a little over 5 minutes to cross (based on the players movement speed) and simply load in different textures every time the timer hits a certain point.

The Player character would develop separate from the timer however, and would load in new textures based upon their bit count (so at 8 bits in the 1 bit phase, the character loads in a new sprite - whether or not the game has reached the 8 bit phase). If we wanted to we could easily reward the player for pulling this off with extra points (I was even thinking a little text popup saying "Ahead of its Time!" or the like, since this is a game based on games).

Just getting my thoughts out there.

Saturday, March 21, 2009

re imagining

I know its way past the point of concepts but i had a re imagining of the terrain so I adapted the backgrounds and sky line we had into (what I think is) a new and improved style.

Tell me what you think; this scale is twice the height of our resolution,
Which I thought would be cool if the camera followed you as you traveled vertically... Though it would never stop scrolling horizontally obviously, I was hoping this would give an illusion of freedom in what is an extremely linear game play.

Friday, March 6, 2009

Program Requirements

As Brad and Andy mentioned to us today, we might want to get a more specific list of requirements for the programmers (and I felt it would help to get the same list going for the artists) so that we knew EXACTLY what was required of the program. This list will likely be updated as we go along and our requirements grow and change.

For Programmers:
Platform style gameplay (Jumping, collision, gravity)
Countdown timer (5 Minutes)
Changing Sprites during Gameplay (Character, Background, Platform, Object and Enemy sprites will be changing)
Object collection and score keeping.
640x480 screen size, 64x64 character size, 32x32 platform tile size.

For Artists:
1 bit, 8 bit, 16 bit and 32 bit themed sprites.
Character (enemies, objects and player) sprites 64x64.
Ground and platform size in 32x32 (with platform caps for the ends of the platforms).

Things we need to discuss are:
How death will work in the game (do you have lives or does it remove a bit?)
How the background will work (Does it move and repeat seamlessly, or does only the foreground move?)

Tuesday, March 3, 2009

Game Design Document

Threw together a preliminary GDD in my days off sick, I just threw in some finishing touches and thought I would show it to you guys first. If there's anything you feel that should be changed or taken out of there, let me know.

I couldn't link the images that I had in the document, so just imagine that the stuff Scott mocked up is where it says it is.

Threw together a preliminary GDD in my days off sick, I just threw in some finishing touches and thought I would show it to you guys first. If there's anything you feel that should be changed or taken out of there, let me know.

I couldn't link the images that I had in the document, so just imagine that the stuff Scott mocked up is where it says it is.

EDIT: I just added all our concept art and the GDD to our SVN. You can check it out on there if you have it set up on your computer.


BIT
Design Documentation

OVERVIEW
Bit is a game about games. In Bit, you are a simple sprite, floating through the stream of time and growing as the world around you changes. In Bit, there are four separate phases – 1-Bit, 8-Bit, 16-Bit and 32-Bit. In order to keep up with the ever changing world around you, you have to collect other bits to become more complex – and not fall behind lest you become an outdated concept in a far more complicated world. The whole game starts and finishes in a time span of 5 minutes, but encompasses a very large and very early era of gaming.

GAME MECHANICS
Early 1-Bit Concept Art
When the game first starts, you are simply a white block on a black background, fighting to collect other white blocks in order to grow in complexity. You float around the area of play, fighting off other, more aggressive bits. This phase is very simple and Pong-esque in visuals. The intention for the game is to have it grow in complexity as the player progresses, like most modern games do.

Early 8-Bit Concept Art
Once you collect 8 bits, the world changes – and so does the player and the way the game plays. Everything grows more complex as the era changes and the visuals become far more like that of the early Atari games. The player becomes a bit more like a recognizable character now, moving along in the world in a platform style game – though the goal has not changed. Collect bits, grow your complexity, and avoid other aggressive bits.

Early 16-Bit Concept Art
This theme continues into the 16 and 32 bit eras. To get from 8 bit into 16 bit, you must collect 16 bits. To get from 16 bit into 32 bit, you must collect 32 bits. Once entry into 32 bit has been achieved, the game is over – so long as you achieved the goal within 5 minutes.

PLAYER CHARACTER
Early 16-Bit Character Concept
You play as an unnamed, constantly changing character that moves through each era of gaming, becoming something new and interesting each time. As the game plays out, the character grows from a simple square sprite into something far more complicated each time. While the character may still look extremely blocky in 8-Bit, it becomes further and better defined in 16 and 32 bit.

GAME FEATURES
* Progression through four separate visual eras of gaming.
* Character growth and development from a simple 1 bit white sprite into a 32 bit one.
* 1 bit, 8 bit, 16 bit and 32 bit art styles in a short span of time.
* Fixed Sidescroller and Platformer style gameplay (?)
* Use of all 3 of the Product Owners requested themes.
* Playable in 5 minutes.

Monday, March 2, 2009

A Little Inspiration

I found the game that reminded me of the one we've come up with. It's called Eat Lead: The Return of Matt Hazard. You can see the official website here.

Matt Hazard is a fictional videogame character that had a stint of popular games in the 1980's, but later lost his luster and faded into obscurity. In Eat Lead: The Return of Matt Hazard, people play as the returned Matt Hazard through all his old games. It's basically a metagame that pokes fun at the industry with a bunch of videogame references.

Look up Matt Hazard on Youtube, there's some pretty funny video clips of the gameplay.

Saturday, February 28, 2009

User Stories

On friday we discussed as a group and in our indivdual sections (programmers and artist) what our tasks would be and where we wish to head in the next few weeks.
With help from brad and andy we now have some set user stories.

User Stories:
Design:
(these include refined ideas that matt suggested)
  • Create a game design Document.
  • Assign team roles.
  • Review game design document with product owner.
  • Show weekly stable build of the game to product owner.
  • Check new blog entries (before weekly scrum).

Art:

  • Devolop an art style (remember that character models must be fixed into a 32 by 32 pixel spec).
  • Develop an asset list.
  • Start on animation planning (png format was recommended images).

Programming:

  • Pygame loop and res: 640 by 480.
  • Keyboard input to work with res/key detection.
  • Move sprite onscreen with the same keys.
  • Platforms on screen so when you collide with them it collides with the sprite too.
  • collision detection.
  • gravity.
  • sprite to object detection.

Saturday, February 21, 2009

Game References

As we've discussed in class; we want our game to grow from 1 bit to 32 bit in style. I thought it would be handy to have a visual reference as to what 1, 8, 16 and 32 bit games looked like.

Now, 1 Bit is fairly simple. There, you have Pong. However, there is no need to stick with the visual style of Pong necessarily depending on what we want to do in the way of game style. We could have Scott's character mock-up in black and white moving through to 32 bit.

8 Bit, things begin to become a bit more expansive. Around that time you had Atari and the like out and bout. The game I was thinking of as reference, was the Texas Chainsaw Massacre, but the graphics actually looked a lot more complicated than that - as Megaman was 8 bit, too, but released 5 years later.

16 Bit I imagine something closer to Super Mario World. This is where things start getting pretty sticky - the games look really good, and it's kinda hard to think where we can take the games design from 16 bit into 32 bit.

32 Bit and you have Chrono Trigger. How do we feel about doing sprites on that sort of standard? I'm wondering if we should scale things back, just go up to 16 bit for the 3 separate levels instead. But really, it's up to you guys - how do you feel about doing art with these sorts of standards?

-Matt

too many post from me,


waiting to go out, so i made this. i'm pretty bored.

Friday, February 20, 2009

i know i'm getting ahead of myself here, but might as well chuck this up aswell.
this the sprites combined into a gif along with a dpe sheet and the original character sketch.

~Scott

Just mocked up a scene to show what i had in mind for the 32-bit level of the game,
tell me what you think, the red dude is the playable character (its just a sprite i knocked up for the image), tell me what you think?


~Scott

Thursday, February 19, 2009

As a Q.A it means we need to have a testing game by week 4 and a almost finished game by week 10 and we should be all able to test it all then

Producers User Stories

PRODUCER
As Producer, I want to keep things simple and construct this game from the ground up with our core ideas and mechanics so we have a functioning product in 4 months time.

As Producer, I want to set specific roles for my team to focus on and turn in when expected.

As Producer, I want to make sure our planned game sticks to the Product Owners requests of the game being playable in 5 minutes, made up of the themes of Float, Stream and Grow, and to not be multiplayer.

As Producer, I want to keep our Product Owners up to date on the current state of the project as often as possible.

As Producer, I want my team to keep me up to date on the current state of the project as often as possible.

As Producer, I want the programmers to focus on getting the platforming aspects of the game working first.

As Producer, I want the artists to focus on organizing how sprites are going to work and what they are going to look like.

Preliminary Mockups

Here's all the stuff we've come up with so far.

Mockup Document
Platform game: art heavy, less programming.

Time travel theme (stream of time),

5 minute count down timer. Mario ish game. Changing art style (16 bit sprite)

Flow of time represented by the changing of graphics 1-bit, 8-bit, 16-bit.

Constant scrolling background to force game play.

Must evolve to the next bit in order to continue playing.

each level requires you to collect bits in order to get to next level, i.e.

8 bits and 16 bits.

1-bit:

White bit collects other colour bits in order to evolve to 8-bit.

Platform without gravity, side scrolling shooter.


Mockup Pitch

BIT

By Team Bit

The game that us here at Team Bit are going to produce is a platformer/sidescroller. It portrays the player (at the beginning) as a single pixel, trying to make his way through time into an 8-bit sprite, a 16-bit sprite and eventually a 32-bit sprite.

The game mechanic starts off as a simple sidescroller/shooter where your aim is to destroy red pixels who’re flying at your white pixel whilst all the time attempting to collect the golden pixels which – once you’ve collected enough, upgrade your player and subsequently allow you to advance through (time) into the later bit formats.

Mockup Images

Friday, February 13, 2009

Getting Started

Team A is made up of:
Ben Moreschi (Swapped with Kieran McDonald)
Llew Watson
Mat Lawson
James Gibson
Scott Higgenbottom
Ben Russell
Matthew Dyet

Does anybody have any ideas as to what sort of game we could do, or a specific role they would like to do? Both are worth thinking about over the weekend, or if you have your mind made up now go ahead and post your thoughts. I'm happy with a Producer or Designer role if nobody else is.

The idea I've been throwing around in my head was for a game based on the flow of time. A simple platformer like Super Mario or a fixed shooter like Galaga. Basically putting more emphasis on the art than the mechanics since we have so many artists. Unless Mat and Llew think they can program something more complicated - I'd like to keep it simple and add onto it.

Post Testing

just testing i can post,
and just checked the emails, Ben Moreschi and Kieran McDonald switched teams for future reference.

~Scott

Test Post

This test post bought to you by Matthew Dyet!

Thursday, February 5, 2009

Welcome

This is where Team A will blog their progress. Contact andyhawkins@ozemail.com.au if you are having troubles creating a blog here, or you want to be added to this team