About this blog
Making games and learning FTW!
Entries in this blog
I'm at an semi-interesting point in my project right now where I have working tech to build a game and I have a basic game idea. That means trying to do some prototyping to see if there's any actual fun hidden in my ideas. Ideas are cheap and easy to put down on paper but actually implementing something and trying to make it fun is the hard part. I don't claim to be an expert at this so I don't necessarily plan to succeed but learning is the goal. Before you can make good games you need to make shitty ones.
So the basic idea is that I want to make a two stick shooter that uses elements from some classic arcade games. The first classic that I want to steal from is Dig Dug. There are a million two stick shooters out there where you shoot a bunch of things coming at you so I wanted to get rid of the shooting part and put something like the DigDug pump where you have to inflate and pop the bad guys. That's the entire starting point. We'll see where it goes.
Try 1: Get a good guy moving and inflating a bad guy.
Try 2: Tweak player movement to have a basic acceleration curve starting and stopping so movement isn't so jerky. Also allow for fast and slow movement based on how hard you push the gamepad stick. Get bad guys parameterized so they can be popped quicker/slower, bigger/smaller. Actually implement popping.
Try 3: Make the bad guys have a basic chase AI.
So things are starting to look almost game like but it's far from fun. It's way too easy to run around and get bad guys bunched together to kill them all at once. In classic arcade parlance this is called grouping which is actually a good thing generally since it allows some emergent strategies of how to get bad guys to move together. The current problem is that it's just too easy to do it. I plan to see if having some different AI routines running on different bad guys mixes things up as a next step.
One important thing to note is that I'm completely ignoring aesthetics. All place holder graphics, no fancy particle effects on popping on animations. That's all useless if you can't find fun first. The videos themselves are pretty crappy since it seems screen capturing on Linux is a black art. Fraps for Linux where are you!!??
BTW: As a complete aside from this project at my real job we are currently looking to hire people. If you're looking for an awesome gig working at an awesome company then this job is for you if you've got the skills. We have a job posting here at gamedev.net (http://www.gamedev.n...e-manager-r2423) If you think you have the skills and experience feel free to drop me a PM with any questions about the job.
I had been planning on increasing the time between journal posts so I'd have more to talk about that might be interesting to folks but I didn't realize that I had taken that plan so much to heart. I honestly didn't plan on staying away for months but it looks like that ended up happening anyway.
The good news is that I haven't been away from coding during that time so I've managed to make some decent progress on things. The major additions were:
1. Implemented a mostly baked animation system. It does all the basic things like tweening, conditional control/looping, triggering script events, etc. It's also designed in a way that I can easily create different types of animations. I've got a quick sample video here:
That shows off vertex colour animations, texture blending animations, translation/rotation/scaling animations and texture flipping. An object can have any number of animations acting on it at the same time. I still need to add basic mesh animations but since I'm not sure exactly what I'm going to need to do in the game I'm deferring that until later.
2. Implemented an audio system. When I say implemented I really mean wrote some basic wrappers and plugged audio files into my resource manager. The stuff built into SFML is amazing at audio. Even a brain dead coder monkey like myself can get things like streaming audio working in under 10 minutes, all on it's own thread so nothing is blocking. Absolutely a dream to work with.
3. Rejiggered my engine structure to allow easy multi-threading of different systems. Since the goal of my last major project a few years ago was learning how to create a multi-threaded engine this was surprisingly easy this time around. I know a lot of people still work in a single threaded world and say multi-threading is unnecessary but I still think you're silly to limit yourself to one thread. Every single PC/Mac built in the past 5 years is multi-core. Not taking advantage of that is like locking your renderer at 30 fps because "it's good enough" even though it can run at 60. I've currently got graphics/audio/resource management running on one thread and physics/input/scripting on another. I've created the concept of a "System" which can contain one or many managers that run on a thread doing work. Each system can receive messages from any game component/manager/system which it then acts on. This allows things on different threads to easily talk to one another without causing any kind of blocking situations.
4. Refactoring, refactoring and more refactoring. I'm a believer in iterative development which means that I write code to get it into a working state and then revisit the code to make it more modular, smaller, cleaner and faster. I never consider any code completely finished. This may, but doesn't have to include, optimization work. I haven't attempted to really optimize any of my code yet because I don't know what needs to be optimized. I'm a firm believer in not doing any premature optimization unless I have hard proof that something is holding me back. The amount of time most people waste in optimizing code that gains them nothing is usually equal to or greater than the amount of time they deliver a project late. If it ain't broke don't fix it.
Outside of the engine work I've also been working on game ideas with a friend who is going to be doing the art for the game. This in itself has been fun as we've done a bunch of brainstorming on game ideas and really come up with some stuff that I'd like to do. The only downside to working with someone is that you're dependent on their schedule and pace. My friend has recently gone through some major relationship changes so she's been busy and hasn't had a tonne of time to work on things. Up to this point it hasn't been a big deal since I've had a bunch of engine work to do but I'm starting to get the itch to start prototyping ideas to see what will work. It can be kinda hard to do that without art. Our current game idea involves taking some fun mechanics out of some classic arcade games and using them in some more modern game styles. I'm a huge classic arcade game nerd so this is in my wheel house and it's got my excited. I think too many game developers have forgotten what started people into gaming and why it reached such heights in the 80s. There are some great mechanics that haven't been revisited in decades that people will hopefully enjoy.
[font=arial, verdana, tahoma, sans-serif][size=2]For 98% of us working on side projects the biggest obstacle to reaching the finish line isn't a lack of technical expertise or a dearth of design ideas. The #1 cause of project death is motivation, or more accurately a lack of motivation. We all have real life getting in the way of things on a daily basis and it can be hard to really buckle down and write some code or make a model. I like to think that I'm pretty good at keeping motivation high with some techniques that I've learned over the years along with finding a right level of being hard on myself without being too harsh but that doesn't mean I always succeed. In the past couple of weeks the amount of progress I've been making has been under par. I could blame it on work being busy or not getting enough sleep but an honest assessment showed that the reason was the top item on my todo list.
Having fun is more important than being good[/font]
Due to some problems I ran into while getting spot lights to work in my shaders I came to the conclusion that I would like to have the ability to switch back and forth from the fixed function and the programmable pipelines. I also figured it would be a good feature to be able to target older systems that didn't support GLSL. With this in mind I added the item to the top of my todo list and felt good about doing the "right" thing next. It was at this point that forward progress slowed to a crawl on my project.
The biggest problem with this work item is that I don't really gain anything out of it in the short term. I've already got things rendering fine with my current system so adding fixed pipeline wasn't going to visibly change anything. As for targeting older machines I am barely ready to start prototyping so I'm only going to be running things on my laptop which supports my current pipeline just fine. Despite these issues staring me in the face I still was trying to plod on with this work item but I found myself reading forums and watching hockey more than coding.
Finally after a week of making very little progress and feeling bad about it I decided to figure out if I really needed to be doing this work. A quick look at the Steam hardware survey and a similar one from Unity showed that the number of users with cards that only supported fixed function was noticeable but not necessarily an issue if I couldn't target them. When you add in the fact that I don't have a known end target in mind for my current project one can assume that the number will go down by then. I also thought of some of the things I have in mind to implement and I wasn't entirely sure how I was going to do them in fixed function. The long and short of it was that I finally just decided to say F' it for now. I can always go back and do this work later if I decide that I really need to but there's no reason it has to be high on my priority list right now. With that decision out of the way I felt refreshed and excited to code again. I finished up integrating OIS for joystick support earlier this week and am finally getting ready to start prototyping.
Sometimes deciding to not do something is the best way to make forward progress.
Wrapping up Collisions
I finished up passing collision events to individual objects at the end of last week and that went absolutely swimmingly. At the end of every physics frame I process all of the collisions and send the appropriate information to the objects involved. If the object wants to act on collisions it provides a Lua script which is called getting passed the object type that it collided with so it can perform an appropriate action. This is similar to some of the other things I use Lua for on objects so it was under an hour of work. With this piece in place I'm finally at a point where I have the bare minimum of systems up and running to throw together more than just a few ducks bouncing around on the screen.
Brainstorming for Prototyping
With prototyping in mind I got together with an art/design friend of mine who'll be working on this game with me for a brainstorming session. The session went well and we came up with a good starting point for a game we want to make. I'll outline what the game idea is in a future post along with how we approached figuring out what to make but what is important for this post is that some functionality requirements for my code fell out of the brainstorming session. Specifically lighting requirements.
I Hate Lights and Shaders
Really the previous line says it all. It ends up that I needed to add spot lights to the engine but as I've said before I am not a graphics dev. It seemed like a fairly straightforward task seeing that I already had point lights working but nothing is easy for me when it comes to lights it seems. It was easy enough getting the appropriate data into my shader about the lights but no matter what I did the lights just wouldn't light anything. Luckily from my last set of lighting problems I thought it might be another transform problem with the normals or the lights so I moved the camera and the spot light to the origin and my trusty duck model just in front of things and sure enough my light worked. It ends up that the lights in OpenGL are supposed to be in eye space and not in world space. Once I found that out it was easy getting things going and I at least have passable spot lights.
Fixed Function Fall back
What I've learned from the last two painful lighting problems is that I'm horrible at debugging this type of problem. I really got lucky by my move back to the origin because really graphics feel like a black box to me compared to any other system. As such I've decided that to help out my debugging that I'm going to add the ability to fall back to the fixed function pipeline so that I can hopefully see what the scene is supposed to look like and compare it against my own shaders. In the long run it may be an important feature for dealing with older graphic cards as well that don't support everything I need in the programmable pipe.
I didn't think that there would ever be a worse PR vehicle for the games industry than the reality show "The Tester" on PSN. Really how do you top a bunch of people competing for a job with horrible pay, horrible hours where you get treated poorly? It seems though that IGN is up for the challenge of going one step further:
So now being an indie developer is all about coming up with sexist game designs and wearing hipster clothes? When IGN first announced that they were going to help some indies out by giving them office space, etc. I thought it was a cool idea. Kind of like a new mini indie-fund. This obviously is far different from that original image. The really sad thing is that if any of the people on the show are serious about getting into the mainstream industry they are just setting themselves up to get black listed. Reality shows have a way of editing things so everyone looks like a douche or a dumbass. No one wants to hire a douche or a dumbass.
Maybe I'm wrong and this preview is just showing all of the bad side of the show. I hope I'm wrong.
It's been way too long since my last entry but it's not for lack of trying. Real life has been busy with a crazy couple of weeks at work along with a week long vacation in the sun so it's hasn't all been a bad kind of busy . I've managed to fit in some project work during all of that but I just haven't had time to write up an entry on things until now.
When I last wrote I was looking for a physics library to integrate. Everyone was nice enough to unanimously suggest Bullet which made my decision easy and it ends up that it also made integration easy too. The library does everything I need it to do and does it in a very clean fashion. Understanding how all the pieces work together was a breeze which made it easy to fit into my framework. One final work item that I still need to implement is passing along collision events to individual objects in my scene. Currently objects collide correctly based on collision masks but the objects don't currently perform any custom events on those collisions. I haven't done any heavy testing to see how performance holds up with a bunch of things going on in the world but unless there's a complete melt down I would definitely recommend this library to anyone else looking for a physics solution.
Of course everything can't go completely smooth all the time and the physics integration did identify a few bugs in my shaders with lighting not behaving correctly with objects in motion. I would never call myself a graphics dev, and neither would anyone else, so tracking down the bugs was a bit of work. I haven't really done much thinking of dot products, etc. since I was in school and I always let the fixed function pipeline worry about that stuff in the past so my debugging of things took longer than it probably should have. In the end though I did finally get things working enough that I'm ready to move on.
I've got a quick little video showing off the rubber ducky model getting some forces applied to it and bouncing off the walls. The physics world is using a sphere as a rigid body for the duck if you're wondering why the collisions don't look 100% accurate for an odd shaped object like the duck but I can easily get it to use the mesh instead. In this case I just want to test the basics of the physics integration.
There's already been a lot of buzz from the Nintendo keynote at GDC and I'm sure there's going to be more in the next few weeks following GDC. It's not often a keynote address from one of the big 3 gives people something to talk about but this year was an exception. There were a few points in the keynote that I wanted to comment on.
High value and high quality games
Iwata-san mentioned a concern about the growth in low value and low quailty games. The dig was pointed at "downloadable games" and he pointed out that while Nintendo, Sony and Microsoft all care about the quality of their games others do not. The shot could have been pointed at the flood of games on mobile devices, the growth in social gaming or everything in between. While I'm not a huge fan of the clone wars in the iPhone/Android world and the crack farming games in the social networking world I believe that all game developers have the right to make money whatever way they can and make whatever games people will play. The reality is that quality has nothing to do with the platform or the size of the team making a game. Not everyone is lucky enough to have funding in place to make the next big AAA blockbuster and new platforms give the smaller guys a chance to make a living in the industry. The irony of Iwata-san's comments is that the big 3 platforms have plenty of crappy games on them too. It's nice that Mario Galaxy could get a meta-critic score of 97 with a multi-million dollar budget but let's not forget the Wii title Balls of Fury which got a Metacritic score of 19. Where was the Nintendo quality filter then? There is a difference between forcing people to pony up big $ for a devkit license and ensuring that games on your platform are quality and will sell. This same fear mongering abounded in the early days of mobile and casual gaming. The industry didn't die. The cream rose to the top and the crap sank and died. Consumers could still find, enjoy and buy Plants versus zombies amidst the field of other casual Bejeweled clones. The net of the story is give consumers the benefit of the doubt. They will find the hidden gems. Minecraft and Angry Birds are a perfect example of that.
Developers becoming too specialized
A fear of having too many specialists and not enough generalists on a game team is something I completely agree with. It's natural given the evolution of the games industry that we are seeing more and more specialized talents. And while it may seem more efficient to have a team made up of specialists with super defined rolls I believe that it actually leads to lower quality games in both the technical and artistic sense. When everyone is focused on their little part of the game they lose the big picture and games change from being about the fun and being about the delivery. Here on GD I see a stream of posts in the Help Wanted forums about looking for a person for a role on a team or a dev looking for a team. While teams can help out with motivation and can help you expand your knowledge there is a lot to be said about tackling a project all by yourself. Yes it means that your project goals will probably be smaller than a big team but you'll get to have a taste of everything and smaller project goals might mean actually achieving them as well. The most interesting thing about Iwata-san bringing this topic up is that this is less of a problem in the mobile/social/downloadable space where there are smaller teams.
The solution is Innovation stupid!!
The big close to the speech was the call for more innovation. The solution to all of the problems of the gaming industry is more innovation! While innovation is a nice word to throw around I think people use it as a crutch. When we're in an economic lull or having troubles in the face of new competition it's because we don't have enough innovation. When you have a game that sells 5 million copies it's because it's innovative. I believe that compared to other fields of entertainment games have had a constant level of innovation higher than anything else. There are big technical innovations like the Wii or Kinect. There are constant small innovations like having a platformer that models meat sliding down a wall. Sure we have plenty of derivative crap out there but so does music or film. For every new Call of Duty game released there's five new albums by boy bands and 3 new action movies starring Vin Diesel. Quit complaining about innovation and start playing more games. There is a tonne of innovation if you just look for it.
The real solution is already here
If you really want to find quality games that are innovative and are built by people who understand all aspects of game development then look no further than the indie developer scene. If the big 3 were really interested in these things then they'd make it easier for Indies to make money on their platforms. It's not a coincidence that Team Meat ragged on MSFT for their treatment on XBLA at GDC and killed their Wiiware version of the game. Sure you have XBLIG on the 360 but can anyone make enough money on that to actually support a family comfortably?
The innovation platform of the future is the PC. And by PC I mean any generic hardware running some flavour of windows/osx/linux. Without an open platform to publish your games on you're stuck at the whim and fancy of the platform holder. The best part is that everyone here can help make this vision of the future come true. It's as easy as making fun and innovative games and actually getting them out there for people to play. We all know how to finish our projects right?
I'm at the point where I want to start integrating a physics engine into my game. In the past I've always used ODE but it looks like that project has started collecting dust and some of the old wikis on it have disappeared. With that in mind I'm looking at a couple new possible options. The requirements are:
- Support 3D and basic collisions (I don't need anything fancy)
- cross platform
- free for all uses
I'm looking at:
- Newton Dynamic
Anyone have any experiences with integrating Newton or Bullet. I'm mainly interested around ease of use and integration since I'm sure either would do the actual math I need it to do in a performant way.
A few nights of coding again gets me in a situation where I have the exact same output from my engine but I'm in a far better place! I completed the transition from having an XML file representing a scene to just exposing all of the scene creation calls to Lua and creating a scene in script. It was surprisingly more painful than I expected since there are so many different classes that needed to be bound to Lua. It was all fairly straightforward but it was a case where you're making a bunch of code changes and you don't really see if you've succeeded until you've got them all in place. It can make for some interesting debugging but lucky for me everything worked out smoothly.
Going with creating a scene in a script doesn't give me any kind of perf gains or fancy new features but it does make iteration faster and easier moving forward. I no longer have to worry about updating my XML schema every time I want to add a new component. I still need to bind the new component to Lua but that's a far quicker task. This work also had the side effect of getting me to do a little bit of refactoring as well. My XML loading code was doing some work that should have been placed elsewhere so now it is cleaned up and hopefully a bit more straight forward.
Thanks go out to Jason Z who had the suggestion of going with a script over XML in an earlier journal post.
Here's what an example script file looks like right now. Not really sexy but it is functional and fairly readable as well:
-- Lighting Objects
Scene:SetAmbient(0.2, 0.2, 0.2, 1.0)
Light1 = CLight:new()
Light2 = CLight:new()
Camera = CCamera:new()
------------- Game Objects
-- General Input Handler
Object1 = CGameObject:new()
Script1 = Scene:RequestScript("../../data/HelloWorld.lua")
InputListen1 = CInputListener:new()
-- Duck Model Object
Object2 = CGameObject:new()
-- Create Positionable
Positionable1 = CPositionable:new()
-- Load Resources
Material1 = Scene:RequestMaterial("Metal",64.0,1.0,1.0,1.0,1.0)
Texture1 = Scene:RequestTexture("../../data/duckCM.tga")
Texture2 = Scene:RequestTexture("../../data/hello2.tga")
Mesh1 = Scene:RequestMesh("../../data/duck.dae")
-- Create Renderable
Renderable1 = CRenderable:new()
-- Box Model
Object3 = CGameObject:new()
-- Create Positionable
Positionable2 = CPositionable:new()
-- Load Resources
Material2 = Scene:RequestMaterial("Metal",64.0,1.0,1.0,1.0,1.0)
Texture3 = Scene:RequestTexture("../../data/test.png")
Texture4 = Scene:RequestTexture("../../data/hello2.tga")
Mesh2 = Scene:RequestMesh("../../data/test.x")
-- Create Renderable
Renderable2 = CRenderable:new()
-- Overlay Test Object
Object4 = CGameObject:new()
-- Create Positionable
Positionable3 = CPositionable:new()
-- Load Resources
Texture5 = Scene:RequestTexture("../../data/hello1.tga")
Texture6 = Scene:RequestTexture("../../data/hello2.tga")
Quad1 = CQuad:new(0.0,0.0,1.0,1.0,0.0,0.0,1.0,1.0)
-- Create Renderable
Renderable3 = CRenderable:new()
Well the last couple of nights I've had some time to do some work and managed to get the input side of the house in order. I created an input listener component that is strikingly similar to the scriptable component. It is given a lua script to run and is passed in the latest input state to act upon. I'm not 100% sure if having separate components for handling input as well as handling running a script without input makes sense but I'll deal with refactoring one away in the future if I find that it's redundant. I was amazed again at how easy it was to hook things up using tolua++. I just needed to add the new input state struct to my list of bindings and viola it was a go.
One thing that is becoming apparent is that generating scenes through a script instead of a static data file is the better way to go. Whenever I need to add a new component to my model it means updating the scene file parsing code. If I had just gone the route of a script I would just have to expose the new component generation methods instead. I haven't gone ahead with ditching the scene file yet but it's only because of my limited amount of time. Once I get some more time I'll go back in and rework things.
While working in a coffee shop in the University district of Seattle I was showing off my GD.net colours for all to see! No one came to ask me about developing games . I blame my haggard look on a late night hockey game I had early in the week. I just can't burn the candle at both ends like the good old days.
I put the finishing touches on my basic lighting model this weekend. Nothing too special but I can now have an arbitrary number of lights passed into the fragment shader to use for lighting. The lights are just basic directional lights but they get the job done for now and more importantly no longer contain any hard coded values.
Now that I have a basic level of rendering together I'm going to move onto the input system. It's nice having some pretty pictures being drawn but right now I don't have any way to interact with any objects in the scene to really see how the lighting holds up to real time movement.
I present another duck shot with one green light and one red light coming in from different sides of the duck model.
One of the best parts about the journals here on GD.net is seeing the progress others are making on their project/games. It never ceases to amaze me how some people have the ability to just crank out work at such an incredible rate. And I'm not just talking about creating new content but also implementing new features. It can really be self motivating when I see such great work being done. Unfortunately it can also have the opposite effect of being demoralizing when I compare it to my own progress. There are days when I feel like I must be the slowest and dumbest developer on the planet because I just can't move from having a lighted duck to having a duck swimming on a dynamically generated pond complete with reflections, refractions and particle splash effects in just a few days. The reality of the situation is that not all projects are created equal. Just as importantly not all personal calendars are created equal.
At this point in my life I have a full time career that takes up a lot of time. As far as work life balance goes my current job is amazing but the reality is that in North America at least the average work week is now up to ~45-50 hours a week. Being connected to email 24/7 makes it more likely that I'll VPN in to solve some problem at a random non-core hour. I also am a parent of a 4 year old which is amazing but is another full time job. He may not be up 24/7 but he's so full of energy that he can wear me out as if he was awake 24/7.
I wouldn't change any parts of my job or my family life because I love both but it means that the amount of free time available to work on a project can be minimal. This past week I've been able to work for about 90 minutes on side work stuff so far. In that limited time I've been working on changing my lighting system to be completely dynamic instead of containing some hard coded lights. So far this has gone well but at the end of this work I have a screen shot that looks exactly like my hard coded screen shot. Not necessarily something that makes me run in the streets cheering . To top things off I should have been able to code the changes in less time but because I did the work late one evening after a business dinner which included wine I wasn't at my top coding level. Mistakes are harder to find after a couple.
What I've found over the years is that life is not a race. You need to find out what your pace is that makes you happy and stick with it. You don't need to compare yourself to others because the reality is that you don't know the whole picture. In fact there are reasons why going slower might be better for you:
Maybe you're focused on learning more than creating. Different tools make creating games easier and quicker but you might not learn as much low level stuff. If the low level stuff is important to you than slow might be better.
Going at a slow and gradual pace makes burn out less likely.
You have time to notice your mistakes before you get to far along and have to rip things apart to rework them.
Maybe everyone who works fast is an unemployed bum mooching off their parents at the age of 45? At least you've kissed a girl! j/k
In all seriousness GD.net as a whole can be a great resource for not only finding technical help but for personal motivation. For all your fast workers out there I give you kudos for being so efficient and focused at what you do. For my fellow plodders I say that I'm slow and dumb but I've reached the finish line before. It's possible to keep going and reach the end.
I had some coding time tonight so I started to dive into adding some lighting to my fragment shader. So far everything is very hard coded but I was able to get some simple phong shading going without too much trouble.
I'm really starting to like the programmable pipeline and the way I feel more connected to the the data being pushed around. Obviously the whole point of moving away from fixed function was to give you more flexibility and more power but so far it also just seems more transparent to what is going on. As painful as it is to have a complete lack of debugging tools for shaders I find it actually easier to debug issues than in my old fixed DX days.
One of the goals on my current project was to be completely cross platform. To force myself down that path I targeted doing all of my development in Linux. I had recently changed to using Linux as my main day to day OS anyway so it wasn't a completely new world to me but it did mean finding a new working development tool set. The hardest part of finding that new tool set was just going through the myriad options that are out there in the open source world.
IDE - The biggest decision was figuring out which IDE to use. I tried almost every option from Eclipse to MonoDevelop and everything in between. What I finally decided on was Codelite (http://codelite.org/). What sold me on Codelite was just the familiar feel of it coming from Visual Studio. I really hadn't used any non-Visual Studio IDE in almost 10 years and it just has a lot of the same feel and functions. Debugger integration is by far the most important thing I was looking for and it really is flawless out of the box. No fiddling/tweaking/etc. needed. I feel that I can debug at about 95% of the efficiency that I could in Visual Studio which is the most important part of any development setup. The auto-complete is nothing to write home about but it's passable. Outside of that the IDE is just zippy and stable. I ran into crashing issues with MonoDevelop and a couple of other IDEs.
Compiler - Nothing special here, I'm just using g++. I didn't really try any other options because I didn't see the need
Memory/Static Code Analysis - I don't have this bucket completely filled out yet. I've started using Valgrind (http://valgrind.org/) to look for memory issues but the output has such a high noise to signal ratio that it's painful. As I get deeper into the project I plan on doing more research into this area.
Source Control - Even though I've been a fairly big subversion fan in the past I decided to try something new and went with git (http://git-scm.com/). The main reasons for going with git was the ease of setup/use and the fact that I'm the only one developing on the project. I do most of my dev work in random coffee shops which may or may not have ports blocked on their wifi routers so using a remote server is out of the question most days. Have git local means I never have to worry about forgetting to make a check-in. I've gotten into the routine that the last thing I do before turning off my computer is a git commit.
Backups - Having git handle source control locally is great for rolling back changes and all the normal source control stuff but it doesn't save me from a HD crash. My backup technique is currently low tech and is a combination of using an external HD along with a DropBox (http://www.dropbox.com/) folder. Sometimes simple is the easiest.
OS - It's not really a tool but I thought it was worth mentioning that I'm running all of this on a 64-bit build of Ubuntu 10.04. I've tried many different distros over the years and Ubuntu just works nicely out of the box. I'm running it on my older Macbook Pro laptop and it has no hardware issues at all. It's got so many of the old Linux issues ironed out that I'm almost tempted to help my parents move over to Linux since all they do is email and browse. The key word is "almost"
One of the biggest challenges for me when working on a project is to fight off the natural lulls in work. When you're working on a game idea and start pretty much from scratch it's too easy to get overwhelmed by a project to the point that you lose all motivation to work on it. It's hard to see the light at the end of the tunnel when that tunnel is so long. What I do to try and fight that problem is to constantly work on baby steps that are either easily visible or fun. Seeing constant forward momentum is something that helps to motivate me.
The latest baby step for me was to add a fully positionable camera. It's nothing earth shattering but it's something that is going to be needed and it's something that you can visually see. The next few steps for me are adding an improved debug logging system and basic lighting. In the mean time here are a couple of quick screens showing off the ability to move the camera.
I'm a big proponent of not recreating the wheel. There's so much great open source code out there now a days that you can get working code for almost any problem. The biggest problem with open source code is usually deciding which option to use as there are usually plenty of them. The major things that I look for in an open source library are:
Cross platform support. I would say 90% of projects support the Windows/OSX/Linux trio so this usually isn't a big deal.
Easy to build from source without having to use any fancy tools. I like to integrate any open source libraries into my build process even if they come with pre-built libs. The safety of knowing that I can get the code building in any environment is comforting to me.
Community support. If I can't find any forum posts/tuts/etc. on the tech then most likely the code isn't being used by a bunch of people and might not be stable.
Developer support. I know this is usually #1 on most people's list but often times an older library looks stale just because it has fully solved a problem and is good to go.
So when do I decide to roll my own solution instead of using something already out there? Usually only if I want to learn how something is done or if I enjoy writing that kind of code. I've come to the realization that projects shouldn't just be about getting to the finish line as quickly as possible. We also need to stop and have fun along the way. Some would call us nerds for getting so much fun out of writing code but it's gotten to be almost a zen like thing for me. If I'm not coding on a regular basis then I don't feel centered
Onto the open source libraries I'm currently using in my project. I'm sure I'll add more as my project grows but this is what I have up to this point:
SFML (http://www.sfml-dev.org/) - My main development platform is Linux so when I started coding I started with bare bones X Windows. I haven't done any X Windows coding in almost 15 years and I was quickly ready to claw my eyeballs out. SFML to the rescue and I don't need to worry about any boring windowing stuff.
AssImp (http://sourceforge.net/projects/assimp/) - If you need to import 3D meshes there is no better solution than this that I could find. It just simply works and supports so many file formats it's sick. You can compile it down to just support the formats you decide on to keep the lib small.
SOIL (http://lonesock.net/soil.html) - I once wrote a whole bunch of graphic file importers for a steganography project I worked on years ago. It's not fun. It's not even remotely fun. Using SOIL is way more fun.
GLM (http://glm.g-truc.net/) - I once wrote a whole bunch of matrix and vertex handling classes for a graphics course back at school. It was not fun. I don't have that cursed code lying around anymore. Using GLM is way more fun.
Lua (http://www.lua.org/) - I once wrote a scripting language from scratch for one of my jobs. That was a LOT of fun. Way cool figuring out how to make an interpreter and byte code compiler. I don't have the rights to that code nor does it do half of what Lua does. As much fun as it would be to create a new scripting system that's an entire project or two in itself.
ToLua++ (http://www.codenix.com/~tolua/) - Yes it probably puts some overhead into my system and requires separate headers to get the binding all setup but it's easy as cake to get working and maintain. If I find any perf issues in the future I can always rip it out. No optimizations before their time!
pugixml (http://pugixml.org/) - Neat little XML parser that just works. Code examples show how to get everything working in 5 minutes. Sold!
I've been on the road for the past few days so I don't have a tonne of new progress but I did manage to get some simple textured quads working with an ortho projection for UI type stuff. Nothing mind shattering but having the vertex shader making the right decisions of what to do based on the object was fun to get going. I hope to have a more meaningful post later in the week.
Behold a couple of boring meshes and a textured quad!
In my last post about implementing a component based object model I also mentioned my drive to become data driven. When I looked into building a data driven game I saw two big areas where being data driven can help things:
1. Building a scene
I opted to go with a simple xml file to define a scene but there's no reason you couldn't go with any old format. There are just so many different XML parsing libraries out there already it just made sense to re-use instead of starting from scratch. The actual schema is also fairly arbitrary. Just go with something that makes sense to you. In the following example I have a complete scene setup. It's got basic camera data for a view frustum along with three different objects with a variety of different components. As I add more functionality and components to my engine the schema will grow with them.
2. Implementing game logic
In the past I have done most game logic in native code. It was separated out from the main engine code but still had to be compiled any time a change was made. On this project I've gone the route of using Lua for all logic. At least that's the goal. In the following test example I set the object rotating around the Z-axis while also fading between a pair of textures loaded for the object. I have everything exposed to Lua through the parent GameObject which just does a simple call through to any individual component that a method acts upon.
a = Parent:GetElapsedTime()
Parent:SetFadeFactor((math.sin(a) *0.5) + 0.5)
b = Parent:GetRotationZ()
b = b + 1.0
if b > 360.0 then
b = 0.0
3. Bonus area: Unit and Functional testing
While it's not actually part of the final game product testing is still an important function to insure the final product is a quality product. Being data driven makes it easy to be able to setup tests for all of your functionality using a bunch of data files instead of having to write a bunch of unit test code. While I was implementing my model importer I had a number of different scene files that would attempt to load models of different types and styles. It made things easy when it came to testing functionality as well as making sure I didn't have any ugly regressions.
All of this means less time compiling things but more importantly less churn in my testing applications. As I keep adding functionality to my engine library I'll be able to test them out by adding new data to my data files and my core test app will still only be the same few lines of code:
int main (int argc, char *argv)
CSimpleEngine *Engine = NULL;
// Create and initialize the engine
Engine = new CSimpleEngine();
// Create our scene and load a scene file
CScene *Scene = Engine->RequestScene("../../data/TestScene.xml");
A few years ago when I was reaching the end of my multi-threaded game engine project I ran across the following article:
I had never heard of the component approach to designing objects but it fascinated me and made total sense. After all I had all of the problems that came from the traditional deep hierarchies. I had big base classes with too much functionality, I was constantly dealing with keeping objects from having cyclical dependencies and it seemed like I wasn't gaining a lot from some of my different abstractions. Being near the end of development I didn't want to do anything as drastic as reworking my object model so I filed the article away and planned to revisit the component notion again in the future. Flash forward a few years and at the start of this project I dug up that article to refresh things in my mind and then I set it as a goal to try and implement a similar approach.
I'm definitely one who would rather take an iterative approach to development and design rather than attempting to sketch out a complete object model before writing a single line of code. Add in the fact that I'm only about a month into my current project and you'll understand when I say that I'm not 100% sure where the full object model is going to end up but I am 99% sure that it's going in a way better direction thanks to the component model approach. Not only does the approach really allow you to better partition specific functionality into specific objects but it almost does it for you. Add in the fact that it also lends itself extremely well to being completely data driven and you'd understand why I'm so happy with things so far.
To give you a high level view of my object model I have five main buckets of objects:
1. Base objects - very general objects like a scene and the empty game object which will hold the components
2. Managers - things like the renderer, resource manager, input manager, etc.
3. Components - renderable, positionable, scriptable, etc.able...
4. Resources - mesh, texture, shader, scripts....
5. Bindings - the odd ducks. They really aren't separate objects per se but the binding glue allowing everything else to be used through scripting
It just becomes so natural to think that you have a game object that is made up of components that happen to use some resources. Being able to easily put those together in your head means that it's even easier to put them together in a nice XML file. While I was working on getting the first components coded up it became almost necessary to write a quick parser because it seemed like so much fun. Now with a little snippet like this:
I can load some resources, attach them to a renderable component and get it rendering on my screen without having to change a line of code. Talk about sweetness! Of course I'm not going to give all the credit to the component approach as I had data driven design high on my goal list as well but it really just seems to dove tail so well together that instead of dreading writing boring parsing code I was actually super excited about it because the iterative bonuses just were so appealing.
Alright enough of the love fest for now. In short though if you're looking to try something new in your OO approach and also have a desire to get your game more data driven so you're not spending so much time waiting around for your compiler while you move a sprite five pixels to the right you need to check components out. Yes the link at the top of this post is four years old but if it's still that exciting to me then it might be for you as well.
A year or so ago I attempted to make a come back to journal land with a new project. I figured I had made it past the adjustment of being a parent and was ready to get back into having a side project. I'm embarrassed to say that I totally fizzled out. It had been a while since I had failed at a project that badly and it sucked. The one good thing about failures, and we all have them, is that you can learn from them. So what did I learn from my fizzle?
1. Pick a project for the right reasons
The idea behind my fizzle was that instead of focusing on the tech side of things I was going to focus on the game making aspect of things. Doing more things around game design and such was going to be fun and interesting. I was going to use off the shelf tech like Ogre3D to do all the heavy technical lifting and I'd just have to glue things together. Unfortunately it ends up that's not what I like.
While I don't mind game design in the context of a bigger project it ends up that it really isn't a full time passion for me. And while I can easily stick pieces of technology together it ends up that a lot of the joy I get out of coding is around implementing more of the low level and mundane items. I don't want to reproduce every wheel but I do want more coding than just writing a few scripts here and there. I listened to the "Make games, not engines" mantra a bit too much and lost sight of what I like to do. I don't want to make an engine outside of a game but I do want to make an engine inside of a game project.
2. Make sure you're in the right spot for the project
When I started back up I had just started my current job which was back in the games industry after being out for a couple of years. It really was a bit of games overload to think about starting a game project at the same time. Work really filled the gaming void for me and there just wasn't a whole lot of left over room for the project. When you add on the extra level of busy that comes along with a new job I was just asking for failure.
3. Make sure you aren't distracted by other projects
At the same time that I started the project I also caught the sports handicapping bug. Basically statistical analysis using regression models to help predict the outcome of sporting events. Hard core math nerdy and hard core fun playing with reams of data. I ended up getting a lot of my coding fix out of writing software to do all of this. In the end I found out that I can't handle focusing on multiple projects at the same time. The good news is that I'm done with that field for a while. My math is as good as it's going to get and now it's just using that math to beat my friends in football pick'em leagues
It was a tough decision to come out of lurk mode because of this previous failure and I didn't want to have another public fizzle. To make sure that wasn't going to happen I waited until I was already into my project for a few weeks to gauge my passion and buzz. I can tell you that I haven't been this stoked writing code in a long time. I'm totally having a blast getting things running and really enjoying having visual progress again. There's nothing like seeing something rendering correctly on the screen for the first time.
Enough of the text spew. The real secret to Journal land is to have frequent screen shots so I present the first screen shot from my current project which is very appropriately the basic rendering of a model ducky. Nothing too fancy, not even any lighting yet, but it is a Collada mesh being rendered using a basic vertex shader handling object transposition and a little perspective projection. The fragment shader handily applies the correct texture. I'll get into more depth about the various technologies I'm using to get it all together in a later post.
I was in lurk mode and was getting ready to start posting work on my new project and this site revamp has motivated me to de-lurk a littler sooner than I planned. All and all I love the fresh start to the site and look forward to it's continued evolution.
It's been way too long since I've done any kind of posting on projects so I'm going to start fresh and assume no one's heard from me before or remembers anything I've done in the past.
I've worked in the industry for the past 10 or so years. I currently work in digital distribution for PC games which is an exciting part of the industry right now. It has helped me reconnect with my own projects as I'm much more PC focused now instead of console focused. I am a developer by trade and education but I don't do a lot of coding in my day job so I try to have some side projects going on to keep my brain from rotting away. I don't consider myself a hot shot dev, a great game designer or an artist. I am a duck in the world of game development. I can do a bunch of things alright but none of them super great. As it turns out this isn't a bad thing.
My current project started because my coding was getting a little rusty and I wanted to get back into stretching my brain. I had a wish list of things I wanted to try/learn so I just set them out there and am building a project around those goals. The wish list is a combination of technologies and approaches that I wanted to try. The wish list is:
- Programmable pipeline (Yes I'm old and have only used fixed function in the past)
- Using a component model approach instead of a crazy hierarchy of objects (Being completely data driven as a side goal)
- Completely cross platform development (My day to day OS for development is Ubuntu)
- OpenGL (Very DX focused in the past due to xbox dev work)
- Game design collaboration (Always did stuff by myself in the past but this time I have someone helping with the game side of things)
I've been working on coding for the past couple months and am making some decent progress that I'll start to layout in the next few entries. It's great to be back and I hope to be able to make some posts that are fun to follow and maybe even a little educational.
So I have not been slacking off on hobbies and sitting around playing games but I have been short on gamedev work to post about. I have another fairly new hobby that takes over some of my free time come September and that is sports handicapping. NFL handicapping in particular.
Last year I started work on attempting to handicap football. I am not looking to become a professional gambler or tout, nor do I think that such a line of work could be profitable for me or 99.9% of the rest of the public out there. It really is a hobby out of enjoyment of math, football and gambling. It's an outlet for me to remember some of my latent math skills while also learning more about the game. I actually don't place any real bets on games but I do track my performance as if I was really betting on games.
In my first year I used a fairly basic mathematical model that only used scoring, home field advantage and strength of schedule. Using that system I was able to pick winners 53% of the time against the spread. That's just a touch above breaking even as football bets are made at 11/10 odds.
This year I'm supplementing my math model with some more old school handicapping skills looking for situational edges. So far I'm 6-7 for the season so I'm under 50% but the season is a long one. The goal is to beat 53% but in reality the sample size of bets made is so small that the final numbers don't mean a hell of a lot. :)
Anyway I of course make all of this easier with the help of coding and that's what I've been busy doing this past month. I used a Ruby on Rails system last year to do all my data entry and calculations but having MySQL running on my laptop was too much of a pain, and hampered portability so this year I switched to a spreadsheet. It's totally old school spread sheet running BASIC macros. I haven't done anything like this in almost a decade so it was fun remembering my BASIC chops :) But my tools are all completed and tuned up so now it's just running numbers for the rest of the season so I'll be back to gamedev stuff again.
It's going to take me a little bit to dive back in but when I last left off I started work on the networking components so expect to see some stuff along those line soon.
So every real project needs some kind of source control. Even if you're working on a single person project, like I am, source control is vital to keep yourself from going crazy.
In the past I've used SVN on almost all of my personal projects. It was always fairly easy to setup and run and provided me with a nice backup since I ran an SVN server on a separate machine from my dev laptop. When I got around to putting together something for my current project I decided to see if there were any new options open to me on OSX. I looked at SVN to start and also gave Perforce a shot since I use that at work but what I finally ended up going with was Git along with GitX as a front end.
Since I do all of my dev work on my laptop I tend to do most of it in different coffee shops. This always was a problem when dealing with SVN since my server was at home, behind a firewall. I tried a bunch of different things using SSH to be able to access things remotely but it was just such a pain to setup/maintain when I made the switch to Windows for my home server. Running Linux in a VM was something I did for a while but once again there just ended up being too many moving parts.
After deciding to take the server out of the equation there really was no comparison between the options. For a single dev on a stand alone machine Git is the way to go. Zero time/pain to setup. Zero pain to use and very performant. I now have easy access to my whole depot we some clean and fast diff capabilities in a nice UI.
Obviously this setup doesn't take care of the backup situation but I do pseudo regular backups on my machine onto an external drive using Time Machine. It's not perfect but it'll do.
If you're sitting there wondering why on earth a single dev needs source control then you need your head examined or your idea of coding involves HTML and notepad.exe
Tractor Beam Progress
This week was spent cleaning up the hinge joint work that I got working last week along with refining things a bit. A quick video of the current state of the prototype can be seen here on ">YouTube. What you'll see in the video is:
- One large ogre head moving around. This is what I'm using as placeholder for a "ship". I can apply forces to it using standard WASD controls. It moves like a sluggish space ship in jello. :)
- Three small ogre heads moving around. These are what I'm using as placeholder for "asteroids". To make sure I could get collision masks working properly Asteroids can bounce off walls and the ship but not each other.
- A mouse pointer.
Using the right mouse button I can grab any asteroid from the ship which attaches a hinge joint between the two. The ship has a larger mass so typically the asteroid will spin around the ship. I didn't have any art in place to draw for the tractor beam so I just highlight the grabbed asteroid by drawing the bounding box for it. It's not pretty but it's enough to get a feel for the mechanics. The tractor beam holds as long as the right button is held down. Releasing the button destroys the hinge.
The next element I want to add is the ability to have a map bigger than the screen and having the camera adjust properly. After that it's onto shooting asteroids.
The latest code drop is here. The code is very ugly and spaghetti like at this point but it's just proof of concept stuff so I'm fine with it. :)
This week I've been working on getting some prototype stuff up and running. The first thing I wanted to do was simulate a ship shooting a tractor beam and catching an object. This was easy to do with ODE using a nice little hinge joint centered on the ship shooting the tractor beam. The hinge lets the object keep it's momentum by swinging around the ship on the hinge. This opens up all kinds of fun game play ideas around throwing asteroids at your enemies instead of just blowing them up, using asteroids as shields, etc.
To get the initial test working I added two objects to the scene, set one in motion and took control of the other. I mapped a key to create the joint between the objects no matter the distance and then mapped another key to destroy the joint. I got this running in minutes.
The next step of course is to make the mouse trigger the tractor beam such that you can pick which object you want to catch. This is slightly more involved but not much, or so I thought. I got to work on setting up simple mouse picking and realized right away that I can't call my favorite unproject() API for DirectX or OpenGL due to the fact that the underlying graphics API is all abstracted away from me. Surely there has to be access to those calls via some sort of wrapper class right? According to my research the answer is no.
All my research on Ogre3D mouse picking pointed me towards rayQueries from the camera object. Not one to be afraid of learning a new approach to things I dove right in only to hit a big pile on crap. I just couldn't get things to work. I had samples of the code working but anytime I plugged it into my scene I got nothing. No hits on anything.
Now what you have to know about this current project is that it is very part time and I'm lucky if I can find 4-5 hours a week to work on it. As such when I hit a wall like this it usually means I'm going to be stuck on it for a while which sucks. I'm not one who does well in a stuck state. If I hit something that is blocking me I normally keep hitting my head against the wall until I break through. With my lack of available time I just can't do that which bugs me and makes me less excited about working. I mention this all because I'm sure I'm not the only one who runs like this. If you find yourself in this situation know that we all run into this kind of thing. What I've been doing to keep myself coming back for more is envisioning all the cool stuff I'm going to get to code one I get past this wall.
Long story short I finally got past my wall tonight. Ends up the way I was calling this function only works on world geometry like terrains. To get it working against any old entities is passing in a different param. Trivial problems like this are never trivial when you don't have a lot of experience in a piece of tech. I fully appreciate why more people walk away from existing tech when they hit a problem like this. Not knowing what exactly is going on under the covers can be a pain sometimes.
Anyway I need to clean up my code from all the hacking I've done in the last week trying to get things working. Once I do that I'll post the latest stuff.