Friday, July 15, 2005

Game in a Day

I've decided that in order to get back in the groove for Bulwark, I need to do something game related that is not Bulwark. So I'm joining in on the GID fun (www.gameinaday.com). The theme is ghosts, and I have an idea that could be fun. Here's the link to the design doc: (link removed)

I'll probably post updates or at least a post mortem here when it's done.

Tuesday, June 07, 2005

Bulwark update

Bulwark is still moving slowly. It has been almost standing still for the past couple of months, but it is getting to be playable. You can build walls, place cannons (only in secured areas), then fire cannons one at a time. This is all done in timed rounds (building round, place cannons round, attack round). The attack round has static enemies that spawn during the building round and attack your walls in the attack round. John Seguin has made one sweet music track for the building round... done in surf rock style. I'll eventually put some links to his site, since I'm impressed with his ability to compose music in such a variety of styles.

The next step is probably to work on the enemies to make them move and give them different abilities. Networking is also in a bad state... I have not got that working fully just yet. It has worked on my local machine by starting up a dedicated server, but it doesn't show up on the GarageGames master server. It may have something to do with the campus firewall and such.

My summer hasn't officially started yet, since I'm working full time and taking a class, but class is finished next week and I'll have a few more hours per day to do other things. I graduated with my BS in Computer Science and have already started the MS program at the same place... Brigham Young University. I'm working in an AI-centric lab with robots and stuff. It's a fun place to do research. That's all just to let you know that I'm not twiddling my thumbs all day, but have other things going on. Gamedev is just a hobby for me!

Wednesday, February 02, 2005

Time Machine

The contained area scanning is now in 100% c++, and it's fast. Fast enough to not notice it happen, anyway. The display of the contained areas is still slow, since it must create a new object for each gridspace that's contained, but that will be eventually solved by using openGL to draw such things directly on the client. I might even use tri-strips or something.

Anyway, I also got started on moving things to the client. All of the script code to handle multiple clients is there, on the server scripts at least. I still need to create the proper stuff in the clientside scripts for two people to actually play. Before I started on this, I realized I need to send some stuff across the wire. This will make two people on the same keyboard rather simple to implement, but even more importantly it will allow network play. The reason this needs to be so is each client needs to keep track of the walls, contained areas, and other things to reduce network traffic. Just sending updates will be more efficient than storing everything on the server and having the clients access it each time they need it.

So I've been struggling to think of the best way to approach this, since my network coding experience is slim. Just today I spent about 2 hours trying to wrap my head around the whole concept. I think I've finally got it, and that means that fairly soon network play will be possible. So I can sit at work and play... er... I mean... test... yeah, test my game with my wife at home and see how it works. It's exciting just thinking about it.

When I published my one and only game Booym, I was 18, and the whole development cycle was only 3 months. It was a fairly simple game, but I look back and wonder how on earth I got so much done in such time. Yes, it was summer, but we traveled around part of the time, and other things were always distracting (I still like to play other games, too). So it was really more like 2 months. Anyway, my point is that I've tried to reach back 6 years and figure out what was so cool back then. The answer? A clipboard. Yeah, I had a clipboard for my game. I've never done well with full design documents. My design documents consist of a couple short paragraphs describing the essence of the game. Sometimes I explained a particular feature in a little more detail, but there was very little design on that clipboard. Mostly I just dove into the game, got a prototype working, then starting adding stuff I thought would be cool. The main thing on that clipboard was a checklist. While working on the game I would think of other things I need to do. When such things came, I wrote them down. My prioritization method invovled putting a box next to things that need doing soon. I doubled that box if it was urgent, and tripled the box if it needed done today. That's it. In subsequent game attempts, I've tried to be more formal, and I end up spending too much time designing until I get bored and think the game is going to be dumb. So I'm reaching back in time to get that same adrenaline from making a game impromptu. I'm hoping it will work better.

