I am glad to finally post my first attribution to the game here. I've created a demoloop for Cave Flier. This track still may sound different from what the actual ingame music will be. But atleast it can give you a taste of what's coming.
Cave Flier Soundtrack by DubAudio
Enjoy
Wednesday, March 30, 2011
Sunday, March 27, 2011
Project #3: Cave Flier
Okay, that name sucks, but it'll do for now. Cave Flier it is.
So after my failure to explain the game properly, I figured I should just draw it out.
So after my failure to explain the game properly, I figured I should just draw it out.
So pretty much, you've got a bunch of asteroids-style spaceships flying through these sorts of levels, attempting to avoid hitting the walls in order to get to the finish before the other spaceships. The green line would be a waypoint, which would probably have to be tied to a nearby spawn point. But anyway.
Not only would I like to do a racing game mode, but also other things, like deathmatch. A long while back, Onaka and I discussed this game and had come up with some pretty great ideas for it. We ended up with a really funky base-vs-base game where the players could actually build up turrets and other defenses, take control of power generators throughout the levels, and attempt to destroy the other base while defending their own. Obviously, this would require a high amount of players to function well, but it's not as if this is will be a particularly bandwidth heavy thing. Anyway, this idea would need to be saved for later.
I'm going to make mini-goals for this project, due to its complexity in comparison to the others. On one hand, I wanted to wait for us to get more experienced before starting something like this, but on the other, I can't really stand to wait any longer.
By Friday, April 1st, our goal is to have a playable demo where spaceships can fly around in a level.
Assuming we are on time, Friday, April 7th, we will have a level editor completed and readily available for people to toy with. By Friday, April 14th, we will hopefully have completed the basic gameplay with racing through waypoints.
Friday, March 25, 2011
Project #3: Unknown
We haven't quite decided on the name yet, but this project is going to be a lot more complex than the other ones.
It's a bit hard to describe, but I'll try. Imagine asteroids, only, with other people, without the asteroids, and with levels to fly around in. Slamming into walls will damage the player, so if he hits a wall too hard it will kill him. Each player will get a spaceship to fly, and there will be several different game modes to play.
The first game mode we will make is the race game mode. Effectively, players will race through a level to reach the end. Whoever gets there first wins.
A few other game modes will be deathmatch and team deathmatch, which is pretty obvious as to what they are.
Man, I'm doing terrible at typing today. Talk about a dry and not-so-exciting post.
Anyway, we've done some design work already in Cacoo. The rudimentary layout is finished, now we need to get a bit more specific with the designs for the base classes. Then, we can begin work.
When I'm feeling up to it, I'll write a more technical post, and also, will have to decide on a deadline for this, considering it's going to be a lot more work to finish.
It's a bit hard to describe, but I'll try. Imagine asteroids, only, with other people, without the asteroids, and with levels to fly around in. Slamming into walls will damage the player, so if he hits a wall too hard it will kill him. Each player will get a spaceship to fly, and there will be several different game modes to play.
The first game mode we will make is the race game mode. Effectively, players will race through a level to reach the end. Whoever gets there first wins.
A few other game modes will be deathmatch and team deathmatch, which is pretty obvious as to what they are.
Man, I'm doing terrible at typing today. Talk about a dry and not-so-exciting post.
Anyway, we've done some design work already in Cacoo. The rudimentary layout is finished, now we need to get a bit more specific with the designs for the base classes. Then, we can begin work.
When I'm feeling up to it, I'll write a more technical post, and also, will have to decide on a deadline for this, considering it's going to be a lot more work to finish.
Monday, March 21, 2011
Design Diagrams
Matti and I, throughout almost our entire programming career together, have wanted a way to create diagrams for our games' design. It's always been really difficult to convey exactly how we're wanting things to work, and every now and then we'd mess up and not understand the other perfectly, forcing us to make adjustments to our design in order to not lose many hours of work.
Finally, we found something that suits our needs. Cacoo.com is providing an excellent service (although, the fact that they're attempting to charge money for more than 25 sheets is absolute bullshit) in which we're able to create all sorts of diagrams for various things. We've spent a few hours just now working on the design for our next project, which is going to be a lot more ambitious than the last. Now that we have this tool, we hope our code will not end up sloppy. We're able to design the classes, what properties they'll need, what functions they'll need, and make notes on how they should behave. We can visually see how everything fits together, and thus, we can design our project before we start coding (instead of designing it as we coded).
I'll make a post tomorrow about the next project. It's multiplayer, and it should be tons of fun. It's going to require a lot more time than our previous projects, simply because of the scale, but I think we should be able to release it in parts. Think of it as a bunch of mini-projects tacked together to create a bigger project. Details tomorrow. Bed now.
Finally, we found something that suits our needs. Cacoo.com is providing an excellent service (although, the fact that they're attempting to charge money for more than 25 sheets is absolute bullshit) in which we're able to create all sorts of diagrams for various things. We've spent a few hours just now working on the design for our next project, which is going to be a lot more ambitious than the last. Now that we have this tool, we hope our code will not end up sloppy. We're able to design the classes, what properties they'll need, what functions they'll need, and make notes on how they should behave. We can visually see how everything fits together, and thus, we can design our project before we start coding (instead of designing it as we coded).
I'll make a post tomorrow about the next project. It's multiplayer, and it should be tons of fun. It's going to require a lot more time than our previous projects, simply because of the scale, but I think we should be able to release it in parts. Think of it as a bunch of mini-projects tacked together to create a bigger project. Details tomorrow. Bed now.
Wednesday, March 16, 2011
Music Artist & Level Designer
We have two new additions to our team!
Lorenzo Claerhout, a music artist, has offered to join our team and I gladly accepted. He did the sound effects and music for Brick Breaker, and I'm really excited to see what he comes up with for our next games.
David Kaye did some of the level design for Brick Breaker. We'll be providing him with level creation tools for all future games that need it, so that he can design the levels, leaving the programmers more time to actually program.
Not only am I excited to see what they come up with, but I'm also excited to read their future posts about how they came up with it.
Lorenzo Claerhout, a music artist, has offered to join our team and I gladly accepted. He did the sound effects and music for Brick Breaker, and I'm really excited to see what he comes up with for our next games.
David Kaye did some of the level design for Brick Breaker. We'll be providing him with level creation tools for all future games that need it, so that he can design the levels, leaving the programmers more time to actually program.
Not only am I excited to see what they come up with, but I'm also excited to read their future posts about how they came up with it.
Tuesday, March 15, 2011
Project #2: Brick Breaker (Complete)
Finally, we can release Brick Breaker. This took MUCH more time than we anticipated, what with the collision detection struggle, and the visual effects, and then the sound... we put a lot more effort into this than I thought we would.
Anyway, here's a quick video demonstrating one of the more difficult levels. It's being played single-player since I don't have anybody who will help show off the multiplayer, so I'm just controlling both of the paddles.
And now for the release:
.NET 3.0 Redistributable: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043 (If you're on Vista or greater, you won't need this.)
XNA 3.0: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6521d889-5414-49b8-ab32-e3fff05a4c50
Brick Breaker: http://dl.dropbox.com/u/5684321/BrickBreakerRelease1.rar
And, once again, for those who want it, here's the source (although I'm not very proud of how terribly 90% of this has been coded, and would not recommend using this as an example): http://dl.dropbox.com/u/5684321/AwesomeBricksSource.rar
Keep in mind the licensing: http://creativecommons.org/licenses/by-nc-sa/3.0/. This applies to EVERYTHING released.
And time for some credits:
Programming by Matti Lehtinen and Chris Walker <project-nectar.blogspot.com>
Art by Skyler Sharpe <facebook.com/skysharpe>
SFX & BGM by Lorenzo Claerhout <darthduba.newgrounds.com>
Level Design by Chris Walker and David Kaye
I don't really have the energy right now to write about this project, so I'm going to go ahead and do that in another posting at a later date. The only thing I can really say right now is that we need to touch up on events, and start using much cleaner coding practices.
As usual, our next project will be posted up within a few days. I don't think the next one will be very exciting, if it's what I think it is, it really isn't going to be a game, per se.
Anyway, here's a quick video demonstrating one of the more difficult levels. It's being played single-player since I don't have anybody who will help show off the multiplayer, so I'm just controlling both of the paddles.
And now for the release:
.NET 3.0 Redistributable: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043 (If you're on Vista or greater, you won't need this.)
XNA 3.0: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6521d889-5414-49b8-ab32-e3fff05a4c50
Brick Breaker: http://dl.dropbox.com/u/5684321/BrickBreakerRelease1.rar
And, once again, for those who want it, here's the source (although I'm not very proud of how terribly 90% of this has been coded, and would not recommend using this as an example): http://dl.dropbox.com/u/5684321/AwesomeBricksSource.rar
Keep in mind the licensing: http://creativecommons.org/licenses/by-nc-sa/3.0/. This applies to EVERYTHING released.
And time for some credits:
Programming by Matti Lehtinen and Chris Walker <project-nectar.blogspot.com>
Art by Skyler Sharpe <facebook.com/skysharpe>
SFX & BGM by Lorenzo Claerhout <darthduba.newgrounds.com>
Level Design by Chris Walker and David Kaye
I don't really have the energy right now to write about this project, so I'm going to go ahead and do that in another posting at a later date. The only thing I can really say right now is that we need to touch up on events, and start using much cleaner coding practices.
As usual, our next project will be posted up within a few days. I don't think the next one will be very exciting, if it's what I think it is, it really isn't going to be a game, per se.
Saturday, March 12, 2011
Sound Effects & Music
Matti and I spent a bit of time looking through the Newgrounds audio portal, and we stumbled upon a great track that works perfectly for Brick Breaker. I notified the artist of the track, and he's now offered to make some sound effects (as the ones we currently have are absolutely terrible), as well as recommended another one of his tracks for our start menu.
The artist in question is Lorenzo (aka darthduba), and his music can be found at darthduba.newgrounds.com. "Archelon" and "Select Start" are the tracks we'll be using, and we're very excited to have sound effects made by someone who actually knows what they're doing.
As far as the programming is concerned, most everything is done. There's a few bugs to iron out, and we still need to implement powerups, but it's looking very close to completion.
The artist in question is Lorenzo (aka darthduba), and his music can be found at darthduba.newgrounds.com. "Archelon" and "Select Start" are the tracks we'll be using, and we're very excited to have sound effects made by someone who actually knows what they're doing.
As far as the programming is concerned, most everything is done. There's a few bugs to iron out, and we still need to implement powerups, but it's looking very close to completion.
Thursday, March 10, 2011
Brick Breaker WIP Video
Collision detection is working great now, and Matti has added particle effects. There's a few more things we need to do visually, and the powerups still haven't been implemented, but this should be easily completed tomorrow. Here's a quick little video of some of the new additions, and of a sample level. We still need more levels, by the way, so if you want to submit any, now is the best time to do it.
Wednesday, March 9, 2011
Visual Effects
Something that we neglected in Snake was to do any fun visual effects. The textures were there, and looked awesome, but there wasn't much in the way of animation or anything that really made the game feel alive. The background stood out as particularly bland, and really made it feel pretty lifeless.
In our Brick Breaker clone, I've added some funky little visual effects to make the game look more appealing. Even with Skyler's images, it still didn't look very alive -- and this is entirely due to the only two moving objects being a ball and a paddle.
Keeping with the simplistic "drawn on paper" look of the textures, and wanting more color, I've made a few adjustments to include some color.
When a ball hits a paddle, the ball inherits the paddles color, thus establishing "that ball is now belonging to that paddle". To any gamer, this is intuitive. I figured I could extend on this. Not only will the paddle own the ball, but the ball will extend its color to nearly anything it touches. When it breaks a brick, the brick turns into a ghost form of its previous self, except with the ball/paddle's color. When it slams into one of the walls, the wall temporarily inherits its color, and it slowly fades off back to the previous color (of white). The invulnerable bricks have the same behaviour as the wall.
Thinking about it, this almost looks as if the players are painting the game world as they're playing. Perhaps the balls could even paint the background as they move around.
I'll post some screenshots sometime soon, once I'm finished messing around with things.
In our Brick Breaker clone, I've added some funky little visual effects to make the game look more appealing. Even with Skyler's images, it still didn't look very alive -- and this is entirely due to the only two moving objects being a ball and a paddle.
Keeping with the simplistic "drawn on paper" look of the textures, and wanting more color, I've made a few adjustments to include some color.
When a ball hits a paddle, the ball inherits the paddles color, thus establishing "that ball is now belonging to that paddle". To any gamer, this is intuitive. I figured I could extend on this. Not only will the paddle own the ball, but the ball will extend its color to nearly anything it touches. When it breaks a brick, the brick turns into a ghost form of its previous self, except with the ball/paddle's color. When it slams into one of the walls, the wall temporarily inherits its color, and it slowly fades off back to the previous color (of white). The invulnerable bricks have the same behaviour as the wall.
Thinking about it, this almost looks as if the players are painting the game world as they're playing. Perhaps the balls could even paint the background as they move around.
I'll post some screenshots sometime soon, once I'm finished messing around with things.
Tuesday, March 8, 2011
Long Delays, But Finally an Update
It's been a while since I last posted here, so I figured I should probably post an update. We've been busy with other, unfortunately more important, life-related things, and hadn't really been able to do any work on anything until today.
The last few times Matti had a chance to do any coding, he'd been struggling with collision detection. Things just plain out did not seem to work. He was trying to figure out how to properly get which side of the brick was hit. After trying several things, and becoming increasingly frustrated with it, I suggested that he should have a collision rectangle on each side of every brick. That way, by detecting collisions on those, he could properly reflect the ball off the surface.
And now, he's done just that. It works wonderfully. The next step will be to get the paddles working better. Right now, they just reflect the ball at a 90 degree angle. This is absolutely useless to a player, as he'd have no control over the way the ball goes. It would bounce the same way every single time he played, and that's simply no fun. The solution is to bounce the ball based off of where it hits the paddle. If it hits on the far right side, it should bounce sharply to the right. If it hits on the far left side, it should bounce sharply to the left. If it hits directly in the center, it should bounce directly up (although this is highly improbable). The player can then take advantage of this functionality to bounce the ball in the direction he wants it to go.
Skyler sent in his images, and they're awesome. I'll post a screenshot, or maybe a video, of the game with his images included later on; probably sometime tomorrow. As for now, I'm going to start work on the paddle and, if I have time, begin on the multiplier.
I wish I could stay true to the 1-game-a-week goal of this project, but I feel that this game could be a lot more than it is right now, and I know that Matti and I are skilled enough to release it in a completed form. As such, I'm going to push back the deadline even further. I'm setting it for this Saturday. This should give us -plenty- of time to put in all the features we want.
Matti will post later regarding a lot of the technical details to what he's done. I'm sad to say it, but I've mostly sat on the sidelines for this project so far. I'm entirely useless when it comes to collision detection and heavy mathematics. That's something I really need to brush up on.
The last few times Matti had a chance to do any coding, he'd been struggling with collision detection. Things just plain out did not seem to work. He was trying to figure out how to properly get which side of the brick was hit. After trying several things, and becoming increasingly frustrated with it, I suggested that he should have a collision rectangle on each side of every brick. That way, by detecting collisions on those, he could properly reflect the ball off the surface.
And now, he's done just that. It works wonderfully. The next step will be to get the paddles working better. Right now, they just reflect the ball at a 90 degree angle. This is absolutely useless to a player, as he'd have no control over the way the ball goes. It would bounce the same way every single time he played, and that's simply no fun. The solution is to bounce the ball based off of where it hits the paddle. If it hits on the far right side, it should bounce sharply to the right. If it hits on the far left side, it should bounce sharply to the left. If it hits directly in the center, it should bounce directly up (although this is highly improbable). The player can then take advantage of this functionality to bounce the ball in the direction he wants it to go.
Skyler sent in his images, and they're awesome. I'll post a screenshot, or maybe a video, of the game with his images included later on; probably sometime tomorrow. As for now, I'm going to start work on the paddle and, if I have time, begin on the multiplier.
I wish I could stay true to the 1-game-a-week goal of this project, but I feel that this game could be a lot more than it is right now, and I know that Matti and I are skilled enough to release it in a completed form. As such, I'm going to push back the deadline even further. I'm setting it for this Saturday. This should give us -plenty- of time to put in all the features we want.
Matti will post later regarding a lot of the technical details to what he's done. I'm sad to say it, but I've mostly sat on the sidelines for this project so far. I'm entirely useless when it comes to collision detection and heavy mathematics. That's something I really need to brush up on.
Wednesday, March 2, 2011
Brick Breaker Level Format
Well, this is an interesting enough topic to deserve posting a blog post about, I think.
Also, for those if you who want to contribute but aren't a programmer or artist... here's your chance to be a level designer.
Matti and I sat down the other day and talked about what the best way to handle the level files would be, and eventually Matti suggested a visual representation of the level itself, in text form. I thought this to be genius, so while he was busy coding up the actual game, I started work on the level loader & format. The loader itself was easy business, and honestly, so was the format.
The level files look something like this:
Now, as you can see, this is a pretty obvious visual representation of a brick breaker level. What the symbols mean, that's not so obvious, but luckily, I've written a short guide that will get distributed with the game if anyone wants to bother making new levels for it. Essentially, though, it's just: "[#]" = normal brick, where # is equal to hardness. "[*]" = unbreakable brick. And, "***" = explosive brick. The only requirement of this level format is that it's displayed in a fixed-width font, otherwise, it won't look right. The above font is Courier, which works great.
If anybody out there wants to, they could use this information to go ahead and start making levels for us! Post 'em in the comments below, or message me on Facebook, or e-mail me, or basically contact me in any way you possibly can, and I'll almost certainly include your level.
Oh, but a couple quick notes: level size is 17 bricks wide, 19 bricks tall. Explosive bricks do 1 damage to every brick touching them. Unbreakable bricks are... unbreakable, and as such, are not required to be destroyed in order to progress to the next level. And, on a separate note, feel free to name your level. There's a good chance that we'll include level names in the game. It isn't a priority, but it certainly isn't hard to do at all.
And a quick suggestion, while I'm at it. Because of the fact that this is co-op, there is a person on top of the level, and a person on the bottom of the level. It's good form to make a middle line (on line #10) and be symmetrical on both sides. This way, each players scoring potential is identical. Also, it just looks good.
Also, for those if you who want to contribute but aren't a programmer or artist... here's your chance to be a level designer.
Matti and I sat down the other day and talked about what the best way to handle the level files would be, and eventually Matti suggested a visual representation of the level itself, in text form. I thought this to be genius, so while he was busy coding up the actual game, I started work on the level loader & format. The loader itself was easy business, and honestly, so was the format.
The level files look something like this:
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] --- --- ---
--- --- --- --- [1] [1] [1] [1] [1] [1] [1] [1] [1] --- --- --- ---
--- --- --- --- --- [1] [1] [1] [1] [1] [1] [1] --- --- --- --- ---
--- --- --- --- --- --- --- [1] [1] [1] --- --- --- --- --- --- ---
[3] [*] [*] [*] [*] [*] [1] [1] [1] [1] [1] [*] [*] [*] [*] [*] [3]
--- --- --- --- --- --- --- [1] [1] [1] --- --- --- --- --- --- ---
--- --- --- --- --- [1] [1] [1] [1] [1] [1] [1] --- --- --- --- ---
--- --- --- --- [1] [1] [1] [1] [1] [1] [1] [1] [1] --- --- --- ---
--- --- --- [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
Now, as you can see, this is a pretty obvious visual representation of a brick breaker level. What the symbols mean, that's not so obvious, but luckily, I've written a short guide that will get distributed with the game if anyone wants to bother making new levels for it. Essentially, though, it's just: "[#]" = normal brick, where # is equal to hardness. "[*]" = unbreakable brick. And, "***" = explosive brick. The only requirement of this level format is that it's displayed in a fixed-width font, otherwise, it won't look right. The above font is Courier, which works great.
If anybody out there wants to, they could use this information to go ahead and start making levels for us! Post 'em in the comments below, or message me on Facebook, or e-mail me, or basically contact me in any way you possibly can, and I'll almost certainly include your level.
Oh, but a couple quick notes: level size is 17 bricks wide, 19 bricks tall. Explosive bricks do 1 damage to every brick touching them. Unbreakable bricks are... unbreakable, and as such, are not required to be destroyed in order to progress to the next level. And, on a separate note, feel free to name your level. There's a good chance that we'll include level names in the game. It isn't a priority, but it certainly isn't hard to do at all.
And a quick suggestion, while I'm at it. Because of the fact that this is co-op, there is a person on top of the level, and a person on the bottom of the level. It's good form to make a middle line (on line #10) and be symmetrical on both sides. This way, each players scoring potential is identical. Also, it just looks good.
Subscribe to:
Comments (Atom)