This repurposed blog has once again been neglected. I'm back doing Ruby and having great fun. If I do start blogging again, it probably won't be on blogger and definitely won't be this blog. :)
Adios
Game Dev Journal
I'm repurposing this neglected blog to act as a record of my journey into game development.
Tuesday, September 06, 2011
Friday, March 25, 2011
Breakout Week 4: Building a Wall (Part 2)
This is part two of my two part post of building the wall in my Breakout game.
With the wall in place, the next step is to make the ball break the bricks as it hits the wall. This bring us back to collision detection and response again.
With the wall in place, the next step is to make the ball break the bricks as it hits the wall. This bring us back to collision detection and response again.
I did quite a bit of reading on this because there are a number of ways you could do it. The collision detection part can be fairly easy, where you just check if the ball is within the bounds of each brick, but it gets complicated by the fact that once you know a collision occurred, you also need to know which side of the brick the ball hit because it could hit any of the brick's four sides or corners. You need this in order to know in which direction to bounce the ball after it hits the brick. There seemed to be a couple common techniques for doing this, well common ones I found in a quick google search at least.
The first technique involved looking at the previous position of the ball and it's position relative to the brick. For example, you create regions based on the edges of the brick and find which region the ball was in before it hit the brick. The regions would like this:
Labels:
collisions,
gamedev,
xna
Monday, March 21, 2011
Breakout Week 4: Building a Wall (Part 1)
I had a pretty busy week last week, okay that was mostly due to the fact that Dragon Age 2 came out and I spent several nights playing and not sleeping. Despite that I did manage to find some time to work on Breakout. The goal for this week was to get the wall drawn and handle the collisions of the ball against the wall. I did manage to get that all working, which I was pretty happy about, but I also came to the conclusion that the way I am handling the collisions is not very good, particularly for the wall.
Because there is a lot to go through with the collision handling and I also want to cover how I setup and draw the wall I'm going to split this week's post in two. This post will cover the setup and drawing of the wall and it should be relatively short. I'll write another post around mid this week where I'll cover handling the collision of the ball against the wall, the problems with my approach and how I'm going to improve it. So for now, lets get stuck into the setup of the wall.
As usual, we have a Wall class that handles the setup and drawing of the wall. Just like the paddle and ball it is created by the Breakout class. Here are the main instance variables of the wall.
Because there is a lot to go through with the collision handling and I also want to cover how I setup and draw the wall I'm going to split this week's post in two. This post will cover the setup and drawing of the wall and it should be relatively short. I'll write another post around mid this week where I'll cover handling the collision of the ball against the wall, the problems with my approach and how I'm going to improve it. So for now, lets get stuck into the setup of the wall.
As usual, we have a Wall class that handles the setup and drawing of the wall. Just like the paddle and ball it is created by the Breakout class. Here are the main instance variables of the wall.
class Wall { private const int bricksPerRow = 20; private const double wallHeightRatio = 0.20; private const int numRows = 7; private static readonly Color[] colors = { Color.Red, Color.Orange, Color.Yellow, Color.Green, Color.Blue, Color.Indigo, Color.Violet }; private readonly int screenWidth; private readonly int screenHeight; private float brickHeight; private float brickWidth; private Rectangle wallBounds; private Texture2D sprite; private List<Brick> bricks = new List<Brick>();
Saturday, March 12, 2011
Breakout Week 3: When Balls Collide
This week was all about collision detection and collision response. The plan was to add the ball to the Breakout game, get it moving around the screen and bouncing off the walls and the paddle. I probably did much more research than was required this week since I spent a lot of time reading about various collision detection algorithms and the physics of collision response. It turns out that didn't actually use any of the techniques I read about since a very simple technique works well enough for Breakout. It was worthwhile reading all that though, if for no other reason than I now have a much better appreciation for what I need to learn.
So, research aside, the coding up of the ball itself was very easy, it only took about an hour and half and most of that was spent tweaking various parameters to get the "feel" right. So on to the code.
As with the paddle, there is a class for the Ball with LoadContent, Update and Draw methods that are called by the Breakout class. The Ball tracks it's own state in these instance variables:
This is slightly different to the paddle in that we store the speed as a scalar value and the direction as a vector. The direction is a unit vector so it contains no speed information, which is why we need the speed as a separate variable. The reason I did it this way is that the ball can move in both x and y directions, unlike the paddle, so using a unit vector allows use to calculate directional changes for the ball without needing to worry about the length of the vector, since it will always be 1.
The ball also has a few other instance variables that hold initial states, ranges of speed and position and whether the ball is currently active or dead.
So, once again, all the interesting stuff happens in the Update method:
So, research aside, the coding up of the ball itself was very easy, it only took about an hour and half and most of that was spent tweaking various parameters to get the "feel" right. So on to the code.
As with the paddle, there is a class for the Ball with LoadContent, Update and Draw methods that are called by the Breakout class. The Ball tracks it's own state in these instance variables:
private Texture 2D sprite; private Vector2 position; private Vector2 direction; private int speed;
This is slightly different to the paddle in that we store the speed as a scalar value and the direction as a vector. The direction is a unit vector so it contains no speed information, which is why we need the speed as a separate variable. The reason I did it this way is that the ball can move in both x and y directions, unlike the paddle, so using a unit vector allows use to calculate directional changes for the ball without needing to worry about the length of the vector, since it will always be 1.
The ball also has a few other instance variables that hold initial states, ranges of speed and position and whether the ball is currently active or dead.
So, once again, all the interesting stuff happens in the Update method:
internal void Update(GameTime gameTime) { if (state == State.Active) { UpdatePosition(gameTime); if (position.Y > screenHeight) { state = State.Dead; } else { HandleCollisions(); } } else if (state == State.Dead && Keyboard.GetState().IsKeyDown(Keys.Space)) { LaunchBall(); } }
Friday, March 04, 2011
Week 2: With a Paddle
With all the installation and setup out of the way, this week I finally got to write some code.
I decided that the goal for this week was to get some initial classes laid out for the Breakout game and implement the basics of the Paddle. Let's start with the class design.
When you create an XNA project, it auto-generates a Game class for you. This class is the core of your Game. In it you implement methods for loading content, updating state and drawing a frame. However, I don't think it is the best place to put much game logic. I've always tried to avoid pointing too much custom code into classes that extend from framework classes since it makes it harder to test your own code in isolation and it means large amounts of you own code could break if the framework changes. The Game class will act mainly as glue between my game implementation and the XNA framework's game loop. To this end, I created a Breakout class which is instantiated by the generated Game class. Here is what it looks like:
It's pretty straight forward, Breakout has a Paddle, a Ball and a Wall, just as you would expect. The Breakout constructor is passed in a SpriteBatch instance which it will use to draw all the graphics for the game. The SpriteBatch is created in the Game class's Initialize method, where the Breakout object is also created, like so:
I decided that the goal for this week was to get some initial classes laid out for the Breakout game and implement the basics of the Paddle. Let's start with the class design.
When you create an XNA project, it auto-generates a Game class for you. This class is the core of your Game. In it you implement methods for loading content, updating state and drawing a frame. However, I don't think it is the best place to put much game logic. I've always tried to avoid pointing too much custom code into classes that extend from framework classes since it makes it harder to test your own code in isolation and it means large amounts of you own code could break if the framework changes. The Game class will act mainly as glue between my game implementation and the XNA framework's game loop. To this end, I created a Breakout class which is instantiated by the generated Game class. Here is what it looks like:
public class Breakout { private SpriteBatch spriteBatch; private Paddle paddle; private Ball ball; private Wall wall; private int screenHeight; private int screenWidth; public Breakout(SpriteBatch spriteBatch) { this.spriteBatch = spriteBatch; this.screenWidth = spriteBatch.GraphicsDevice.Viewport.Width; this.screenHeight = spriteBatch.GraphicsDevice.Viewport.Height; this.ball = new Ball(); this.paddle = new Paddle(screenWidth, screenHeight); this.wall = new Wall(); } }
It's pretty straight forward, Breakout has a Paddle, a Ball and a Wall, just as you would expect. The Breakout constructor is passed in a SpriteBatch instance which it will use to draw all the graphics for the game. The SpriteBatch is created in the Game class's Initialize method, where the Breakout object is also created, like so:
Friday, February 25, 2011
Week 1: Setting up and Installeering
This week was not the most exciting in terms of this project, but necessary nonetheless. It was all about setting up my development environment and a bit of troubleshooting to get things working.
First of all, I grabbed a copy of Windows 7 professional and installed that into a Bootcamp partition on my iMac. This didn't exactly go without a hitch, Windows 7 doesn't seem to include the right ATI driver for the graphics card in the late 2009 iMacs. So when you get to the third stage of the installation, the screen goes blank... not very helpful. Thankfully there is a pretty simple work around that involves booting up in repair mode and deleting the ATI driver. This forces Windows to use a generic driver, but one that actually works. So with that done I could complete the installation and then install the boot camp drivers to get a proper ATI driver for the graphics card.
From there it was a matter of installing some development tools. I got Visual Studio Express Edition with Windows Phone Developer Tools, which in fact contains XNA Game Studio, not that you would know by the product name. The install for this went without a hitch. I also installed Git Extensions, however for some reason the Visual Studio plugin didn't work, I'm not too fussed about that though since I'll probably use the command line most of the time.
With all that setup, I fired up Visual Studio and created a new Windows game project, called Breakout, that I'll use for building my first game. This was simple enough but there was one hitch, I wasn't able to run the game within Parallels, I got an error saying there was no suitable device support HiDef. Fortunately the Internet came to the rescue again. Apparently this is caused by Parallels only supporting DirectX 9. The fix is pretty simple, you just need to right click on the Game project, select Properties, then change the Game Profile to "Use Reach ...", the game should now run and display a beautiful cornflower blue screen.
I also tried out VMWare Fusion as an alternative to Parallels, it also suffered from the same HiDef support problem, so there wasn't really any reason to switch. I'll see how it goes with Parallels for while, I do get the sense that I'm eventually either going to need more RAM, or I'm going to have to reboot into Windows more often, but I'll see how it goes.
---
In order to get up to speed with C# I read through Intro to C# from Objective-C and Java. I've gotta say, it's not the best document. I realise it is only 24 pages, but it seems to really skim over important language features at the expensive of talking about the CLR platform. For example, it has a list of about 15 items that Java has but are different in C# or that C# has but Java doesn't, like indexers, different inheritance syntax, access restrictions on overriden members, clashing interface inheritance but it doesn't actually discuss how C# does it. And yet there is a page and half on garbage collection, which is essentially the same between the two platforms. Oh well, I'm sure I cope.
---
I've also setup a Github project at http://github.com/seangeo/breakout. It's a public project so anyone can grab the code, although at this stage there isn't much to see, hopefully it will get more interesting.
Next week I'm going to start getting familiar with the XNA API and draw some sprites. If I get time I might make them move across the screen!
First of all, I grabbed a copy of Windows 7 professional and installed that into a Bootcamp partition on my iMac. This didn't exactly go without a hitch, Windows 7 doesn't seem to include the right ATI driver for the graphics card in the late 2009 iMacs. So when you get to the third stage of the installation, the screen goes blank... not very helpful. Thankfully there is a pretty simple work around that involves booting up in repair mode and deleting the ATI driver. This forces Windows to use a generic driver, but one that actually works. So with that done I could complete the installation and then install the boot camp drivers to get a proper ATI driver for the graphics card.
From there it was a matter of installing some development tools. I got Visual Studio Express Edition with Windows Phone Developer Tools, which in fact contains XNA Game Studio, not that you would know by the product name. The install for this went without a hitch. I also installed Git Extensions, however for some reason the Visual Studio plugin didn't work, I'm not too fussed about that though since I'll probably use the command line most of the time.
With all that setup, I fired up Visual Studio and created a new Windows game project, called Breakout, that I'll use for building my first game. This was simple enough but there was one hitch, I wasn't able to run the game within Parallels, I got an error saying there was no suitable device support HiDef. Fortunately the Internet came to the rescue again. Apparently this is caused by Parallels only supporting DirectX 9. The fix is pretty simple, you just need to right click on the Game project, select Properties, then change the Game Profile to "Use Reach ...", the game should now run and display a beautiful cornflower blue screen.
I also tried out VMWare Fusion as an alternative to Parallels, it also suffered from the same HiDef support problem, so there wasn't really any reason to switch. I'll see how it goes with Parallels for while, I do get the sense that I'm eventually either going to need more RAM, or I'm going to have to reboot into Windows more often, but I'll see how it goes.
---
In order to get up to speed with C# I read through Intro to C# from Objective-C and Java. I've gotta say, it's not the best document. I realise it is only 24 pages, but it seems to really skim over important language features at the expensive of talking about the CLR platform. For example, it has a list of about 15 items that Java has but are different in C# or that C# has but Java doesn't, like indexers, different inheritance syntax, access restrictions on overriden members, clashing interface inheritance but it doesn't actually discuss how C# does it. And yet there is a page and half on garbage collection, which is essentially the same between the two platforms. Oh well, I'm sure I cope.
---
I've also setup a Github project at http://github.com/seangeo/breakout. It's a public project so anyone can grab the code, although at this stage there isn't much to see, hopefully it will get more interesting.
Next week I'm going to start getting familiar with the XNA API and draw some sprites. If I get time I might make them move across the screen!
Saturday, February 19, 2011
Refurbished and Repurposed
I've decided to repurpose this blog as a journal for my foray into game programming.
I've always loved video games and they have always been a big part of my life. When I decided to to return to university after a brief stint as a sound engineer, my main motivation for doing computer science was to end up as a game programmer. I even dabbled in building a MMORPG in my second and third years. However, at some point I took a different direction. I don't really know why, probably a combination of factors: a lack of local jobs and not wanting to move state again, the idea of another industry being the industry that the best people work in (at least in Adelaide) and some sense that it was time for me to grow up and act like an adult; probably why I cut my hair and started wearing button up shirts.
It's just over 8 years since I graduated. I've never been short of work and I've had some great jobs with some great people. However, I still have a nagging regret when it comes to game programming. I keep wondering what would have happened had I kept my sights on that goal and worked towards it. And most of all, game development is still something I really want to do. Basically I don't want to be in the position 8 years from now where I'm wondering the same thing, only it would be even harder to do something about it.
So, this marks a turning point, my hair is long again and I prefer t-shirts.
To have any chance at a game development career, I need to learn game programming techniques, libraries and platforms, because at the moment, my game development knowledge is pretty minimal, I've spent all my time doing business/commercial development. It's not going to be easy or quick and I have a lot to learn, but really I have nothing to lose. I still need to work and make a living so I need something I can do in my spare time and with a plan that keeps me focussed. I'm going to put about 3 hours a week into building small tech demos or games that will teach me something about game programming. I'll also write a weekly blog post that outlines what I did, what I learnt and what I plan to do next week. If I can stick to this I should learn a decent amount in a reasonable amount of time, but most importantly have a set of demos for a portfolio and a journal to go with it. And from there, we'll have to see.
Which brings me to the first little project. I've spent a bit of time reading and thinking about where to start, it does make sense to use Windows for the project initially though, even though I normally use a Mac and have an iPhone I could develop for, however, the games I would want to work on are PC or console games and most game jobs require C/C++ on Windows, so Windows just makes sense. I don't want to get overwhelmed and discouraged so starting reasonably small would be a good idea, which makes me think starting with XNA Game Studio is a good way to get my feet wet with XBox 360 and Windows development, rather than jumping into the deep-end with DirectX. Even if it is C# as opposed to C/C++, I'm not too worried about that just yet.
I'm going to start by developing a Breakout clone for Windows. This fits the reasonably small criteria but should cover a enough new areas that it should be interesting. I expect to learn about at the least following:
I've always loved video games and they have always been a big part of my life. When I decided to to return to university after a brief stint as a sound engineer, my main motivation for doing computer science was to end up as a game programmer. I even dabbled in building a MMORPG in my second and third years. However, at some point I took a different direction. I don't really know why, probably a combination of factors: a lack of local jobs and not wanting to move state again, the idea of another industry being the industry that the best people work in (at least in Adelaide) and some sense that it was time for me to grow up and act like an adult; probably why I cut my hair and started wearing button up shirts.
It's just over 8 years since I graduated. I've never been short of work and I've had some great jobs with some great people. However, I still have a nagging regret when it comes to game programming. I keep wondering what would have happened had I kept my sights on that goal and worked towards it. And most of all, game development is still something I really want to do. Basically I don't want to be in the position 8 years from now where I'm wondering the same thing, only it would be even harder to do something about it.
So, this marks a turning point, my hair is long again and I prefer t-shirts.
To have any chance at a game development career, I need to learn game programming techniques, libraries and platforms, because at the moment, my game development knowledge is pretty minimal, I've spent all my time doing business/commercial development. It's not going to be easy or quick and I have a lot to learn, but really I have nothing to lose. I still need to work and make a living so I need something I can do in my spare time and with a plan that keeps me focussed. I'm going to put about 3 hours a week into building small tech demos or games that will teach me something about game programming. I'll also write a weekly blog post that outlines what I did, what I learnt and what I plan to do next week. If I can stick to this I should learn a decent amount in a reasonable amount of time, but most importantly have a set of demos for a portfolio and a journal to go with it. And from there, we'll have to see.
Which brings me to the first little project. I've spent a bit of time reading and thinking about where to start, it does make sense to use Windows for the project initially though, even though I normally use a Mac and have an iPhone I could develop for, however, the games I would want to work on are PC or console games and most game jobs require C/C++ on Windows, so Windows just makes sense. I don't want to get overwhelmed and discouraged so starting reasonably small would be a good idea, which makes me think starting with XNA Game Studio is a good way to get my feet wet with XBox 360 and Windows development, rather than jumping into the deep-end with DirectX. Even if it is C# as opposed to C/C++, I'm not too worried about that just yet.
I'm going to start by developing a Breakout clone for Windows. This fits the reasonably small criteria but should cover a enough new areas that it should be interesting. I expect to learn about at the least following:
- Setup of development environment and building and running a Windows game.
- Simple 2D graphics.
- Simple UI components.
- Simple 2D vector math, trigonometry and animation of the ball and paddle.
- Timing of animation.
- Keyboard input.
- Collision detection.
- Simple audio playback.
- Simple particle effects.
I'll be storing all the code for the project in my github account. So if anyone wants to see how I'm progressing in terms of the code, check it out. (I'll post a link to the actual repository when I get it set up next week.
That's all for this week, next week I'll post about setting up the XNA Game Studio in Windows.
Subscribe to:
Posts (Atom)