The next steps are to get the necessary data on the client and synchronize with the server. After that, it's getting the build command and fire command to work from the client (simple). Then I've got to code in all the piece templates to make the game more interesting, and randomize the selection of the next piece.

Monday, January 24, 2005

We have the area contained, sir!

This weekend was quite productive. I even have a screenshot to prove it.

The keyboard-controlled marker now places objects and acts as a target in firing mode. In building mode, the marker icon is changed into a "wireframe" of the piece to be placed next. It's not really rendered as a GL wireframe, it's just some DTS objects. The aim marker is even a dts object (though just a plane with bitmap). I even had time to do the contained area check. And half of it is in C++ code (since it was slow... about 12 seconds to compute just a quarter of the map!). I started on getting the other half into C++ code this morning, and I'll definitely have that done this week. The first half sped up the whole process to 5 seconds for the entire map, so that's good. The c++ code is still calling some script functions to build the markers and to check for walls, which are key points in the loop. Once it's all in C++, I expect it will be fast enough.

Right now the contained areas are displayed by spawning a dts object (translucent) just above the terrain at each point on the terrain. Yeah, that's slow. So eventually I'll make custom GL code or something to draw patches above the terrain client-side. I plan to represent the occupied areas with quadtrees to reduce the network traffic.

Also, the piece building "template" is on the server, so each client would build using the current piece/rotation shared by everyone. That might be interesting, but not for this game. I need to migrate the piece code to the client, and just transmit which piece number and orientation to build at. Or perhaps even just the orientation. The position is already stored on the server... the idea is to avoid blatant cheating.

So my next steps are to finish migrating the contained check code into C++, then to move the piece-building stuff to the client, so each client can build a different piece. Cool.

Now check the image. If you look carefully, you can see a couple of arcs from cannon shots.


Friday, January 21, 2005

Focus Lesson

Ok Reader-San, it's time for a focus lesson. Breathe in, breathe out. Well, actually, the focus of the focus lesson is me. Er, I'm the student. Anyway, I've made a good amount of progress on Bulwark (that's the code name for the new game), but I spent more time that I probably had to at this stage.

Last night I polished off the piece placement code. The problem was you could overlap pieces, which isn't supposed to happen. It turns out I was using world coordinates as an index to the map instead of map coordinates. Simple enough.

Then I started tweaking the ballistic aiming code. I tried tweaking, but the problems were still huge. I searched for another method for a good 20 minutes, and I came across an article covered in AI Game Programming Wisdom. Their formula was a little different, so I implemented that. Wow. Instant improvement. It still needed tweaking, so I started tweaking. I spent about 3 hours working on the game last night, and at least 2 of those were spent tweaking. Gah! I must focus! The aiming isn't perfect at short range (it almost is at long range), but it's good enough for prototyping. In my tweaking time I also spent too much time goofing around... placing blocks, placing hordes of cannons, and letting the blocks have it. It's fun to watch, but really sort of a waste of time at this stage. So I realized at 2am that I should put it down and go to bed, then work on something better the next time.

This morning I got up early relative to my bedtime, did my English homework, and started punching away at the game. I put another 1.5 hours in or about that. This time I was more focused. I got rid of the point-and-click method, and transferred the camera movement control to the mouse. The keyboard will still be able to do this, mind you. Now the keyboard controls move around a little marker (for now just another brick) to show where the cursor is. It's rather nifty, and a pretty big change. I still need to add key bindings to rotate pieces and place objects, which shouldn't take more than 15 minutes. After that, the next step is to have the marker show the complete piece and its rotation in build mode. In combat mode, it should show some sort of aiming marker, and not snap to grid like it does now. Again, once this is done, I'm going on to the contained-area code, and the game's looking pretty good. Maybe one of these times I'll post some screenshots. Probably after the weekend.

If I decide to work on this game instead of the Game in a Day, I could very well have this all working this weekend. I really should skip the GID, simply for the momentum of this game. I have a good concept for the GID, but doing it will take time away from this one. If only I had waited to start until this weekend...

Thursday, January 20, 2005

