Day 22 - Another 8 Hours

Here's another full day of programming for me. I started to put in the star power up when I realized that I had already coded most of it! The file just wasn't included in my solution! Once imported I changed it to work with my new framework and bam, another new object. Getting Mario to actually become invincible was another matter though. It got me thinking again about collision detection and how to do it better. When 2 things on screen collide they both call the OnStomp, OnHeadbutt, or OnSideCollision functions depending on where each object is located on screen. Then each thing checks what it collided with and does the appropriate action... The thing is this collision detection really only needs run on objects which are moving (as un-moving objects will never collide with anything.) So for example if Mario headbutts a block it would enter the Mario class via OnHeadbutt(Block block), then Mario would react appropriately by stopping his upward movement, and finally it would call block.Activate() and the block would take whatever action it needs. This will be another setback because most of my classes will need re-written.

Then again, I could just leave it and continue on my merry way.

I also dug up a spikey enemy that I previously coded and got him working. Then I decided to add that invisible block which holds a 1-up in the middle of level 1-1. Currently it's just a regular block which isn't drawn on screen. Mario can still stand on it and it also blocks his horizontal movement... Yet another reason why I want to rewrite my collision detection...

I fixed a few other bugs and as a finish for the day I added all the objects to the first level. Aside from the special area through the pipe I almost have the first level completely finished!

No video for today...

Day 21 - 8 Hours a Day

What a day for programming! I had a great time working out some bugs and adding new content to my game! I swear if I could work like this everyday, then I would be finished with this game in under a month.

I started out by adding a loading screen which shows the level number and how many lives the player has. Then I thought "You know what I'm missing? A heads up display!" So I implemented that as well! It's printed on top of everything else and simply shows the player's score, coins, and level. I might use it later for debugging as well.

At that point, I added points for all the enemies and then figured I should fix the bugs with how enemies interact. The turtle shell now properly kills other enemies only when it's moving, Mario's fireballs explode when they hit enemies, and Mario can properly die now! He still has some issues moving from big Mario to little Mario but that's for another day.

Finally, I added the flagpole and a second level. The end animation is kinda janky and I didn't have a flag sprite in my spritesheet (so I just used a coin instead,) but it works and moves onto the next level.

I think I need to start tracking bugs and new features to prevent myself from getting sidetracked. It's hard to keep track of everything. Once I finish adding a feature, I often forget where to go next and spend time browsing Facebook or playing my game looking for bugs.

Here's a video of me screwing around with enemies!

Day 20 - Game State Management

Game State Management is perhaps the most fundamental thing about game programming. I've been avoiding it until now, but I need to start implementing lives and new levels soon. To do this the game needs to transition between different "states". For example, one state would be a title screen, one state would be the actual gameplay, and finally a game over state. To make all this happen, all the logic needs to reside on screens. When one screen exits, it will destroy all the images and things it was using before the next screen is loaded.

There is a great example about GSM in the XNA tutorials. It contains a bare-bones screen manager with a bunch of example screens. In about an hour I merged this code with my game and got it working. Now there is a menu screen which transitions to the first level when the user hits enter on their keyboard! Whooooo!

Things to do from here:

1. Spruce up the title screen
2. Add a level transition screen which shows the level number and number of lives left
1. When the level starts or Mario dies the level transition screen should be shown and the level should be restarted
3. Add a transition to the next level
4. Add a Game Over screen which routes back to the menu screen

I've been super busy this week (getting home around 7pm everyday!) so I haven't had much time to work on this. I'm gone for the weekend but have nothing to do Monday and Tuesday so hopefully I'll get a lot done then!

No video for today...

Day 19 - A Good Day

Some days my code just comes together and I can get tons of work done. Other days I can stare at my screen for hours and only get a few lines in. Today was the former.

I got my collision detection all finished up. Now I'm working on writing interactions between different game objects. For example, only Mario can break blocks and hit question blocks. Enemies need to bounce off each other and walls. Mario needs to power down or die when he hits an enemy. Everything needs to be accounted for.

This was also the first time I tested my Koopa Troopa enemy since I wrote it a week ago. I was surprised that it worked fairly well when I first loaded it up. Just a few more tweaks and we're in business!

