T+167

Over 100 hours since my last post. Feels bizarre. I had to recheck to make sure it was correct, since I was sure it was yesterday. I also have a minor sleep deprivation thing going on. Last night I finally brute-forced the first working network implementation for the Quickrally with pure willpower. When I finally got it up and running, it was something like 7-8am. I collapsed to bed for 4 hours, just to wake up for a afternoon lecture @ school, only to find out that the damned thing was cancelled. Fortunately I didn't wake up for nothing, since there was a weekly meeting of Load (our gamedev club @ school) soon after. We were able to do a little testing on the new multiplayer version, and even recorded a short video:



As you can see, I have removed all the eyecandy from Quickrally for testing purposes, just to underline the stuff about prioritising the gameplay/fun over the fancy (yet technically more intriguing) visuals. This also cut back my pregame loading times alot, which is great.

I realized today, that I need to start specifying some concrete todos for the crunch now. I knew beforehand, that my crunching would be more concentrated on december, and there were more "other stuff" for november. Yet I still have the feeling, that things haven't progressed as much as I'd liked. I really have to separate the must-have features from the rest. The truth is -- and I'm very glad this is the case -- that only the Tanksalot needs to be in a robust and polished form after the crunch. Quickrally can (and will) be more of a prototypish demo when I pass it on to my teacher. It has to run, it has to look decent and it has to come with documentation and that's about it. This gives me some leeway on what I'm trying to get crunched until the 9th of December.

Tanksalot

1. Replace the powerup placeholders with actual 3d-models
2. Polish the audio
   
3. Add a "Rematch" button
4. Clean up all the debugging data and unused assets
   

Quickrally

1. Make the server more robust with players coming and going
2. Give the players waypoints and subgoals (laptimes, scoreboard, etc.)
3. Try to test and optimize the network code for WAN connections
   
4. Finalize the carmodel
   
5. Bring back the old shaders and eyecandy when the other stuff is done
6. Figure out if the preload times can be optimized
   
7. Try celshading

There is also a common task for both of the games, which I left out from the lists: Try to make them work smoothly on different setups and OSes. Today I tried the Tanksalot @ school with a 64-bit Windows 7 and I got it to run, but it had a flickering loading screen and it eventually crashed on OpenAL initialization. I got the Quickrally multiplayer demo to run alright on the same machine, but it had some weird jaggs and jitters on frame rate every now and then, even though the CPU load never went over 30%. It was weird. Couple weeks ago we were also able to get the eyecandy version of the Quickrally to run on an iMac, but for now I'm trying to focus on getting the two games work on all the Windows setups smoothly.

T+63

I got home from work and eventually ended up doing the health/ammo -powerups on the Tanksalot. You can see the red and blue placeholder boxes in the background. I also put some touches on the missile. There is now a shiny billboard texture to respresent bright light from the afterburn + some more flash with the same texture when it explodes. It made the missiles much more visible which is excellent. It was kind of disturbing when you couldn't get any feedback behind those sexy smoke particles. I also added a little more ground texture to see where the ground is, since there aren't much shadows or other artifacts lying around.

I have one informational bit to share with you who are planning to make a split-screen game: It is a very hard to determine if your split-screen game is fun. You can't test it with your friends over the internet (unless you make support for it) and testing it alone is just a waste of time. Sure you find the bugs, but the actual gameplay needs two players on one machine. Period. When I played a prototype of Tanksalot with our team for the first time, I felt like a utter retard. I just had some kind of false expectation, that two tanks fighting against each other, on plain ground with unlimited ammo, would be fun. It worked for the Rocket Arena-mod in Quakeworld, so why not here too? Well all I can say that it was a very very sad five seconds for me personally.

I took some lessons from my disapointment and even found some deeper insight later: I noticed how my pattern of doing gamedev has always been the visuals and the engine beneath the game. I just end up using huge amount of time to get some textures or bloom (oh I just love the bloom) for some early prototype, where no one else gives a s**t how it looks. Or maybe try to optimize some part of the code to give me +0.23 frames per second. The truth is that I have never really paid too much attention to what is (or could be) really fun for the player. I was just too busy having fun myself with building stuff out from nothing and making it look extra nice. One of my friends nailed it down in a simple slogan: "You have to decide if you are making games or game engines". The right way to make great games is just the opposite of what I was doing. You need to prototype your idea without the glitter and make it fun. You can paint it with pretty colors afterwards. Well, I'm still a new kid on the block, and there is a lot to learn, so mistakes are bound to happen.