One Hour of Productivity

The past 24 hours have been fairly productive! I managed to get 1 hour of game dev time into my busy school and work schedule. Last night I scaled the whole map down (trivial in Torque). I also started adding support for arbitrary "tetris-like" pieces. I almost finished, then had to go to a dinner meeting. While there, I tried to come up with an algorithm to find areas surrounded by a wall. I thought I had some good ideas, but each of them failed in one case or another.

After I got home, I looked up an algorithm for finding closed-in areas on a grid (areas surrounded by a wall). It took about 10 minutes to understand how the algorithm works. It's pretty neat, but will be fairly slow on my tentative 256x256 grid. But then it only needs to be done once every couple seconds at most. Optimization can wait.

I woke up early this morning to put in another half hour, and finished up the arbitrary piece code. It still has one small problem, but I'll sort that out soon enough. I also added rotation support, so each piece can be rotated 90 degrees. That's not tied to any controls yet, but that's not difficult. Once I polish off the piece code, I'll go back to the projectile aiming code to get rid of the problems. After that, it's changing the control scheme to use the keyboard for movement and piece rotation/placement. The mouse will be used to control the camera view. After that, the code to check for contained areas, and then it will be half playable!

Wednesday, January 19, 2005

Starting a New Game

Greetings. Since this is the first blog post, I'll explain what I plan to post here. I am a completely independent hobbyist game developer. That means my team consists only of me. I have a few tools (but I always want more, of course), and I'm poised to rattle off a game.

Since I'm a one-man team, I try to do everything. That includes game design, art assets (3D and 2D), coding (all aspects), sound, music, and marketing. Needless to say, it takes a long time this way. I did manage to get one game on store shelves (packaged with others) back in 1998. It's called Booym. The profits from that have stopped coming in, so I'm working on other projects.

For almost a year, I've been dabbling with one idea, called Captain Disaster. The basic gameplay was teams FPS with a goal other than shooting each other. You had to hunt down three different resources, bring them to processing machines, then take the processed material to another machine. Doing that the fastest would constitute a win. I never did really come up with good win critera... but getting that final machine loaded up was the first step. Each resource had different firepower properties... explosive, long-range, or mischief. That also depended on its "refinement." A few days ago, I decided this might not be the most-fun-to-play game. Not even a kind-of-fun-to-play game. It was taking a lot of work and a long time to get things into prototype phase really. I knew it would take at least a year to finish, and I wanted to finish a game sooner.

That leads us to the title... "starting a new game." The new game is (hopefully) much simpler. The gameplay is similar to the 1990-ish arcade game Rampart. You use tetris-like pieces to build a wall around your castle, place cannons, then fire away on the enemy (boats if single player, another castle if multiplayer). My version of the game will introduce a few new things, as well as a different feel. The theme won't be castles. It's not even going to be modern warfare. I haven't solidified what the theme(s) is going to be, so I won't hint at what it's going to look like yet. It's going to be different enough that Atari won't have grounds to sue me out of my pants. Well, at least not for copying their game.

After about 10 hours worth of work (mostly done Saturday) I already have something close to prototype. You can build walls out of single bricks, place cannons, and fire. This is all done with mouse clicking. This is being done with the Torque Game engine (3D), by the way (GarageGames - Torque). The firing is even fairly accurate. It's not perfect, but it might be good enough. There is a bug, though... there's only a 180-degree arc wherein the cannons fire correctly. Outside of that (I say "behind the cannons") the behavior is erratic... they fire straight up or randomly. So there's a bug in the code somewhere.

Before I fix the aiming, though, I'm going to put in some basic tetris-like pieces to build with (instead of single bricks) and the code to check for a closed-in area. You can only build cannons inside such closed areas, so that's an important step. Once those two things are done, the prototype will be playable, but not complete. I plan to change the controls to keyboard and add 2-players-crammed-together-on-the-same-computer support. That way I can play it with my wife. Then I'll start adding new features and have fun with it.