Here's me playing around in the world.

Day 18 - Collision Woes

Now that I've changed blocks into game objects instead of tiles it completely changes the way my collision needs to work. Previously since all the tiles were laid out on a grid I could quickly retrieve a tile given any position on screen. Now since the blocks could theoretically be placed anywhere, I need to iterate through them and then each object needs to figure out what to do when it collides with it. This sounds like a lot of work and... It is.

No big changes and no video for today. My brain isn't working.

Day 17 - Adding and Removing

I finished up my level builder! All the game objects are added and removed from the screen as the player moves around it.

Next up is dealing with collision detection. I commented out everything that I had in place before because I need to come up with a better system. I'm thinking of making a "moving object" class since the only moving things can collide with other things. I don't need to check if one stationary block hits another stationary block because that will never happen; It's just wasting CPU cycles. I'll need to sleep on it.

Anyway, here's my awsome changes in action!

Day 15 and 16 - Branching and Merging

I had to branch my code for the first time not because I was trying to implement crazy new features, but simply because I forgot to sync my code! I've been working on the level builder but when I went to work I realized all my changes were on my home PC. I didn't want to re-write that code so I made a branch and went along creating some new enemies. They haven't been tested yet but theoretically should work with a little more tweaking.

I merged the branch and master code together once home and continued working. The level builder is starting to come together! As Mario moves forward, new rows of blocks (and enemies in the future) are added to the screen. My FPS shot up from 1500 to 5000+ just with this change! Next up is removing the blocks and game objects once they pass a certain threshold outside the viewable screen. Then I just need to revise my collision detection algorithms and we'll be back in business!

Day 14 - Refactoring

I made some very big changes to the underlying engine of my game. Hopefully by the time I'm done, adding in new features will be a breeze.

I changed the GameObject class in a big way. Previously, all game objects were required to have a Sprite associated with it. Now, each object can decide for itself whether it wants to display a Sprite, Animation, or something else. I made the Draw and GetBoundingRectangle methods abstract, which means that all classes that inherit from GameObject must implement these methods. This cleaned up my code immensely, but each object needed to be refactored to accommodate the change.

Next I got rid of the animation handler. Now I'm treating all animations the same way as sprites, which means that they need to draw and update themselves.

Finally, I renamed the "Tile Manager" to "Level Generator" which will read the level file and add all objects to the screen. This part isn't finished yet because I ran out of time, but it will solve number 1 and 2 of my previous post.

No video for today because the collision detection is currently broken!

Day 13 - Back in Action

I had a mostly free day at work so I finally was able to sit down and get back into the swing of things. I've been super busy at school planning lessons and having classes (5 per day!) while HAJET web development has taken up most of my free time at home.

I got a surprising amount of work done on the game today. The code just fell into place with no errors or extra fiddling required. I fixed the issue I had with the mushroom spawning by adding a flag to stop collision detection. The mushroom was trying to pop out of the box, but my collision detection algorithm said "No!" and prevented it from moving. Once finished I added the powerup to Mario. He now turns into big Mario when colliding with the mushroom!

Next I implemented the fireflower powerup and everything that goes along with it. Getting it to pop out of the item box was easy; It's the same as the mushroom. Transforming Mario into fire Mario was also a simple change. Finally, implementing the fireball took some time. It's still not quite right because Mario can shoot an unlimited number of fireballs regardless of how many are on screen. I'll fix it later.

Last, I added my first enemy, a goomba! He slowly walks across the ground, bouncing off walls, falling off blocks, and dying when Mario jumps on or shoots him. I've got a feeling that implementing the other enemies will be quick and painless too!

I have a few things to clean up in my code. I'm not looking forward to fixing this stuff because I know it will take a lot of time and it's not fun.

1. Add an enemy manager. This will spawn the enemies when Mario gets close and remove them when they are too far outside the view-able screen.
2. Revise the tile manager. Currently it loads all the tiles into memory at once. Only the tiles on screen and a few rows off screen should be loaded at one time. The game should be running around 6000fps, but it's only running at 1500fps because of this.
3. Fix the game object class. Not all game objects have sprites associated with them, some have animations instead.

Here's the video!

AJAX is like C# right?