That's it. Now it's time for this new kid to get some sleep. Ciao!

T+49

I pretty much sat in front of my PC the whole day. I was feeling very unproductive thought, and everything seemed to take me longer than expected. I guess it was just one of those days. I'm glad it wasn't a total disaster and I was able to get things done too. I focused on the Quickrally's client/server implementation like I planned in my long post yesterday, but didn't get to drive my car around the server yet, like I was hoping for.

My networking engine was missing a system for reliable packet delivery over UDP and that took me many many many hours to get those ACK-packets to do their job. Now it's finally up and running, and I was able to transfer settings, heightmap and roadspline to client-side, without worrying about missing packets along the way. You can get away with losing a packet of current coordinates for some arbitary world object, but losing a packet describing your vehicles suspension or maybe some curve in your road is another thing.

I was planning to explain the way I'm going to implement the networking in Quickrally, but I feel that it is going to be more useful to write about it after I get the first working prototype out of the oven. I already have a pretty good idea how everything is going to be implemented, but I never used a physics middleware like Bullet along with my networking stuff, so there might be some surprises in store for me.

Tomorrow I'm going to focus only on Tanksalot. My goal is to add collectable ammo and health packets, which are going to drop out from the sky in some parachuting manner. This is going to make the gameplay much more sensible, because players now have motive to drive around and not go straight for the kill, which made the game pretty retarded so far. I don't have the 3d-models for the powerups yet, but I'm going to use some placeholders. I'm also going @ my dayjob tomorrow, so I don't think I have time to do anything else for the game. Well I could stick in the new audiosamples if I still have time & energy left.

T+26

By now there might be some random (missclicked) readers who are not affiliated with me @ school or otherwise and might want to know what are these two games about. Actually Tanksalot is maybe over 80% complete and Quickrally - while never going to be totally finished - has come a rather long way too.

Quickrally

Quickrally is my flagship project at the moment. It is going to be very much multiplayer-only driving game. I'm leaving out all the boring career modes and fony stories. Focus will be on driving and driving only. One feature that sets Quickrally apart from other driving games is the procedural side of it: The track will be different everytime you race. Now it's more about driving skills and less about memorizing all the tracks to beat your friends.

Tanksalot

Tanksalot is a game I've been coding couple of months now. It's a school project for a course called "Introduction to Game Development Tools". I have three other people besides myself in the group doing modelling, 2d-art and audio. It is split-screen tank duel with non-linear fire and very simple game mechanics. We decided to do cartoon-like style celshading and I really like how it looks now. I might do celshading in Quickrally too.

First day of war

I got over the fence and into the trenches tonight. Coke bottles were opened, coffee ended up being very strong and beautiful code started to emerge. Well, not so much emerged, but the existing code took some refactoring blows and heavy cleaning was being made by our late night coding hero. I also started to get better vision how to implement networking into Quickrally and that is what I'm going to explain next.

Networking

Networking in a real-time fast-action multiplayer game is not very easy or straightforward. I would not recommend it to anyone doing their first project. There are no complicated mathemathics involved, but quite alot of ways to hang yourself while implementing your multiplayer extravaganza. Be warned: You are almost always screwed, if you try to add multiplaying features to your game afterwards, unless you have used some very sophisticated event-based architecture in your game. And even then you are still probably screwed anyway.

The story of multiplayer networking

Once upon a time, you were player in this distributed world (it means that the world exists in multiple computers). You decide, that it is time for you to walk forward, so you send the server a message: "dear server, I would like to walk forward, if this is anyway convenient for you, sir". Notice the polite tone in the message. This is due the fact, that in this very world, the server is in charge of everything. The server is the KING. You do not f*** with the king. After all, what kind of world would it be, if every person could decide the laws of physics for themselves? A world very hard to implement in any programming language I know.

So back to the story: The allmighty server gets your request. It does some calculations and decides to reply: "So you little punk, you wan't to walk eh? ... well go ahead, your coordinates are now x,y,z and your velocity is v". This message is sent to all the players nearby, so that they all would see you in your new position. After all, all the other players are in a different dimensions, interconnected only by his highness the server.

So everyone got your new location. Well, everyone except your cousin riding on a horse toward you. The king uses high-speed messagepidgeons to deliver these messages, and the very bird that was going to deliver your cousin the information, had one too many tortillas for lunch, and has stopped somewhere along the way to take a dump. So now you're cousin is not aware of our hero's new location, which happens to be right across his path. The king has also set a new law, that in order to save money, he always waits for the pidgeons to get back to send new messages. So while the king is waiting for your cousins constipating pigdeon, his next physics calculations get closer and closer to a crueling outcome: You, my friend, are kaputt.

