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.
Posted by Mike Bossy,
10 September 2011 -
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.
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
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.