No work on Mario today because I was preoccupied with my other volunteer project. I spent the day studying up on jQuery and AJAX to add a few new features to the website I manage. I ended up with a quite nice FAQ dropdown menu.

Here We Are Again

I'm back from vacation finally! I feel bad for starting my programming later than I originally anticipated. All is not lost though! I recently became webmaster of the Hokkaido JET Association and spent the past few days updating content and rearranging articles.

Today I installed .NET 4.0, Visual Studio C# Express 2010, and XNA on my computer at work. As a result, I spent most of the day working on Mario. I fixed up issues with the mushroom, implemented crouching, and rewrote the movement of Mario and slightly altered the collision detection. I began adding a fireflower but then realized I don't have all the art-assets loaded into my solution yet. All the extra images are at home. I'll pick up there later.

No movie today...

Vacation

I've been on vacation since July 20th and will continue to be away until August 13th. The programming will resume then.

Day 12 - More Mushroom Collisions

Today I added collision detection between objects so now everything on screen can play nicely with each other. I of course ran into some snags along the way which always seems to happen when I move code around. I also spend a good bit of time modifying my spritesheet to include big Mario and fire Mario. I finally got everything working but when I ran the game the mushroom didn't appear. I debug and see that it spawns properly, slowly rising out of the question mark brick, but nothing appears on screen. I didn't modify the code which draws items on the screen but threw in some breakpoints just to be check. Sure enough it is drawing properly.

This issue has to wait until tomorrow because I can't stay up any longer messing with it. Tiredness is not helping me program successfully.

Day 11 - The Mushroom

It's great when things just come together.

I moved all the collision detection stuff into the moving game objects so now any object I create will automatically respond properly to gravity and tiles! Getting the mushroom to move and bounce off objects was a simple task.

The next not-so-simple task is to have the mushroom disappear and power up Mario when it touches him. For this I need to slightly modify my OnHit() classes so everything plays together nicely. As it stands now, if I implement a jumping enemy it will also be able to break blocks. I started the changes but haven't finished them yet.

Here's a video of the mushroom in action. Nothing too exciting.

Day 10 - Refactoring

My goal today was to have a block spawn a mushroom. I completed that goal, but it took much longer than I originally anticipated.

My code needed refactored (read better organized) rather badly. I had references being passed around to so many objects that it was hard to keep track. For example, if a block needed a texture it first needed to be created by my game class, passed to the tile manager class, and finally given to the block itself. The same could be said about sounds and animations. It was a big headache dealing with all the references and creating variables to store said references. Instead I simply created a few static methods so that these things could be accessed by any object! This made my code much clearer and easier to understand. I don't think I'm done with this change, but it works for now.

Before, when I wanted the block to create a mushroom I would need to pass a reference to the game object list through a bunch of classes to the block. Then the block could add the mushroom to the list.

Now, since the list is static, any object can create a new object just by saying World.AddNewObject(new object)!

No video today because the mushroom doesn't have any collision detection implemented. Tomorrow I'll create some generic algorithms for any object that needs to worry about collisions.

Day 9 - The Camera

I got the camera working today. To do this I needed to add everything on screen to a new class I called World. The camera camera class takes an object to follow (in my case Mario) and moves across the world as Mario moves. I had some issues with the collision detection going bonkers after I implemented it, but soon figured out that my algorithm to find solid tiles on the screen was messed up with the addition of the camera. With everything sorted out, I built the rest of level 1-1 so Mario can run though it!

Today I learned the limitations of my tile manager class because I'm having trouble spawning objects like mushrooms and stars from blocks when they are hit. Each block needs to be able to spawn a new game object... To top it off, when I create an entire level my framerate drops from 6000 to 1500. It gives me new respect for the programmers that did this on hardware over 25 years ago.

 My code is currently torn apart and unplayable at the moment, but here's a video from earlier today.

Day 8 - Bump

I realized today that small Mario can't break brick blocks, but instead they bounce up a few pixels and return to their original positions. I quickly implemented this and also applied the changes to the question mark block. While I was at it I added the coin popping out of the question mark block when it is hit. Finally, I edited my level file to reflect the first level in Mario Bros up until the halfway point. Next time I'll work on getting the camera working so Mario can run through the level!

