Both me and Chris have become a little bit too busy to keep working on this project for now.
It is my wish to return to this project once work-related things calm down and stabilize a little.
Sunday, April 10, 2011
Wednesday, March 30, 2011
Cave Flier Soundtrack
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
Cave Flier Soundtrack by DubAudio
Enjoy
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.
Friday, February 25, 2011
Project #2: Brick Breaker
The next project will be Brick Breaker, and the deadline will be next Friday (the 4th of March). Matti and I discussed Tron and decided that we want to save it for when we are more skilled and can actually make it be the best we can.
So, Brick Breaker. Sitting down and thinking, Brick Breaker is a fairly simple game. We decided from the get-go that our focus is going to be on co-operative play. One player will reside at the top, and the other at the bottom. There will be walls on the left and right side, but other than that, the players will need to work together to make sure the ball does not go out of the play field.
So what does Brick Breaker involve? Well, we have bricks, two paddles, ball, and powerups. The paddles bounce the ball around to break the bricks, which in turn may drop powerups to increase scoring potential.
The bricks will be able to have multiple layers of defense. That is, they may have to be hit more than once. This will be shown to the player by way of color, and will be very intuitive.
Each player will control a paddle. The paddle will correspond to the player by way of color. One player will be blue, the other will be red. Thus, anything in the game world that is that color will be immediately recognizable to the players as belonging to that color player.
The ball will change color when a player hits it, so as to represent the last player to touch it. Each player has a separate score, and there is also a combined score, so the color of the ball will be important to obtain a greater score than your friend. This is competitive co-op, where both players work together, but also compete.
Powerups will randomly spawn from bricks. Depending on who hit the brick, the color of the powerup will change to the player of the opposite color. Only that player will be allowed to actually collect the powerup. The powerup will act the same as the ball -- only it cannot break bricks, and also cannot collide with the ball or other powerups. Once the powerup touches the paddle of its' color, both players will get that powerup.
The game will feature a multiplier so as to make scoring more interesting. Every time the ball touches a brick, the player will score X points. Every time the ball breaks a brick, the player will score Y points. Additionally, every time the ball touches a brick, the multiplier will increase slightly. The way that this works is there will be a bar at the bottom of the screen, accompanied by text saying the current multiplier. The bar will increase in fullness until it is full, and then the multiplier will go up by one. The multiplier will then multiply into every point scoring.
Finally, I've spent a bit of time thinking about what kind of art I'd like to see in this game. Something I really like is when people draw their art as pencil sketches on paper, and then scan it in. I think it looks very cool, and I think it fits very well with these old games. I'll see if Skyler is available to do the art for this game. If he isn't, I have a scanner, and Matti's friend might be able to help out.
So, as you can see, this project is a lot more ambitious than Snake was. Consider Snake our warm-up, I expect that this game will turn out quite nice.
I'll post again when we've made some progress.
So, Brick Breaker. Sitting down and thinking, Brick Breaker is a fairly simple game. We decided from the get-go that our focus is going to be on co-operative play. One player will reside at the top, and the other at the bottom. There will be walls on the left and right side, but other than that, the players will need to work together to make sure the ball does not go out of the play field.
So what does Brick Breaker involve? Well, we have bricks, two paddles, ball, and powerups. The paddles bounce the ball around to break the bricks, which in turn may drop powerups to increase scoring potential.
The bricks will be able to have multiple layers of defense. That is, they may have to be hit more than once. This will be shown to the player by way of color, and will be very intuitive.
Each player will control a paddle. The paddle will correspond to the player by way of color. One player will be blue, the other will be red. Thus, anything in the game world that is that color will be immediately recognizable to the players as belonging to that color player.
The ball will change color when a player hits it, so as to represent the last player to touch it. Each player has a separate score, and there is also a combined score, so the color of the ball will be important to obtain a greater score than your friend. This is competitive co-op, where both players work together, but also compete.
Powerups will randomly spawn from bricks. Depending on who hit the brick, the color of the powerup will change to the player of the opposite color. Only that player will be allowed to actually collect the powerup. The powerup will act the same as the ball -- only it cannot break bricks, and also cannot collide with the ball or other powerups. Once the powerup touches the paddle of its' color, both players will get that powerup.
The game will feature a multiplier so as to make scoring more interesting. Every time the ball touches a brick, the player will score X points. Every time the ball breaks a brick, the player will score Y points. Additionally, every time the ball touches a brick, the multiplier will increase slightly. The way that this works is there will be a bar at the bottom of the screen, accompanied by text saying the current multiplier. The bar will increase in fullness until it is full, and then the multiplier will go up by one. The multiplier will then multiply into every point scoring.
Finally, I've spent a bit of time thinking about what kind of art I'd like to see in this game. Something I really like is when people draw their art as pencil sketches on paper, and then scan it in. I think it looks very cool, and I think it fits very well with these old games. I'll see if Skyler is available to do the art for this game. If he isn't, I have a scanner, and Matti's friend might be able to help out.
So, as you can see, this project is a lot more ambitious than Snake was. Consider Snake our warm-up, I expect that this game will turn out quite nice.
I'll post again when we've made some progress.
Wednesday, February 23, 2011
Project #1: Snake (Complete)
And here we are, a completed version of Snake. Sorry for the late release, I've been sick and in the middle of a move so getting to a computer was difficult for me.
First things first, the game and its dependencies:
.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
AwesomeSnake: http://dl.dropbox.com/u/5684321/AwesomeSnake.rar
And, for those who want it, here's the source: http://dl.dropbox.com/u/5684321/AwesomeSnakeSource.rar
Just keep in mind the licensing (found here: http://creativecommons.org/licenses/by-nc-sa/3.0/).
You'll need WinRAR or a similar program to extract AwesomeSnake.rar. Just put it wherever you want and run AwesomeSnake.exe.
You may also be interested in looking at settings.cfg. You can change the game mode between Single, Versus, and Co-op. For player one, use W A S D to move around. For player two, use the arrow keys. As your snake eats food, it will grow in size, and increase in speed.
One of the more important tweaks I've made to Matti's code is to have the snakes behave differently when they hit walls depending on the game mode. If you're in versus, and you hit a wall, you will simply wrap around to the other side of the level. In every other mode, you will die.
A major problem with the versus mode in this game is that the loser is the one who has less points. This presents a problem, as either player could get enough points to win, and then kill themselves. If I had more time, I would spend some thought on what could be done to fix this, but unfortunately I'm already past the deadline by a day and can't.
Closing thoughts on this project: I'm unhappy with how bad the actual code looks right now, but I put my throat infection and house-moving to blame for this. I had to put most of the final work onto Matti's shoulders, and he didn't have enough time to really code things in a neat manner. Next project, I'll be striving to make the code as neat as possible. Another thing, while slightly unrelated, has to do with the visuals. The art is great, but I neglected to get a background image. The grey background looks terrible, and I can't think of any way to make it better.
I'll be posting a new project either tonight or early tomorrow. Matti and I have been discussing doing a remake of Tron, but I'm considering leaving that for later as online play is one of the things I really would like to have in a game like that.
First things first, the game and its dependencies:
.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
AwesomeSnake: http://dl.dropbox.com/u/5684321/AwesomeSnake.rar
And, for those who want it, here's the source: http://dl.dropbox.com/u/5684321/AwesomeSnakeSource.rar
Just keep in mind the licensing (found here: http://creativecommons.org/licenses/by-nc-sa/3.0/).
You'll need WinRAR or a similar program to extract AwesomeSnake.rar. Just put it wherever you want and run AwesomeSnake.exe.
You may also be interested in looking at settings.cfg. You can change the game mode between Single, Versus, and Co-op. For player one, use W A S D to move around. For player two, use the arrow keys. As your snake eats food, it will grow in size, and increase in speed.
One of the more important tweaks I've made to Matti's code is to have the snakes behave differently when they hit walls depending on the game mode. If you're in versus, and you hit a wall, you will simply wrap around to the other side of the level. In every other mode, you will die.
A major problem with the versus mode in this game is that the loser is the one who has less points. This presents a problem, as either player could get enough points to win, and then kill themselves. If I had more time, I would spend some thought on what could be done to fix this, but unfortunately I'm already past the deadline by a day and can't.
Closing thoughts on this project: I'm unhappy with how bad the actual code looks right now, but I put my throat infection and house-moving to blame for this. I had to put most of the final work onto Matti's shoulders, and he didn't have enough time to really code things in a neat manner. Next project, I'll be striving to make the code as neat as possible. Another thing, while slightly unrelated, has to do with the visuals. The art is great, but I neglected to get a background image. The grey background looks terrible, and I can't think of any way to make it better.
I'll be posting a new project either tonight or early tomorrow. Matti and I have been discussing doing a remake of Tron, but I'm considering leaving that for later as online play is one of the things I really would like to have in a game like that.
Monday, February 21, 2011
Snake Status
Apologies for any poor formatting in this post, I'm on my android.
Snake will be posted up tomorrow. There are a few simple tweaks that need to be done before I post the release, and I can't do them until I finish moving to my new apartment. I will be sure to post as soon as possible.
UPDATE: I don't think I'll have time tonight to upload Snake. Sorry! We're still moving and my computer isn't unpacked yet... nor my desk, for that matter. :P
Snake will be posted up tomorrow. There are a few simple tweaks that need to be done before I post the release, and I can't do them until I finish moving to my new apartment. I will be sure to post as soon as possible.
UPDATE: I don't think I'll have time tonight to upload Snake. Sorry! We're still moving and my computer isn't unpacked yet... nor my desk, for that matter. :P
Awesomesnake: Playable version
So, we now have two snakes that move and grow according to player input. Right now the controls aren't customizable due to us needing to implement a lookup table to translate strings to the enum XNA uses.
We now have three game modes, single player, two player versus and two player co-op (just for the hell of it), and they're all scored properly.
There are still a couple of little details that need to be fixed, but the game is now entirely playable.I'll let Chris look it over and post an actual build once he wakes up, if he still has time to check it out due to moving and whatever.
But now I'm just gonna go ahead and chill for an hour or two.
Also, pictures:
Snake Images
Just completed the snake images today. they were fairly simple, and were composed of a snake head, snake body, and food that it eats.
the snake head began as just a circle. since its more challenging to draw more pictures or to rotate the images, I drew a snake head that faced the player instead of moving in a specific direction. The head is an upside-down triangle with rounded edges, and the eyes were faded yellow lines. the nostrils were also faded yellow lines but much thinner.
I began with the snake body as a circle as well, but I didn't like it that way, so a friend of mine suggested a black box with half circle's taken out of each side, effectively making an X. But since I didn't think that it would flow well, I decided to take half circles out of the corners of the box. then I traced the box to allow room for the edge.
For the food I drew an apple. this is an easy food to draw, and would clearly represent food to anyone who plays this game. I added a faded white line to give a 3D effect.
No leaf cause it was easy to mess up.
All images were drawn in a basic paint program.
Above is a longwinded way of saying I drew some pictures in Kidpix compared to what everyone else is doing.
I'm just happy to contribute ^_^
DK
Sunday, February 20, 2011
Licensing & Snake's Status
Now is probably a good time to talk about licensing. All released code and images, UNLESS OTHERWISE STATED SPECIFICALLY IN THE PROJECT OR IMAGE, OR ALTERED IN A LATER BLOG POST, will be released under the following license: http://creativecommons.org/licenses/by-nc-sa/3.0/.
As far as attribution goes, simply include a link to the Project: Nectar blogspot, and state what code/images you used of ours. It'd be great if you'd also send us a message or comment saying you've used our content, as well.
And... well, that's really all there is to say about licensing.
Now as far as Snake is concerned, Matti will be finishing up most everything tonight and you can expect a post from him talking about it later on. Also, some images that are being included in Snake are coming up from Skyler Sharpe!
As far as attribution goes, simply include a link to the Project: Nectar blogspot, and state what code/images you used of ours. It'd be great if you'd also send us a message or comment saying you've used our content, as well.
And... well, that's really all there is to say about licensing.
Now as far as Snake is concerned, Matti will be finishing up most everything tonight and you can expect a post from him talking about it later on. Also, some images that are being included in Snake are coming up from Skyler Sharpe!
Some cleanup and general improvements
I've gone ahead and made XMLImageLoader and TextConfigLoader into static classes so they can be easily accessed around the entire program without shoving references of them everywhere.
I've also cleaned up some code, and added some new variables into the cfg:
#Global Game Settings
#start_speed is measured in milliseconds. the higher it is, the slower you will start off.
#300ms default
start_speed=300
#food_speed is the amount that a snakes speed will be modified when eating food. higher is slower.
#0.95 default, between 0 and 1
food_speed=0.95
I'm considering adding something like "max_speed", but not sure.
Anyway, now what needs to be coded in is:
- Adding of food
- Adding of snake body parts
- Adding of the secondary player
- Actually loading the players' respective keyboard configuration
- Possibly adding keyboard events instead of shitty input polling that XNA uses
Also, I'd like to take this moment to announce that Skyler Sharpe will be becoming a member of our team as a graphics artist. He's going to provide some imagery for this Snake game, so I'm going to hold off on posting any screenshots until he's sent them to me.
And on a more personal note, I've had some health problems these past few days, so it's been very hard for me to do anything. On top of this, I'm moving, and my new landlord is just absolutely fucking me over as best as he possibly can, so things are very stressful. I apologize for my lack of daily updates as promised, and assure you they will exist as soon as everything gets straightened out in my life (which shouldn't be too much longer). Thankfully, I'm not the only programmer on this team, so I believe Matti will be able to pick up the slack. I'm unsure if I'll be able to do any more work on this project, but there really isn't too much that has to be done. It's honestly too bad, too, since I really do feel online multiplayer could've been done without much hassle. Maybe we'll come back to this project in a few weeks from now and throw in some net code.
I've also cleaned up some code, and added some new variables into the cfg:
#Global Game Settings
#start_speed is measured in milliseconds. the higher it is, the slower you will start off.
#300ms default
start_speed=300
#food_speed is the amount that a snakes speed will be modified when eating food. higher is slower.
#0.95 default, between 0 and 1
food_speed=0.95
I'm considering adding something like "max_speed", but not sure.
Anyway, now what needs to be coded in is:
- Adding of food
- Adding of snake body parts
- Adding of the secondary player
- Actually loading the players' respective keyboard configuration
- Possibly adding keyboard events instead of shitty input polling that XNA uses
Also, I'd like to take this moment to announce that Skyler Sharpe will be becoming a member of our team as a graphics artist. He's going to provide some imagery for this Snake game, so I'm going to hold off on posting any screenshots until he's sent them to me.
And on a more personal note, I've had some health problems these past few days, so it's been very hard for me to do anything. On top of this, I'm moving, and my new landlord is just absolutely fucking me over as best as he possibly can, so things are very stressful. I apologize for my lack of daily updates as promised, and assure you they will exist as soon as everything gets straightened out in my life (which shouldn't be too much longer). Thankfully, I'm not the only programmer on this team, so I believe Matti will be able to pick up the slack. I'm unsure if I'll be able to do any more work on this project, but there really isn't too much that has to be done. It's honestly too bad, too, since I really do feel online multiplayer could've been done without much hassle. Maybe we'll come back to this project in a few weeks from now and throw in some net code.
It lives! ...kinda
So now our snake has little a head that is capable of movement.
Due to the looming deadline, I decided to forgo actually implementing the different components properly, input handling is right now implemented terribly, it will just favor certain keys over others if several are pressed and there is currently no configurable support for multiple keymaps.
Speaking of keymaps, XNA's default input handling is terrible, all we get is an array containing the current status of the keyboard/gamepads and that's it, no events, no timestamps, just a damn array. Another fun thing about it is that there seems to be no elegant way to convert strings into keys, as the keyboard state array is presented in enums. We'll need to implement some kind of event-based keyboard handler later on, because this just won't do.
I see my partner here has been posting a whole bunch of code, but I don't feel like mucking about and copying all of that stuff over here right now, especially as it needs a good amount of tidying up before being presentable.
Eugh, I shouldn't write when tired.
Thursday, February 17, 2011
TextConfigLoader
So, we needed a configuration file to place... well, configuration settings in. This means we'd need a loader, thus, TextConfigLoader.
Thinking about it, the necessary functions of this would be to return values from the config file to the program, to allow for comments in the config file, and to allow for simple assignments such as "texture_path=texture/".
The result:
As you can see, I've added simple error handling. If a setting doesn't exist, it will throw an error. If the settings file is incorrectly formatted or non-existent, it will throw an error.
On a side note, I believe I have tonsillitis. Updates may become slow if it gets worse than it already is.
Now that configuration & loading/drawing of textures is out of the way, we can begin coding the game.
Thinking about it, the necessary functions of this would be to return values from the config file to the program, to allow for comments in the config file, and to allow for simple assignments such as "texture_path=texture/".
The result:
class TextConfigLoader { Dictionary<string, string> config; public TextConfigLoader() { config = new Dictionary<string, string>(); } public bool LoadConfig(string location) { try { StreamReader streamReader = new StreamReader(location); string configText = streamReader.ReadToEnd(); streamReader.Close(); string[] configArray = configText.Split('\n'); foreach (string s in configArray) { if (!s.StartsWith("#") || s.Length == 0) { string[] configLine = s.Split('='); config.Add(configLine[0].ToLower(), configLine[1]); //lowercase the setting name so that casing does not matter } } return true; } catch { throw new Exception("Error loading settings.cfg. Incorrect format or nonexistant file."); } } public string GetSetting(string settingName) { settingName = settingName.ToLower(); //lowercase the setting name so that casing does not matter string value = ""; //if TryGetValue fails to get the value, throw an exception. otherwise, return the value. if (!config.TryGetValue(settingName, out value)) { throw new Exception("Setting does not exist in settings.cfg: " + settingName + "\nPlease check your settings.cfg file."); } return value; } }
As you can see, I've added simple error handling. If a setting doesn't exist, it will throw an error. If the settings file is incorrectly formatted or non-existent, it will throw an error.
On a side note, I believe I have tonsillitis. Updates may become slow if it gets worse than it already is.
Now that configuration & loading/drawing of textures is out of the way, we can begin coding the game.
Summarizing: XMLImagerLoader & XMLImage
Due to lack of sleep, I updated XMLImageLoader and XMLImage to actually load the image. This was accomplished using Texture2D's FromFile method. Matti drew up some little 16x16 sprites, I wrote them into our texture XML file, and now they're drawing to the screen just fine.
So let's quickly summarize XMLImageLoader & XMLImage, by defining what they are, what they accomplish, how they do it, etc. etc.
I'll try to keep this short.
XMLImageLoader takes an XML file and reads through it. The format of this file is as follows (and currently resides as /texture/textures.xml):
So, as you can see, there are multiple (and, technically, there could be infinite) elements called "image". Inside each is a name, width, height, and file location. XMLImageLoader will read through this XML and put each image element into a XMLImage object. This object will then attempt to load the texture. As a precautionary effort, I have made it so that if the XMLImage class cannot find the image file, or it fails to load for any reason, a boolean value is set to false (notifying the program that this file failed to load), and a default texture is loaded. This way, artists wishing to test new images who make a typo somewhere or otherwise mess something up, can easily identify the problematic texture and investigate what exactly went wrong.
Furthermore, once an artist is on-board with our team, I want to add support for texture packs, and easy reloading/swapping of the texture packs with a keypress in-game. With this, artists can easily see what looks good and what doesn't.
Texture packs would be accomplished by having a file in our main texture directory, perhaps called "texturepacks.xml". In addition to this file, there would be several directories, each containing appropriate imagery and a "pack.xml" (name subject to change) file. "pack.xml" would be essentially what texture.xml is right now, and texturepacks.xml would simply be an index of all the texturepacks installed, and, if any, their respective variables.
Moving on, I'd like to speak a bit more about the actual game. We will absolutely be including local multiplayer, likely only two-player, though. We'd like to add support for the 360 controller, as well, since this is a very simple thing to do.
"AwesomeSnake" (as we love abbreviating our games with the word "Awesome") will have a nice little configuration file that can be editted. For the sake of user simplicity, it will not use XML, and will instead be a simple text based configuration (ie, player1_color=#FF44DD). Due to time constraints and the hassle of adding in menus, we will likely not include an in-game config editor. Writing text input code is a pain in XNA, so we'll put that off until the next project.
Multiplayer will be an interesting addition to this. I'm thinking co-operative and versus modes will be included, so as to suit all playstyles (and really, it's just a difference between one score, and two scores).
I didn't keep this short. Oh well.
So let's quickly summarize XMLImageLoader & XMLImage, by defining what they are, what they accomplish, how they do it, etc. etc.
I'll try to keep this short.
XMLImageLoader takes an XML file and reads through it. The format of this file is as follows (and currently resides as /texture/textures.xml):
<?xml version="1.0"?> <imageset> <image> <name>grey</name> <width>16</width> <height>16</height> <file>grey.png</file> </image> <image> <name>red</name> <width>16</width> <height>16</height> <file>red.png</file> </image> </imageset>
So, as you can see, there are multiple (and, technically, there could be infinite) elements called "image". Inside each is a name, width, height, and file location. XMLImageLoader will read through this XML and put each image element into a XMLImage object. This object will then attempt to load the texture. As a precautionary effort, I have made it so that if the XMLImage class cannot find the image file, or it fails to load for any reason, a boolean value is set to false (notifying the program that this file failed to load), and a default texture is loaded. This way, artists wishing to test new images who make a typo somewhere or otherwise mess something up, can easily identify the problematic texture and investigate what exactly went wrong.
Furthermore, once an artist is on-board with our team, I want to add support for texture packs, and easy reloading/swapping of the texture packs with a keypress in-game. With this, artists can easily see what looks good and what doesn't.
Texture packs would be accomplished by having a file in our main texture directory, perhaps called "texturepacks.xml". In addition to this file, there would be several directories, each containing appropriate imagery and a "pack.xml" (name subject to change) file. "pack.xml" would be essentially what texture.xml is right now, and texturepacks.xml would simply be an index of all the texturepacks installed, and, if any, their respective variables.
Moving on, I'd like to speak a bit more about the actual game. We will absolutely be including local multiplayer, likely only two-player, though. We'd like to add support for the 360 controller, as well, since this is a very simple thing to do.
"AwesomeSnake" (as we love abbreviating our games with the word "Awesome") will have a nice little configuration file that can be editted. For the sake of user simplicity, it will not use XML, and will instead be a simple text based configuration (ie, player1_color=#FF44DD). Due to time constraints and the hassle of adding in menus, we will likely not include an in-game config editor. Writing text input code is a pain in XNA, so we'll put that off until the next project.
Multiplayer will be an interesting addition to this. I'm thinking co-operative and versus modes will be included, so as to suit all playstyles (and really, it's just a difference between one score, and two scores).
I didn't keep this short. Oh well.
Wednesday, February 16, 2011
XMLImageLoader
I've just completed the XMLImageLoader class (and accompanying XMLImage class). XMLImageLoader loads up an XML file containing data on images for use in the game, then puts each images data into an XMLImage object. These are held together by a Dictionary, and have strings to identify them by. Later, support for animations will be added, but Snake doesn't require animations, it can be done programatically.Something I had some difficulty with is reading the XML files. Reading an XML file is painful, as your best option is to just scan through each node and make some seriously bad assumptions. I couldn't seem to find a way to do it more effectively, and resulted in this:
while (reader.NodeType != XmlNodeType.EndElement && reader.Name != "image") { if (reader.NodeType == XmlNodeType.Element) { switch (reader.Name) { case "name": reader.Read(); //Read to XmlNodeType.Text name = reader.Value; reader.Read(); //Read to XmlNodeType.EndElement break; case "width": reader.Read(); //Read to XmlNodeType.Text width = int.Parse(reader.Value); reader.Read(); //Read to XmlNodeType.EndElement break; case "height": reader.Read(); //Read to XmlNodeType.Text height = int.Parse(reader.Value); reader.Read(); //Read to XmlNodeType.EndElement break; case "file": reader.Read(); //Read to XmlNodeType.Text file = reader.Value; reader.Read(); //Read to XmlNodeType.EndElement break; } } reader.Read(); }
However, this code now lays the groundwork for image loading in our games. It's built in a way that we can expand upon it later if need be.
Tomorrow, will add support for the actual loading of images into the game.
Tuesday, February 15, 2011
Project #1: Snake
Our first project will be Snake. It's an excruciatingly simple concept: on a grid, an object controlled by the player moves around with a tail following behind it. Other small objects will appear, and the player's goal is to move their "snake" over those objects. Every time the player consumes another object, the snake's tail will grow in length.
Not only will this be simple to program, it will be simple to design, and will require little art. I expect we will have no trouble meeting the deadline of next Tuesday (February 22nd), and in fact, may complete it earlier.
Our design will include some slight alterations. To begin with, support for power-ups would be ideal. The original snake gameplay is fairly boring, so anything that can increase the enjoyability of the game would be useful. However, power-ups can easily be added in after the core gameplay is finished, with no real issues, so we will ignore them until we're done with the basics.
More importantly is multiplayer. Local multiplayer is a must, and I'd like to stress that almost every game we produce will at least have some form of multiplayer. Right now, I'm avoiding having to write network code (although, it is sort of my specialty) because it can take quite a long time to get right, and introduces many bugs that are hard to track down in a small amount of time (for instance, a week). But, if we complete our Snake clone significantly before our deadline, it might be possible for us to include online multiplayer as well.
On a final note, I'd like to speak about the first piece of code that will be written: a simple graphics loader based off of XML. It will function in such a way that creating "skins" for games will be easy -- which, when we actually get a real artist on board, will easily allow him or her to create images for the game; testing them out would be the simple procedure of placing them in a directory and reloading the game.
I'll be posting daily (possibly even more) on Project #1's status. I'd like to have the XML-based graphics loader complete by the end of today (Tuesday).
Not only will this be simple to program, it will be simple to design, and will require little art. I expect we will have no trouble meeting the deadline of next Tuesday (February 22nd), and in fact, may complete it earlier.
Our design will include some slight alterations. To begin with, support for power-ups would be ideal. The original snake gameplay is fairly boring, so anything that can increase the enjoyability of the game would be useful. However, power-ups can easily be added in after the core gameplay is finished, with no real issues, so we will ignore them until we're done with the basics.
More importantly is multiplayer. Local multiplayer is a must, and I'd like to stress that almost every game we produce will at least have some form of multiplayer. Right now, I'm avoiding having to write network code (although, it is sort of my specialty) because it can take quite a long time to get right, and introduces many bugs that are hard to track down in a small amount of time (for instance, a week). But, if we complete our Snake clone significantly before our deadline, it might be possible for us to include online multiplayer as well.
On a final note, I'd like to speak about the first piece of code that will be written: a simple graphics loader based off of XML. It will function in such a way that creating "skins" for games will be easy -- which, when we actually get a real artist on board, will easily allow him or her to create images for the game; testing them out would be the simple procedure of placing them in a directory and reloading the game.
I'll be posting daily (possibly even more) on Project #1's status. I'd like to have the XML-based graphics loader complete by the end of today (Tuesday).
Project: Nectar
What is Project: Nectar?
Project: Nectar is the resulting computer games designed by a small group of people who wish to further their knowledge of game and software development. To do this, the group will produce a new game every week, and then release it on this website in whatever state it currently is.
What is your goal?
Our goal is to eventually be able to produce high-quality games at a rapid rate. We expect to accomplish this by a) writing a large amount of useful code that can be used in a variety of applications, b) gaining knowledge of the XNA Framework and C#/.NET programming, and c) gaining experience with programming in general.
Who are you?
Currently, we consist of two programmers, Matti and Chris, a single artist, Skyler Sharpe, a level designer, David Kaye, and a music artist, Lorenzo Claerhout. We're still looking for more artists and might even be willing to take on another programmer. Way in the future, as in, a few months from now, we'll be needing writers, so if you think you can do any of that, send Chris Walker a message or just go ahead and respond to this post.
Why the name "Nectar"?
Programming is a relaxing intellectual experience in which you can sit back and enjoy yourself. "Nectar" easily represents the joys of programming, as both are sweet and rewarding.
Subscribe to:
Comments (Atom)