Afterwards, your cousin decides to bury you right there in the spot. While he is digging your grave, the unfortunate pidgeon finally arrives and delivers the message. The cousin reads it and goes red-hot-al-qaida-mad, screaming his lungs out: "what the f*** am I going do with this now?!". If only the message got there in time.

The pidgeons in this story were UDP-based by the way. It means that they are fast and light, but not guaranteed to arrive in order, or better yet, not arrive at all. There is a simple solution: The king has to send pidgeons after pidgeons and not wait for the comebacks. In a time-critical game, the information gets old the very second it is being sent. Nobody wants to know your location 2 seconds ago. It's yesterdays news.

TCP or UDP?

Awhile back, when I started to research the subject, there was alot of dispute over which protocol to use. I don't know if the disputes still go on. If I had to guess, they are. Have you ever heard a dispute being settled in the wonderful world of interwww? I sure haven't.

My advice is this: The more time-critical your games, the more you want to lean toward UDP. If I'm doing a game like fast FPS-shooter or driving game, all the milliseconds in our response-time are going to make a huge difference. UDP gets things done faster and lighter, so it is the weapon of choice for fast-action. After all, how wrong can mr. Carmack be?

Then again, if you are creating turn-based strategy or slow-based roleplaying game: Go for the TCP. It guarantees order and delivery which makes life alot easier when your needs are more toward events and less about current state.

There is also third option: the hybrid model. Use UDP for time-critical data and TCP when you need more hi-fidelity order and delivery. I personally dislike this approach (in theory) for it's messiness, but have actually never tried it myself, so I try to refrain myself from making foolish comments about stuff that I'm too retarded to implement.

This ended up to be a very long post indeed. I got a little carried away by the subject, but no harm done I guess. Tommorow I might get my multiplayer implementation to actually work and maybe I'll explain my approach in a little more detail.

T+11

So even after a good night sleep, I didn't end up hating the idea of blogging and made it public @ blogspot. I really feel that I should have started a blog about Quickrally -project from the day one. It would be so cool to see how the engine grew from very simple "helloworld in OpenGL" to what it is now. I really should use quote marks around the word engine though. I'd rather describe it as a codebase or even "big pile of undocumented gamedev code for me to copy-paste from". Game engines typically have more features, more structure and more encapsulation. This makes them useful for everyone. My "engine" is useful for me and me only. I'm going to refer to it as engine for now on, but take it with a grain of salt.

While the Tanksalot and Quickrally essentially use alot of the same components and code, I actually separated the two projects completely. Due the lack of solid structuring and careful planning, I was slightly afraid that whenever I did something new in the Tanksalot, it would break things up at the Quickrally and vice versa. It is not something I'm very proud of, but it was necessary for my immidiate mental health. While the two are now separated, it is still very easy to copy Java classes from one project to another since underneath they share similar structure and hierarcy. I'm going to go deeper into actual engine later in the blog and explain what I did and why. For now I'll just say that I'm using stuff like this:

• Java
• LWJGL
• OpenGL
• OpenAL
• Bullet Physics (JBullet)
  
• Lightwave
  

T+1

I decided to start this sort of "miniblog" that has finite timeline. In this blog I'm planning to blog about two game development projects that are going to be big part of my graduation process: Quickrally and Tanksalot. I calculated that I have exactly 440 hours of time to finnish them both. There are other courses too that still need some effort and I need to do minor work-related stuff too, but mostly my time is now relatively free for some serious gamedev crunching.

My main reasons for starting this slightly time consuming blog are:

• I need to document these projects for school credits anyway
• I have a theory: Writing interesting stuff in the internet is more likely to have positive than negative outcome later in life
• Easier to keep track of the progress
• Writing is fun!

Readers of the blog (if any) are most likely going to be finnish, but I'm still doing this in english because:

• I seem to think about gamedev in my head in english
• Why put anything informational in the interwebz in finnish anyway?
• God damned, I just feel like it!

I'm not going to make any announcements like "I'm going to write atleast eleven posts per day" or "I'm going crunch like hell these three weeks and make some superb gamez". Life has taught me that while they seem like realistic goals beforehand, I am notorious for trapping myself with overoptimistic goals. So all I'm going to say is that I'll try to update as often as I feel fun and inspirational about it. Nothing more, nothing less.

Now I'm going to get some zZz. If this blog still feels like a good idea in the morning, I'll make it public.