Unfortunately I only had a small bit of time today to work.

Day 7 - Breakable and Unbreakable Bricks

I had a ton of extra time today so I got a lot accomplished. I feel like it's taking me longer than it should to implement each feature, but I guess that's just from lack of experience.

I finally got around to creating a sound manager. This holds 2 different types of sounds: sound effects and music. Sound effects are triggered once and play until they finish while music supports pausing, stopping, and repeating.

Next I finished up the brick class so it explodes into pieces when Mario hits it. I then implemented the question mark block which simply turns into an empty block when hit. I need to figure out how to load it with an item and have that pop out. I also squashed a bug in my animation class. I was calculating how long until the next animation frame but when one animation moved to the next frame it reset the time value. This caused the other animations to never advance frames! Now each animation holds a value for the time since it last changed frames.

Day 6 - Headbutt

Today I only had about 1 hour to myself. I got a little bit of reorganization and one new feature implemented.

First I fixed the drawing order of sprites so now Mario appears in front of all other objects like clouds and bushes. Next I added 3 methods to my tile class and Mario class: OnHeadbutt(), onStomp(), onSideCollision(). Eventually I will make a generic GameEntity class which holds these 3 methods, but for now they are simply copied into each class that needs them. When Mario hits a block from below, the OnHeadbutt() method is called and the block can respond accordingly. To test this I created a brick block which disappears when Mario hits it from below. Next I'll add some animation to it so we can see the pieces of the block fly away after it is destroyed.

The OnStomp() method will mostly be used by enemies since that is Mario's only way of killing them. It will trigger the death animation and also give the player points. Likewise the onSideCollision() will be used when a shell hits an enemy or when two enemies run into each other. I think implementing enemies is still a ways off yet, but the framework will be available.

Subversion Time

Let me rephrase my original statement about this blog. I will update every day except weekends. This is because I spend most of my weekends away from technology and my PC. For instance, yesterday you could find me sleeping in a small cabin on top of a mountain 200 miles away from here.

Today I played around with collision detection between Mario and the tiles that make up the level. First I needed an indicator to show whether each tile was solid. Next I implemented an algorithm to return the tile from any point on screen. Finally, I looked at where Mario was located and if he was colliding with a tile or not.

This took a lot of experimenting to get it right but I think I implemented a good solution. In previous games I would take every object on screen and compare it to every other object on screen to find collisions. This algorithm becomes very slow as the number of objects increases so I decided to find a better solution. I check each corner of Mario and if that point happens to fall on a solid tile then figure out what to do with Mario. This gives me a constant speed of 4 instead of n^2.

I'm still having a few issues with Mario's movement, but progress is coming along nicely.

If you want to view my source code, check it out on GitHub at https://github.com/Exor/SuperMarimoBros

One Step Back and Three Steps Forward

I don't really understand why I couldn't wrap me head around the physics movement problem yesterday but here goes. I took a step back and wrote down on paper how I need the movement to work. When I took a look back at the code, it was easy to implement. Now Mario walks, runs, and slides properly around the screen. Jumping and gravity still isn't implemented yet because I need to do collision detection with the blocks.

The next thing I did was fix the animation class so now he animates properly. It doesn't look completely accurate yet, but I'm writing it off as "good enough" until I get the rest of the major elements implemented.

Finally, I created a tile manager class which takes a text file and prints out all the objects on screen. Amazingly I got this working my first try without any errors!

There is one bug to note. When Mario is standing still he appears behind all the objects on the screen. This has to do with the order that the sprites are being drawn and should be an easy fix.

Speed, Acceleration, Friction, Time

Today was a complete failure in terms of getting anything meaningful accomplished.

I went through some of my old code and found an XNA library with a few useful functions. I can use the input manager and fps tracker as-is, but the animation manager will need some heavy modification because of the way I did my sprites. The first thing I did was hook up the fps tracker. This allows me to track the frames per second put out by my PC to analyze any problems. For example, if I make a change to the way sprites are rendered and suddenly my FPS drops from 6000 to 4000, I'll know that it was not a very efficient change. It's much easier to debug memory issues and cycle hogs on the spot rather than further down the road when my codebase is 10x as large.

