Howdy folks, and welcome to another installment of theraje's Game Development.
I found out yesterday that the Khronos Group consortium - the people behind OpenGL - have released the OpenGL 3.1 specification. Of course, this release brings about some major changes to streamline the API, but it also means a lot of old throwbacks have been deprecated.
Naturally, a lot of those "old throwbacks" are things that I've incorporated into Dungeon 3D. Nowadays, you're expected to use shaders - small "programs" that alter the way your graphics card processes things like vertex and fragment data - rather than using the less flexible, but more straightforward, fixed-function pipeline. Before learning about the deprecations in the latest OpenGL spec, I never found any reason to use shaders. Now it seems that if I want my game to be compatible with graphics cards that will be available in the near future, I will have to use them.
So, I had a look in one of my books to find out what shaders are and how to use them. It seemed to only multiply the questions I had. Then I had a look at an online tutorial. That didn't help things much, either. It looks like learning how these shader things work will take a big chunk of my time. Then there is the matter of plugging everything into my project.
A battle is now raging in my mind - do I spend an indefinite amount of time trying to learn about and implement shaders into my game, or do I just finish the game as it is and hope that backwards compatibility saves me?
Of course, simply debating the topic is robbing me of precious productivity. It seems like a lose-lose in my case.
Thursday, March 26, 2009
Friday, March 20, 2009
Not Your Mama's Blender
When the average person hears the word "blender," they think of those kitchen devices that can either make great smoothies or turn your hand into a thick red paste. But chances are that if you're a techie like me, the free 3D modeling software Blender is the first thing that comes to mind.
When I first used Blender many years ago, I was still a young adult... I'd say 19 or 20. I was excited that DirectX was coming to Visual Basic 6.0, so I started looking into making my own 3D models so I could start making 3D games. As I looked at the prices for some of the high-end 3D modelers, I was taken aback. Some were $3,000 US. I even found one that cost around $10,000 US. A very ghastly situation when you don't come from money and have a bottom-tier job.
Among the more reasonably priced options I found was Blender - a totally free and open-source software suite for 3D modelers. Of course, when I first tried Blender, I was confounded by the interface. I couldn't figure out how to even close the program... I actually had to go into Task Manager and kill the process.
Over the years, I kept coming back to Blender on occasion, without much better results. I would learn how to do one or two things each time, but found it far too cumbersome to work with. I could use it in a pinch, but it wasn't fun.
I wanted to learn how to actually use Blender effectively, so I bought a book that promised to help you "unlock your artistic potential and get the most out of Blender." While these claims are lofty indeed, the book itself has taught me a lot about the nuances of Blender, and has enabled me to use it much more efficiently than any of the online tutorials I've perused.
One of the most important concepts behind using Blender detailed in the book is "ohomohok" - One Hand On Mouse, One Hand On Keyboard. This is pretty much the golden rule of using Blender, as many tools and menus are quickly accessible from keyboard shortcuts. It also allows more control over translating, rotating, and scaling models. For instance, rotating a model 45 degrees on the Z axis can be as simple as pressing 'r', 'z', then typing '45' and tapping the Enter key.
I also learned that the MMB - or "Middle Mouse Button" - is a handy tool. Most people roll the scroll wheel, but never seem to remember that pressing down on it serves as a MMB. It can be used to navigate freely within the 3D view, and to split the views (which is handy when you want to view the model in one window and edit a UV map in the other).
Also, the book taught me what I needed to know for making game-appropriate models. From Mirror Modifiers, to face extrusion; from marking mesh seams, to unwrapping UV maps.
The only problem I had with the book is that the images are printed in black-and-white, and are in some cases a bit tiny. I can see them fine in decent lighting and with the book up close, but it can definitely be a problem for people who don't have the best eyesight (or, in my case, glasses).
If you're one of those people who need an affordable 3D modeler, I would now recommend Blender - something I wouldn't have done in years past. However, I would also highly recommend that you spend a little money on a decent book like I have. It really will be a big help in learning Blender's unique interface.
When I first used Blender many years ago, I was still a young adult... I'd say 19 or 20. I was excited that DirectX was coming to Visual Basic 6.0, so I started looking into making my own 3D models so I could start making 3D games. As I looked at the prices for some of the high-end 3D modelers, I was taken aback. Some were $3,000 US. I even found one that cost around $10,000 US. A very ghastly situation when you don't come from money and have a bottom-tier job.
Among the more reasonably priced options I found was Blender - a totally free and open-source software suite for 3D modelers. Of course, when I first tried Blender, I was confounded by the interface. I couldn't figure out how to even close the program... I actually had to go into Task Manager and kill the process.
Over the years, I kept coming back to Blender on occasion, without much better results. I would learn how to do one or two things each time, but found it far too cumbersome to work with. I could use it in a pinch, but it wasn't fun.
I wanted to learn how to actually use Blender effectively, so I bought a book that promised to help you "unlock your artistic potential and get the most out of Blender." While these claims are lofty indeed, the book itself has taught me a lot about the nuances of Blender, and has enabled me to use it much more efficiently than any of the online tutorials I've perused.
One of the most important concepts behind using Blender detailed in the book is "ohomohok" - One Hand On Mouse, One Hand On Keyboard. This is pretty much the golden rule of using Blender, as many tools and menus are quickly accessible from keyboard shortcuts. It also allows more control over translating, rotating, and scaling models. For instance, rotating a model 45 degrees on the Z axis can be as simple as pressing 'r', 'z', then typing '45' and tapping the Enter key.
I also learned that the MMB - or "Middle Mouse Button" - is a handy tool. Most people roll the scroll wheel, but never seem to remember that pressing down on it serves as a MMB. It can be used to navigate freely within the 3D view, and to split the views (which is handy when you want to view the model in one window and edit a UV map in the other).
Also, the book taught me what I needed to know for making game-appropriate models. From Mirror Modifiers, to face extrusion; from marking mesh seams, to unwrapping UV maps.
The only problem I had with the book is that the images are printed in black-and-white, and are in some cases a bit tiny. I can see them fine in decent lighting and with the book up close, but it can definitely be a problem for people who don't have the best eyesight (or, in my case, glasses).
If you're one of those people who need an affordable 3D modeler, I would now recommend Blender - something I wouldn't have done in years past. However, I would also highly recommend that you spend a little money on a decent book like I have. It really will be a big help in learning Blender's unique interface.
Thursday, March 19, 2009
Dungeon 3D So Far
Since "Dungeon 3D" has been in development for a few weeks, and I'm just getting this blog rolling, I thought it would be nice to give all of you a bit of background in the development process for the game.
"Dungeon 3D" started as an idea that I've always wanted to work on - a game that builds its levels procedurally (i.e. the program builds levels by itself, rather than loading levels built strictly by hand). I wanted to base my game loosely on a Rogue-like game (specifically, Nethack), but without the "drunken walk" generated hallways, so things would be a little cleaner.
After getting a good idea of what I wanted out of the game down on paper, I began work. Choosing to use a combination of C++ as the language and SDL and OpenGL as utility libraries, I sat down and started on the simple things - like getting stuff to draw.
Upon getting something to render, I added a homebrew lighting scheme that lights individual tiles, rather than lighting everything per-vertex or whatever. This is so the lighting between tiles is easily identified, as it will affect characters' ability to hit each other based on visibility.
Next thing I did was start on level generation, since I could now see what I was doing. After making sure I could see, I changed the view so that the level could be seen adequately.
Unfortunately, the rooms were a little too random. Many rooms were disconnected from each other, so I tweaked the level generator to fix that. However, the level was still largely too random.
I then decided to make dual views for the game, in the form of a minimap in the corner, and the player view in the rest of the screen, to get a "feel" for the maps. I went ahead and added text messages to a sort of heads-up display next to the mini-map.
To help alleviate the unwieldy randomness of levels, I decided to change how levels were generated. Instead of randomly choosing where to plant a room, then randomly setting the width and height, I created some small, hand-made "room definitions" and plugged it all in. Still not there, but getting closer.
After making some new, "optimized" room definitions, I added a frame rate counter to the bottom of the screen. Then I thought the player view looked a bit too bare. I wondered if adding a "ceiling" cap to the walls would help. After showing the before and after to a couple people, we all agreed that the game looked better with capped walls.
I decided it was time to work on something else. I opted to go after model loading and rendering. After all, what is a 3D game without a few 3D models? This wasn't a problem, since I already had an old OBJ loader lying around in an old project. After a few tweaks, I had models up and running.
With that small victory under my belt, the level layouts were still bugging me, so I made some final tweaks to the levels, until I was satisfied with the results.
Of course, the levels themselves are generated fine now, but they still looked a bit boring. I decided to add some trimmings to the levels. I started with pillars inset into inner wall corners, but that killed my frame rate. I was then shown the light.
I had been rendering everything in "immediate mode" - using glBegin() and glEnd() blocks to render it all. A friend of mine told me about vertex arrays and vertex buffer objects. After learning about and implementing those features, I was pleased with the outcome.
So, that's pretty much where I am at the moment. I'm currently working mostly on 3D models, and some minor tweaks. There is still much left to do in the grand scheme of things, though. It's interesting to see how far this project has come over the past three weeks or so when I first got the idea.
"Dungeon 3D" started as an idea that I've always wanted to work on - a game that builds its levels procedurally (i.e. the program builds levels by itself, rather than loading levels built strictly by hand). I wanted to base my game loosely on a Rogue-like game (specifically, Nethack), but without the "drunken walk" generated hallways, so things would be a little cleaner.
After getting a good idea of what I wanted out of the game down on paper, I began work. Choosing to use a combination of C++ as the language and SDL and OpenGL as utility libraries, I sat down and started on the simple things - like getting stuff to draw.
Upon getting something to render, I added a homebrew lighting scheme that lights individual tiles, rather than lighting everything per-vertex or whatever. This is so the lighting between tiles is easily identified, as it will affect characters' ability to hit each other based on visibility.
Next thing I did was start on level generation, since I could now see what I was doing. After making sure I could see, I changed the view so that the level could be seen adequately.
Unfortunately, the rooms were a little too random. Many rooms were disconnected from each other, so I tweaked the level generator to fix that. However, the level was still largely too random.
I then decided to make dual views for the game, in the form of a minimap in the corner, and the player view in the rest of the screen, to get a "feel" for the maps. I went ahead and added text messages to a sort of heads-up display next to the mini-map.
To help alleviate the unwieldy randomness of levels, I decided to change how levels were generated. Instead of randomly choosing where to plant a room, then randomly setting the width and height, I created some small, hand-made "room definitions" and plugged it all in. Still not there, but getting closer.
After making some new, "optimized" room definitions, I added a frame rate counter to the bottom of the screen. Then I thought the player view looked a bit too bare. I wondered if adding a "ceiling" cap to the walls would help. After showing the before and after to a couple people, we all agreed that the game looked better with capped walls.
I decided it was time to work on something else. I opted to go after model loading and rendering. After all, what is a 3D game without a few 3D models? This wasn't a problem, since I already had an old OBJ loader lying around in an old project. After a few tweaks, I had models up and running.
With that small victory under my belt, the level layouts were still bugging me, so I made some final tweaks to the levels, until I was satisfied with the results.
Of course, the levels themselves are generated fine now, but they still looked a bit boring. I decided to add some trimmings to the levels. I started with pillars inset into inner wall corners, but that killed my frame rate. I was then shown the light.
I had been rendering everything in "immediate mode" - using glBegin() and glEnd() blocks to render it all. A friend of mine told me about vertex arrays and vertex buffer objects. After learning about and implementing those features, I was pleased with the outcome.
So, that's pretty much where I am at the moment. I'm currently working mostly on 3D models, and some minor tweaks. There is still much left to do in the grand scheme of things, though. It's interesting to see how far this project has come over the past three weeks or so when I first got the idea.
The First Post
Howdy folks, theraje here. I'm a lone-wolf game developer, meaning that I develop my own video games - from design, to programming, to media - all by myself. I've been developing games since 1999.
I've been floating around various places which you may be familiar with if you're into game development. I'm a regular at the Game Programming Wiki forums, and have been a part of several other game programming communities. I was once the head of a large community video game project, known as "The Gathering Project," for over a year back in 2001-2002.
Right now, I'm working on a one-man project. The project is currently entitled "Dungeon 3D." Yes, what an exciting name. Don't worry, I plan to change it once I have time to think of a real name. It is a 3D Rogue-like game. Levels are generated on-the-fly and the graphics are 3D. A more-friendly-than-the-typical-Rogue-like user interface is planned, as is an actual story line (with dialogue and cut-scenes). Think of it as Nethack for the Final Fantasy generation.
I will be documenting the development of "Dungeon 3D" of course, as well as giving insights into what it really takes to be a lone-wolf game developer. I plan to update this blog about once a week, if not more often. I will share my experiences with you in the hopes that other developers will learn from my (many, many) mistakes.
So kick back, relax, and enjoy the show.
I've been floating around various places which you may be familiar with if you're into game development. I'm a regular at the Game Programming Wiki forums, and have been a part of several other game programming communities. I was once the head of a large community video game project, known as "The Gathering Project," for over a year back in 2001-2002.
Right now, I'm working on a one-man project. The project is currently entitled "Dungeon 3D." Yes, what an exciting name. Don't worry, I plan to change it once I have time to think of a real name. It is a 3D Rogue-like game. Levels are generated on-the-fly and the graphics are 3D. A more-friendly-than-the-typical-Rogue-like user interface is planned, as is an actual story line (with dialogue and cut-scenes). Think of it as Nethack for the Final Fantasy generation.
I will be documenting the development of "Dungeon 3D" of course, as well as giving insights into what it really takes to be a lone-wolf game developer. I plan to update this blog about once a week, if not more often. I will share my experiences with you in the hopes that other developers will learn from my (many, many) mistakes.
So kick back, relax, and enjoy the show.
Subscribe to:
Posts (Atom)
