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.

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.

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

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

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!

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.

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.

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:

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):

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

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();
}

XMLTextReader (which is what "reader" is in the above code snippet) only seems to have the ability to read to the next node. I can't tell it to read to the next element, or to read to a specific element. I would have to create loops to do specifically that. Perhaps it would be useful to later create a class that inherits from XMLTextReader but has a better selection of functions to move around the XML file? Certainly something like this already exists... Oh well.

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.

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

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.