Just wanted to post a quick screen shot of my tile editor in action, with the grid for PacMan. Hopefully I'll have some video and screen shots of the game that I've made by following James Silva's book later on.
Tuesday 27 July 2010
Sunday 25 July 2010
2010 Roadmap
Ok, so I've decided that if I'm going to make some serious progress with this engine then I need some sort of roadmap with milestones to try and hit, otherwise it'll never happen.
I've decided to focus on the 2D aspects of the engine initially and then build up into 3d from there.
As I mentioned in the beginning, the development of the engine is going to be game driven. I'm working on the basic framework of the 2d rendering engine, which will basically be an abstraction of the layering, batching and culling of the various sprites that make up a scene. I also need to work out the interaction with shader based effects.
So, the roadmap. I'll start short term. This week I'm still on holiday, so I should be able to get the whole of PacMan completed this week. This will include a first draft of the 2d rendered, and possibly a base Ai class as part of the engine.
After that I'll be back at work, but I'll be able to move onto my last clone, Mario. That will involve an expansion of the Tile editor that I've made for PacMan to include parallax backgrounds/ foregrounds, and collision surfaces (ledges) to allow for more complex levels. I also want to refactor the editor into the engine code, and work on a way of allowing the designer to 'plug in' gameplay code and then run the game within the editor, to allow for quick testing of levels.
I'm currently envisaging Mario (and the supporting work on the editor) taking up the whole of August.
In the longer term, I want to have my team's first original game ready for playtest by Christmas.
We have 3 different concepts that we're toying with. I don't want to talk about them too much at the moment, but we have one arcade type game, one room based platformer/ puzzler, and one 2d scroller/ platformer shooter. The first requires basically zero graphics assets, but seems to be the least likely be successful, the middle concept requires the most in the way of artwork, and may be out of our reach at the moment, but equally is the most refined of the concepts. The third will probably have the broadest appeal, will need some, but not too much in the way of artwork, but is the least well fleshed out of the three.
I might say more once we've decided on which to go with, and once development is in process.
Anyway, that's a bit of a rough, rambling roadmap for the remainder of 2010. Hopefully by the end of the year the Alta engine will be in a state where it can comfortably provide the functionality for most 2D games we want to develop...
Thursday 22 July 2010
Tile map editor, and James Silva's book
Well, a lot has happened in the week or so since I last posted.
I now have a fully functional Tile editor based on Winforms. I was concerned after learning a bit more about the integration between XNA and Winforms that it wasn't going to be possible to create a comprehensive Editor for Alta using Winforms, as the only method I could see for running the game in the Editor was to hook an update method into the Application.Idle process, which seemed a bit of a hack to me.
A quick query on the XNA forums seemed to suggest that this was fine though, so I'm going to carry on heading in that direction.
James Silva's book (http://www.amazon.co.uk/Building-XNA-2-0-Games-Professionals/dp/1430209798/ref=sr_1_2?ie=UTF8&s=books&qid=1279808646&sr=8-2) arrived late last week, and I've been blasting through it ever since. I'm both impressed and dissappointed by this book.
On the one hand, the content covered include things that you just can't find anywhere else, like a strategy for level editing, basic 2D terrain-type collision detection, a character/ animation editor, and (the most impressive in my opinion) scripting. Also the game created looks the part, and unlike any other game that I've created by following a book, I would actually be proud to sell it (had I come up with it myself obviously!).
So why am I disappointed? Two reasons. First, simply put, the editing is attrocious. Whilst the source code that you can download from the book's website is all correct, the code in the book seems to be a hodge-podge of various itterations, with variable names changing within the same function, and a constant switching between C# properties and manual GetYourVariable and SetYourVariable methods. Its fairly clear that someone has started rewriting the code for the book (to make it more readable perhaps? see below) but hasn't finished the job. This makes it very difficult to follow, and I was constantly flicking between the book and the online source code to see if I could tell what a function was supposed to do, and then make sure that it did it.
Which brings me to my other disappointment with the book: the code itself. Now I'm not the sort of programmer who lifts code wholesale from books/ tutorials and sticks it in my own projects without understanding what it does, but I do like to be able to look at the code I'm working with, and see what each part of it does, so that I can refer back to it if I ever need to do anything similar. With the code in this book, that simply isn't possible. James admits himself that there are a lot of hacks in the code to get something working quickly, and that its not as neat as you would normally like. Unfortunatley this is a contender for the understatement of the year.
Because James uses spritesheets, his code is full of crazy little bits of code to determine the correct source rectangle to use for textures, which I can live with, if they're a little annoying, but the placement of everything in the tools is hard coded (presumably figured out by a lot of trial and error on Jame's part, and fairly complex functions are just copied in, with a single line in the text to explain what purpose they perform. I'm not looking for a line by line explanation, but if you are creating a (fairly good looking) full screen effect, I'd like to know exactly how it achieves it!
/rant
That's probably an unfair assessment of Jame's book, given that I've taken away a LOT of useful tips, tricks, and techniques from it. But that's what I was looking for from the book. If anyone was looking at it with only a limited understanding of XNA then it would only serve to confuse them.
It probably should have a place in the learning path of a budding XNA developer, but I would put it after having cloned a few classic games in full to learn the ins and outs of XNA. Just my 2p...
Anywy, next up for me is creating the Tile map for PacMan, and then trying out some rapid development of the gameplay. The trickiest bit will be the AI, which I've never really had to deal with previously (the AI in pong left much to be desired!).
Until next time...
I now have a fully functional Tile editor based on Winforms. I was concerned after learning a bit more about the integration between XNA and Winforms that it wasn't going to be possible to create a comprehensive Editor for Alta using Winforms, as the only method I could see for running the game in the Editor was to hook an update method into the Application.Idle process, which seemed a bit of a hack to me.
A quick query on the XNA forums seemed to suggest that this was fine though, so I'm going to carry on heading in that direction.
James Silva's book (http://www.amazon.co.uk/Building-XNA-2-0-Games-Professionals/dp/1430209798/ref=sr_1_2?ie=UTF8&s=books&qid=1279808646&sr=8-2) arrived late last week, and I've been blasting through it ever since. I'm both impressed and dissappointed by this book.
On the one hand, the content covered include things that you just can't find anywhere else, like a strategy for level editing, basic 2D terrain-type collision detection, a character/ animation editor, and (the most impressive in my opinion) scripting. Also the game created looks the part, and unlike any other game that I've created by following a book, I would actually be proud to sell it (had I come up with it myself obviously!).
So why am I disappointed? Two reasons. First, simply put, the editing is attrocious. Whilst the source code that you can download from the book's website is all correct, the code in the book seems to be a hodge-podge of various itterations, with variable names changing within the same function, and a constant switching between C# properties and manual GetYourVariable and SetYourVariable methods. Its fairly clear that someone has started rewriting the code for the book (to make it more readable perhaps? see below) but hasn't finished the job. This makes it very difficult to follow, and I was constantly flicking between the book and the online source code to see if I could tell what a function was supposed to do, and then make sure that it did it.
Which brings me to my other disappointment with the book: the code itself. Now I'm not the sort of programmer who lifts code wholesale from books/ tutorials and sticks it in my own projects without understanding what it does, but I do like to be able to look at the code I'm working with, and see what each part of it does, so that I can refer back to it if I ever need to do anything similar. With the code in this book, that simply isn't possible. James admits himself that there are a lot of hacks in the code to get something working quickly, and that its not as neat as you would normally like. Unfortunatley this is a contender for the understatement of the year.
Because James uses spritesheets, his code is full of crazy little bits of code to determine the correct source rectangle to use for textures, which I can live with, if they're a little annoying, but the placement of everything in the tools is hard coded (presumably figured out by a lot of trial and error on Jame's part, and fairly complex functions are just copied in, with a single line in the text to explain what purpose they perform. I'm not looking for a line by line explanation, but if you are creating a (fairly good looking) full screen effect, I'd like to know exactly how it achieves it!
/rant
That's probably an unfair assessment of Jame's book, given that I've taken away a LOT of useful tips, tricks, and techniques from it. But that's what I was looking for from the book. If anyone was looking at it with only a limited understanding of XNA then it would only serve to confuse them.
It probably should have a place in the learning path of a budding XNA developer, but I would put it after having cloned a few classic games in full to learn the ins and outs of XNA. Just my 2p...
Anywy, next up for me is creating the Tile map for PacMan, and then trying out some rapid development of the gameplay. The trickiest bit will be the AI, which I've never really had to deal with previously (the AI in pong left much to be desired!).
Until next time...
Tuesday 13 July 2010
Graphics!!!
Well, the book I ordered still hasn't arrived. I spoke to the ebay seller last week who said that it had been sent 2nd class, but it still should have arrived by now. Its disappointing as I'm approaching the half-way point in my time off and I really wanted to be ploughing through that book by now.
Still, I've kept going in my XNA endevours. Tetris is now complete, with working high scores, music, and game modes.
I'm starting on PacMan, and I've already abstracted out a simple tile engine from the tile manager code I created for Tetris. I'm now working on creating a basis for my 2D rendering engine.
There is however some other news. Over the weekend I received an email from the Sunburn people offering me a promotional price on the community license for the Sunburn rendering engine for only $150 dollars. For non-creators club members (like me) that license would normally cost a massive $399!
It was too good an opportunity to miss, and so I now own a copy of Sunburn:) I'm still intending on abstracting out my own custom renderer using the Sunburn engine behind the scenes, so that in the future I can write my own rendering engine if I so choose without breaking any of the games that have already been built with Alta.
Sunburn will greatly speed up the process of getting the engine into a finished product. Once that happens I'll be free to tinker with sections of the engine behind the scenes without changing any gameplay code.
As I've said before, ultimately I'd like to be able to replace the XNA underpinnings with C++ and directX, and possibly OpenGL, but that is a number of years in the future at this point. In the meantime, I'm hoping to be able to update you on PacMan later this week.
In what I hope isn't the beginning of feature creep, I've decided to create a level editor with PacMan to alter the 'Maze' that the game is played in. Whereas I made a basic level editor with breakout, I'm planning on creating this editor as a stand alone winforms project, which I'll then build on when it comes to Mario.
I'm really hoping at this point I'll be able to get started on an original game before the end of my holiday, as that should give me the momentum to keep going once I'm back at work...
Still, I've kept going in my XNA endevours. Tetris is now complete, with working high scores, music, and game modes.
I'm starting on PacMan, and I've already abstracted out a simple tile engine from the tile manager code I created for Tetris. I'm now working on creating a basis for my 2D rendering engine.
There is however some other news. Over the weekend I received an email from the Sunburn people offering me a promotional price on the community license for the Sunburn rendering engine for only $150 dollars. For non-creators club members (like me) that license would normally cost a massive $399!
It was too good an opportunity to miss, and so I now own a copy of Sunburn:) I'm still intending on abstracting out my own custom renderer using the Sunburn engine behind the scenes, so that in the future I can write my own rendering engine if I so choose without breaking any of the games that have already been built with Alta.
Sunburn will greatly speed up the process of getting the engine into a finished product. Once that happens I'll be free to tinker with sections of the engine behind the scenes without changing any gameplay code.
As I've said before, ultimately I'd like to be able to replace the XNA underpinnings with C++ and directX, and possibly OpenGL, but that is a number of years in the future at this point. In the meantime, I'm hoping to be able to update you on PacMan later this week.
In what I hope isn't the beginning of feature creep, I've decided to create a level editor with PacMan to alter the 'Maze' that the game is played in. Whereas I made a basic level editor with breakout, I'm planning on creating this editor as a stand alone winforms project, which I'll then build on when it comes to Mario.
I'm really hoping at this point I'll be able to get started on an original game before the end of my holiday, as that should give me the momentum to keep going once I'm back at work...
Thursday 8 July 2010
Finishing touches
I've come to the point in Tetris where I normally move on to the next project: the finishing touches.
I've got the gameplay mechanics sorted, the visuals look passable (I'm not really putting much effort into visuals at the moment as these are just learning games, but I've tried to make sure they don't look too amateur). What's missing are little things like a high scores page, a different game mode that lets you see how many points you can score in a given time period, things like that.
I'm not the kind of person who is driven by finishing every minute detail. Its one of the reasons my code is never very good as far as error handling is concerned. But if I ever want a comercially released game I'm going to have to get better at it, and so I'm persevering with Tetris. By the end of the day I'll have a High scores table, a couple of game modes, and decent 'you won'/ 'you lost' screens.
And then I'll call it a day and move on to the next learning game: PacMan! I'm going to spend some time abstracting out the reusable code from the Tetris tile engine, as both PacMan, and the next game, a Mario clone, will use it in one form or another.
I'm still waiting for James Silva's book to arrive, but when it does I'll be working through that as well, and probably refactoring some of my engine code as a result. I also want to get started on my 2D rendering engine. At the moment all of my different game components use a seperate SpriteBatch to draw to the screen. Its not a big deal now, but if I start having a lot of sprites on the screen (including say some particle effects) the draw calls might start hurting performance.
Anyway, that's it for this update, more soon I hope.
I've got the gameplay mechanics sorted, the visuals look passable (I'm not really putting much effort into visuals at the moment as these are just learning games, but I've tried to make sure they don't look too amateur). What's missing are little things like a high scores page, a different game mode that lets you see how many points you can score in a given time period, things like that.
I'm not the kind of person who is driven by finishing every minute detail. Its one of the reasons my code is never very good as far as error handling is concerned. But if I ever want a comercially released game I'm going to have to get better at it, and so I'm persevering with Tetris. By the end of the day I'll have a High scores table, a couple of game modes, and decent 'you won'/ 'you lost' screens.
And then I'll call it a day and move on to the next learning game: PacMan! I'm going to spend some time abstracting out the reusable code from the Tetris tile engine, as both PacMan, and the next game, a Mario clone, will use it in one form or another.
I'm still waiting for James Silva's book to arrive, but when it does I'll be working through that as well, and probably refactoring some of my engine code as a result. I also want to get started on my 2D rendering engine. At the moment all of my different game components use a seperate SpriteBatch to draw to the screen. Its not a big deal now, but if I start having a lot of sprites on the screen (including say some particle effects) the draw calls might start hurting performance.
Anyway, that's it for this update, more soon I hope.
Thursday 1 July 2010
A new (old) book
Two entries in one day, whoa! :-)
Over lunch at work I spotted a book on ebay that I've been meaning to buy for a while and at less than £4.50 with free postage it was a steal. The book is 'Building Xna 2.0 games' by James Silva. I've heard great things about this book, and I'm looking forwards to working through it.
I have a lot of XNA books, some of which are good, some of which are terrible, but mostly what I need to learn isn't how to use Xna, its how to structure and build good games.
James has built some v. successful games so an insight into his way of working should be invaluable.
I also heard about a new iphone games book, which got me itching for the 'buy' button on Amazon but I held off for now. With Xna, UDK, and Unity on the go, starting an MSc in computer science in October and a full time job, iphone games may have to hold on for now.
(Incidentally at some point I'll be starting blogs on UDK and Unity so as to not clutter this one with thoughts not related to the Alta engine. I'll link to them when I get them going).
Code, delete, re-code
One issue with the idea of game driven development is the fact that I find myself spending hours over an issue that has a quick fix FOR THIS GAME but not for other games, and hence is useless for the engine.
I came across an example last night whilst debugging my latest build of Tetris. At the core of my engine is a game state manager. This works by having a stack of 'in use' states, and controlling whether or not those states in use are visible and enabled.
Those states that aren't on the stack are removed from the game's component list and are added to it when they join the stack.
This all worked fine until I created game components that were owned by my game states. If the owner state was removed from the stack, the owned components remained active. Problem.
Now, its a simple enough matter to fix. I don't really need all the objects that are currently 'owned' game components to actually inherit from the GameComponent class, I can just call their update and draw methods from within the owner's update and draw methods.
However that's not a very satisfactory solution, especially in a more complex game where the playing state might have many sub-components.
I have two options that I can see. The first is to add a components list to the base game state and add the components to that, which then adds them to the Game class's component list when the owner state is pushed onto the stack, and removes them again when they're popped or removed from the stack.
The other is to re-evaluate my whole approach to game management, as the game state system isn't as flexible as others I've seen, such as unity's Scene - game object - component hierarchy, or UDK's system where everything is a 'level'.
The second would be more work to implement but might save me from complex work arounds in the future, but the first is simpler to implement now and may turn out just fine...
Subscribe to:
Posts (Atom)