I haven't done a whole lot with my game engine stuff over the past week (been focusing on implementing GPU splatting for my research), but I decided to capture a video today. It's a little low quality, but it shows off the basics. For the most part, there's enough functionality in there to start working on a game, but I want to make the code simpler and easier to work with. Anyways, here's the video:
Currently I'm using Bullet for Physics, CEGUI for the in-game GUI, DevIL for loading images, OpenGL for rendering and a whole lot of boost to make my life easier. The windowing (Cocoa, Carbon, X11 or Win32) is my own. Eventually I might do the same for the image loading and in-game GUI so that there are less dependencies, but for now I don't really care too much about that. I'm planning out a simple game to make eventually, so look forward to that in the future. Perhaps not the very near future, but quite possibly by the end of the year.
Showing posts with label Game Design. Show all posts
Showing posts with label Game Design. Show all posts
Modeling 101
Okay, this is far from me giving you a 101 class on modeling, because when it comes to drawing/modeling/things of that nature I suck pretty bad. Nevertheless, I amazed myself at how quickly I could whip up a "stick man" model with a basic skeleton using Blender.
He's in a sitting pose, waving I think. Yeah, I have skills *cough*. Anyways, other than a crash here and there, Blender is a pretty decent piece of software. Some of the keyboard shortcuts are non-intuitive but once you get them down you'll be unstoppable.
That screenshots also shows off my integration of CEGUI into my WIP. I struggled with two issues that I'll share with people. The first issue was that you need to have the OpenGL viewport set up correctly when initializing CEGUI. Unfortunately my initialization was occurring before I called glViewport, but that was easily resolved. The second thing was that having any VBOs/VAOs bound messes up CEGUI (for now). Be sure to release any bound buffers/arrays before rendering things.
CEGUI is a pretty hefty library, but it looks to be incredibly robust and still actively developed. I loved how I could manually inject input events into the CEGUI system, which meant easy integration into my own windowing system. I noticed that some other systems used existing input libraries or hooked into something like GLUT or SDL. I also love the ability to use describe things in XML. I think CEGUI and I will get along quite fine until I decide to write my own UI system.
There was a bit of messing around getting things to link properly, but I managed to get everything working in the end. I'll finish off by pointing out qmake. I use it for my Makefile generation and I absolutely love it, mainly because it's incredibly simple. CMake is another option if you happen to be looking for one.
He's in a sitting pose, waving I think. Yeah, I have skills *cough*. Anyways, other than a crash here and there, Blender is a pretty decent piece of software. Some of the keyboard shortcuts are non-intuitive but once you get them down you'll be unstoppable.
That screenshots also shows off my integration of CEGUI into my WIP. I struggled with two issues that I'll share with people. The first issue was that you need to have the OpenGL viewport set up correctly when initializing CEGUI. Unfortunately my initialization was occurring before I called glViewport, but that was easily resolved. The second thing was that having any VBOs/VAOs bound messes up CEGUI (for now). Be sure to release any bound buffers/arrays before rendering things.
CEGUI is a pretty hefty library, but it looks to be incredibly robust and still actively developed. I loved how I could manually inject input events into the CEGUI system, which meant easy integration into my own windowing system. I noticed that some other systems used existing input libraries or hooked into something like GLUT or SDL. I also love the ability to use describe things in XML. I think CEGUI and I will get along quite fine until I decide to write my own UI system.
There was a bit of messing around getting things to link properly, but I managed to get everything working in the end. I'll finish off by pointing out qmake. I use it for my Makefile generation and I absolutely love it, mainly because it's incredibly simple. CMake is another option if you happen to be looking for one.
Game Design
So, one thing that I've been working on over the past week is reviving my "game engine" that I started working on a couple of years ago. It's not far, but I'm currently happy with the way things are going:
Pretty simple, I know. Shows off some basic texturing and per-pixel lighting, but that's about all I got for now. Currently this is all done in OpenGL, but I've abstracted many of the concepts in such a way so that I could easily swap in a DirectX renderer. This is done at compile-time though, so that I avoid dealing with dynamic libraries.
It's pretty easy to get something up and running too. I just extend an application class, which takes care of some nitty gritty details for me (e.g., the game loop). With the help of some compile-time polymorphism, I just override three methods: initialize, update, and render. Also, input handling (keyboard + mouse) is currently implemented using mappings to boost::functions. These mappings are registered at runtime, generally in the initialize method one specifies.
There's plenty of work to be done, but I think it's a good start. Some things I need to work on:
Of course, there's a lot more than that -- Terrain LoD, Character Animations, GUI Rendering, Game Logic, Physics, etc -- but it's a start!
Pretty simple, I know. Shows off some basic texturing and per-pixel lighting, but that's about all I got for now. Currently this is all done in OpenGL, but I've abstracted many of the concepts in such a way so that I could easily swap in a DirectX renderer. This is done at compile-time though, so that I avoid dealing with dynamic libraries.
It's pretty easy to get something up and running too. I just extend an application class, which takes care of some nitty gritty details for me (e.g., the game loop). With the help of some compile-time polymorphism, I just override three methods: initialize, update, and render. Also, input handling (keyboard + mouse) is currently implemented using mappings to boost::functions. These mappings are registered at runtime, generally in the initialize method one specifies.
There's plenty of work to be done, but I think it's a good start. Some things I need to work on:
- Resource Management. Currently all resource management is done through boost:shared_ptr. In other words, there isn't really any "management" happening. I need some form of a manager that can load various assets, caching things as necessary to help with efficiency.
- Higher-level Primitives. Currently I send triangle primitives to the renderer, which is a little too low level for my liking. I'd like to pick a set of base primitives that are at a higher-level (e.g., triangular mesh, model, terrain)
- Deferred Rendering. I've always wanted to take a stab at implementing deferred rendering. I'd just love to play around with shaders in general and getting some fancy stuff on the go.
Of course, there's a lot more than that -- Terrain LoD, Character Animations, GUI Rendering, Game Logic, Physics, etc -- but it's a start!
Subscribe to:
Posts (Atom)