Saturday, June 13, 2009
Thursday, May 28, 2009
What we are working on
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
Friday, May 22, 2009
Update for Matt
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.
Splash
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
- death will be worked on by Mat and Scott
- Rudmenty will be worked on by James
- Double jump cap will be worked on by Mat done
- Slow Falling will be worked on by Mat
- Col map for level 3 will be worked on by Mat and Scott
- Enimies spawn point will be worked on by Ben R done
- 16 Bit Art will be worked on by Ben M done
- Bit Spawn Point will be worked on by Ben R done
- No Title/ end screens will be worked on by peter
- sporn bits on screen will be worked on by llew
Death Sequence
Tuesday, May 19, 2009
Thursday, May 14, 2009
1, 8 and 16 Bit Era Layout's
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
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
Friday, April 10, 2009
Map Builder
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!!
(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
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
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
http://i80.photobucket.com/albums/j200/scott_higg/El_Nudeo_COMPLETE.gif
Sunday, March 22, 2009
Blazing Goblin's
<>
(Animated Version)
http://i80.photobucket.com/albums/j200/scott_higg/FireGoblin.gif
Triple Head Sprite
feeling pretty inspired
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
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
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
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
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
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
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
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
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
Friday, February 20, 2009
Thursday, February 19, 2009
Producers User Stories
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
Mockup Document
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 ImagesFriday, February 13, 2009
Getting Started
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
and just checked the emails, Ben Moreschi and Kieran McDonald switched teams for future reference.
~Scott