I ran into a big issue when I hooked up the fps tracker. Previously my game was running at a constant 60fps, but suddenly my PC was pushing out frames as fast as humanly (computerly?) possible. This caused my character's movement speed to increase 100 fold. To combat this I need to change my movement algorithm to incorporate elapsed game time. I must be tired or had a brain fart or something because I can't get it working properly. Out of frustration I deleted my current movement code and decided to deal with it tomorrow.

No video for today folks.

I Do Indeed Work Best in the Morning

I decided to slowly adjust my sleep schedule in order work on this game in the morning instead of late at night. I realized that after work I just don't have the energy or willpower to do anything productive. Instead I would like to spend the time relaxing, making dinner, playing video games... Waking up at 5am gives me a solid 2.5 hours to work before work. The only problem is I feel like an old geezer.

Today I implemented a sound manager and inserted music from Mario RPG. It begins playing as soon as the game starts and loops indefinitely. Next up I added some blocks to the screen. Currently my implementation is awful because I have to manually set which pixel on screen I want each block to draw. I want to create a level manager that reads a text file and creates a level based on that. Finally, I added a gravity component so that Mario is constantly falling. Once I implement collision detection with the blocks, he will have a nice platform to stand on.

We Have Animation

Today I dove right in and created new classes for sprites and animations. Everything that has only 1 frame (such as Mario standing still) will be a sprite, and everything else will be an animation. Along with that I needed to add Mario's current state so the game knows if he is walking, running, dying, ect. It was rather easy to hook up.

Unfortunately I spent the majority of my time today trying to create a sprite sheet. I found out that specifying individual pixels for each sprite was rather annoying, so I broke up everything into 16x16 pixel pieces. Everything in the game can be broken up into these blocks which I will use for my advantage later on. I may eventually create some sort of image packer program to streamline the process, but I'm not too worried about that right now. It will become more necessary as the number of sprites increase.

Here's the end of the day progress.

Installation Complete. Please Restart Your PC.

In my experience, the hardest part about creating a video game is finalizing it. If you don't have a clear vision of the final product, then your project is doomed to stay unfinished. This is why I've chosen a pre-existing game to copy, Super Mario Bros for the NES. My goal here is not to make money nor distribute my code so I don't have to worry about copyright infringement. I chose Mario as a base because the rules of the game are already well defined; I know exactly how the game should look and feel once I'm finished. As an added bonus, I don't have to worry about creating art assets which will free up my time for more coding goodness.

My goals by the end of this project are to:

1. Create a level editing tool which will allow me to easily create levels.
2. Use the tool to recreate the first level of Super Mario Bros.
3. Build a library of functions for use in future games.

Having a set list of goals is also a good way to keep motivated.

Today I installed Visual C# 2010 Express along with the XNA 4.0 framework on my PC. I grabbed a sprite-sheet from Google and cut out a Mario sprite. I created a Mario class, added keyboard controls, added in a coefficient for velocity and friction, and finally flipped the sprite to look the proper direction when moving. So far so good!

Oh look he's moving!

Booting Up, Please Wait...

This blog is my motivation.

I have been procrastinating a lot recently and had a reality check last night. I've already decided that I'm not going to be an assistant teacher forever and I need to start working towards my future. As of 5 months ago I didn't know what I wanted to do with my life and as such spent every extra minute studying Japanese. I finished the advanced course offered by the JET program and decided to stop. Unfortunately the free time I now had went into unproductive activities like playing video games. This needs to stop.


It has been my lifelong dream to create video games. I messed around with the idea in high school. I got a degree in Computer Science. I spent my free time at work dabbling in XNA. Now I'm stuck as an assistant teacher which I love but is not a career path. This position offers no advancement, no raises, and no promotions. I sign a yearly contract to continue doing the same thing I'm doing now. 


I need some sort of motivation to keep me going. In the past I've always started a new project, started learning some basic concepts, started digging deeper, but nothing was ever finished. I need to see this through to completion and this blog is my motivation. I will post my ideas and how I execute them every day from this day onward until I leave Japan. 


I promise myself that in 1 years time I will become a video game developer.


Signed: Jon Slabaugh