Digital Dave

While the thought of building a really fun and interesting 3D game definitely crossed my mind, and even got me to the point of writing out a few pieces of documentation on it, I just couldn’t commit to it.   So, instead, I decided to drop back into 2D mode while setting the bar pretty high with things that I want to get out of this.  It’s definitely been a slow start due to flopping back and forth on a idea, but I’m moving now.

For this project I will be using C++, OpenGL, SDL, and Adobe Photoshop.   My goal on the art side is to actually find an artist that wants to work on a project for fun. I also have somebody that will be helping me create audio for it.  And I have somebody open to improve the design, if needed.  There’s networking in action for you.

So this is a vertical scrolling shooter game.  My inspiration for this project are recent titles released by Big Fish Games: Star Defender 4, Alien Stars, and others.  I played several games, wrote several ideas, and added bits and pieces to the design that I thought were missing.

My approach to game design is rather simple.  I have 4 principles that guide me through this process.  In fact, you may have seen my prior logo (Made a few years ago; used to be on my GD.NET journal):

Blue: Fun
Yellow: Rewarding
Teal: Immersion
Red: Challenge

Once I have solidified a genre, I start thinking about how this game is going to reward the player, while being above all else, fun.   I love rewards, and I see their effects every time I watch my girlfriend play a game, or my nephew.  Players want candy, and they are more than willing to accept it.   I don’t want subtle rewards, I want to see my rewards!  So right off of the bat, I will be introducing a Ranking system, similar to the Military’s ranking.  I’ve designed 10 different ranks that will take the player from the Enlisted side, and over to the Officer side.

What will being a higher rank achieve?  Better, unique, weapons.  A Captain will have special weapons that he/she starts the new mission with that a Private would not get.  These include “Helper” ships that will flank the player, and as you progress, they will become stronger.  This also leads to more advanced bombs (guided, and others) and shields.

The promotion system will be based off of several factors.  The players kill to death ratio, time in rank, bonuses, and special kills.

Special kills are also a new addition.  Consider this a bounty.  On your screen you will have an image of who you need to seek and destroy.  These are special creatures/ships and they will not go down easily.

I also plan to introduce quests to the game that will trigger between missions.  These will involve capturing, instead of killing, specific creatures/ships…  Destroying specific landmarks…  Among other things. They won’t be hard, just something to add to the game that will give the player another option and a way to tie the player into the story.

And I have more that I will wait to share until I start making headway into this.

So, the programming started a few days ago.  I haven’t devoted a lot of time to it, but that will begin to change.  I had to spend some time re-developing how I do things since I’ll be using OpenGL for my graphics, and I’m still trying to piece that together.

I have a scrolling background and the game windows main panel.  This is programmer art at its best.

I am running into some issues, already.  The scrolling background scrolls without the panel, but with it, it doesn’t.  The reason is because I am using display lists for the background, and simply drawing the panel.  Well, to get the display list to scroll, I translate it’s position each tick.   Well, when you translate, you’re translating the entire screen… I don’t want to do that… I also don’t want to burden the game by redrawing the polys each cycle.  I seen on NeonHelium something regarding creating different ‘viewports.’  I’m sure this could be one way to fix this, but I really don’t want to go that way, yet.  I’ll tinker with it some more.

Here is the first screen shot.

Game Window : Right Click, View Image for a Larger Size

Well, I decided to implement some sort of way for a user to know how they are doing.  So, tonight, I tossed together a way for the player to know.  The point values are not set in stone, yet, but they go as followed:

• You Hit Somebody +100 Points
• You’re on Fire BONUS STREAK 3 +500 Points
• You’re on Fire BONUS STREAK 5 +1000 Points
• You’re on.. Have Mercy… BONUS STREAK 10 +5000 Points (God, help those that play with this person)
• You Get Hit -150 Points (I need to make this a high value, to provoke you to care if you get hit or not)

Of course, play testing with my tester will help round out these numbers.  Here is the score screen, and my lashing that I gave a innocent test dummy.  I want to avoid, at all costs, putting anything UI related on the players screen while they are playing.  This score window is completely voluntary.  If you want to see how things are going, and you’re hiding, while other people are reloading, tap ‘s’ to bring this window up.  Of course, the streak is put on this window so everybody knows who to team up on.  Good luck nailing that 10!

I spent the evening throwing together the user interface.   Everything is there, and the following will likely will not change from where it stands, except for the credit screen.

So, Let’s get a glimpse of how the user progresses toward the actual snowball fight. Now, these transitions actually fade into each other.  If you have seen my prior game, Breakout Returns, then you’ll know how smooth these transitions really are.  If you haven’t, then you’ll get to see on Christmas eve, I hope.

Main Screen

Credit Screen

Server Selection

The only other thing that I might add on the user interface is the character select screen.  Well, more like a jacket color select screen.  But, I’m not sure if I’m going to go through with that.  Other then that, If I actually get the game completely polished before Christmas Eve, I may go through and finish the particle system so I can get some snow going through the menus and into the game.

Oh, yeah, and this project nailed me 100% in my networking class.

I updated a few things on the game tonight.  One of which, is an indicator that signals to the user how many snowballs they have remaining to throw.  How the game works is that a player can only hold a maximum of TWO snowballs, and after they deplete, they must run back over to a snowball mound to pick up another set.  The user will be able to tell how many they have by looking at their cursor.  Right next to the arrow, will be either 1 ball, or 2 balls.

I also integrated a message queue for the network.  This will make sure that all of the requests are actually processed, and that nothing is skipped. It also helps me manage a few other things effectively.  This probably should had gone in way earlier, but I’ll contribute that failure to my newb status.

Let’s see. What else.   Ah, I also have a feedback mechanism now that will trigger when you are hit.

I started working on the user interface for the main menu, credits, and player selection (jacket color).

I also fiddled around and tried to make a particle system.   Mainly for my main menu (snow).

That about wraps up progress for tonight.  I get to take Calix to the vet in an hour to get him Neutered.  Wish him luck, and pray that he doesn’t hate me after taking him there and leaving him.

After doing some optimization on my packets that I send to the client, I decided it was time to put in some more functionality into the game.   I still have further optimization that I can do on those packets, but I figured I’d move on so I could get something else finished before the due date.  I did end up testing it on two different machines, and it ran pretty well.

So, when I developed my Breakout Clone, I wasn’t really concerned with anything but firing up, and if it hit something, bounce off into a direction that seemed logical.  I knew that wouldn’t cut it in this game.  I couldn’t restrict somebody from throwing something left, right, up, or down.  So, after refreshing myself on some trig, I got it to the point where the snowball will be thrown based off of the angle where the user clicked.   It was a lot easier than I was making it out to be, but half the battle is understanding what in the heck you’re doing.

Anyway, I have some pictures.  Of course, I plan on restricting this so one player can’t claim complete and utter domination over another, but I do plan on having it be a bit on the chaotic side. >;o)

And My Favorite…

I also changed the cursor. The prior cursor just wasn’t going to cut it.

Well, I’ve completed my initial ‘base’ task for my networking project. The big concern for the project was to at least have it to where I could have two players running around simultaneously. This, alone, should easily net me an A on the project. There are still people who have yet to start on a final project. Call me an over-achiever, but I enjoy myself some game dev time. >;)

I’ll need to do some testing with somebody to make sure that what I’ve got works well from two different locations. Running it on my poor laptop isn’t netting me the results that I need, and that’s probably because when I fire up the server, I have 2 threads running. Firing up a client, nets 1 thread. Add that with two games, utilizing SDL, and you’ve got yourself a ‘lag fest’ consuming tons of system resources, even over the local host. I’m pretty confident that the code is well enough to maintain a constant stream of data back and forth, without all of this other processes going on, but we’ll see.

Essentially, my logic goes something like this.

I have a ‘PlayerPosPacket’ structure that consists of the x, y, avatarNumber, playerNumber, and the totalPlayers (maintained by the server packet) for each player connected.

With that in hand, I can easily pack up the players data points from the current player objects, send it on to the server, the server can unpack it, re-assign the new values to the objects, repack the new values (catching any updated movements), and send it back to the client with the updated structure. And the process revolves just like that.

I would post code, but the project hasn’t been turned in yet and I don’t want to violate any school rules in the rare case somebody finds this blog. I’ll save ‘code-and-show’ until the end of next week.

After I do some testing, I’ll be sitting down to write down the tasks that I want to complete by Christmas Eve, doing some housekeeping on the code base, and moving on to throwing objects.

Not because I have to, but because I wasn’t feeling tired, so I thought I would spend the night working on my Snowball fight game.  So I picked up some new tracks from iTunes, and went to town.   I want to get this thing working really well for my networking class.  I still have 10 days to finish it, for that deadline.  So, we’ll see how far I get, but there are a few things that I will not even be worrying about until after the deadline.  Modes (yep, modes!), menu screen, user interface, and …. AUDIO… Come one, don’t you want to ping your buddy over the head to the tune of a remixed Jingle Bells?  I think (or hope) I can mix something good together.

I have 2 1/2 weeks until my next semester class begins (Jan 2nd).  So, by Christmas Eve, I hope to have this thing fully decked out for distribution.

I figured I would update the blog with my progress this evening.

Well, my systems were not designed exactly right, particularly how I was dealing with players being introduced to the server and client.  Luckily, it wasn’t bad at all to fix.  I was also having some fun trying to get the client and server to work from the same application, but I eventually got them working.  That was mainly due to downloading boost and needing to get a little familiar with it.  I particular wanted it to use it for Threading.   Right now, I just bump a thread to handle the code that will accept a new connection.

For testing purposes, the server can drop in players, up to 6 (or however many is defined), onto the game map.  Collision detection works fine, the players move around just fine (one at a time), and things look like they’ll work well from a data transmission point of view.

This might look familiar to you, from a few entries ago. But, now we’ve got some multi-colored jackets.

Which makes me wonder if you’re thinking, “Multi-colored jackets? How do we…”

Free for All.

Manipulating the map is simple. I have plans to drop in my Calix Map Editor with the download so the server master can create a custom map, and transmit that new map to the connecting players. So, the mode of gameplay will be: Teams, and Free for All.

But, before all that, I’m going to get back to the code. Next up is to finalize the code for communication between the server and client(s).

In a prior entry, I wrote about a final project for my networking class.  Well, scratch that idea.

I turned the concept into a multiplayer snowball fight.  I figure it would be pretty fun to sling a snowball at your friend for the sake of the holiday season that is fast approaching.   I will be trying to reach a limit of 3 on 3, with anybody over 6 players being in spectator mode, with the ability to join in once a player disconnects.

I redid the artwork and added a few more pieces, finished the input system, and I finished the collision detection system this morning.

Here is an in-progress shot!

Well, up next is some of the networking system. We’ll see how well my systems were designed for a client and server interaction.

Happy Thanksgiving to those who find their way to my website! I hope that you are nice, warm and extremely full from all of the Thanksgiving treats!

I spent the day playing the Wii with nearly everybody, and showing off Super Mario Galaxy to those who hadn’t seen it yet.  Yep, they all had a blast.

I picked up a copy of Introduction to 3D Game Programming with DirectX 9.0c A Shader Approach yesterday. The book has great reviews, and from what I skimmed over, it looks pretty solid. I hope to start on this soon.  I need to brush up on some Math, and finish a networking project.  I actually took a course a few years back, from the author of the book, at gameinstitute.com.  So the book is very progressive, which is nice.

I thought I’d say something about a blog I have been reading recently.

If you’re independent, you should go over and read a blog Brenda Brathwaite has recently started.  She is an industry veteran, in game design, and has a lot of great things to share about her experiences shipping 22 commercial games.  She’s now a professor at Savannah College of Art and Design so she spends time on her blog writing about various things regarding design.   I just noticed she posted something today, what looks to be another good post, regarding interviews and portfolio.

I started to work on my distributed network game a few days ago.  Since then, I’ve basically got the foundation for the graphics system in place, and am now working to get the input system in place 100%.  The input system is about 60% complete, and it shouldn’t take much longer to piece together the rest of it.   After I get all this engine related stuff complete, I’ll start working on the network code.

For the initial phase of the network side of this project I’m aiming pretty low.  I want to avoid writing any sort of GUI elements, and font crap, this early. The server starts automatically when the application starts.  The client automatically connects to the server when the application starts.

My initial milestone is to get basic movement between a server and 2 client.  Hopefully, all 3 will update fairly well by the time I’m done.  I will probably post the executables for you to play with when I’m finished with that aspect.  But I hold no promises.

Here is a very early shot of the initial ‘playground’ that you’ll be playing in.  Click it for a bigger picture, and don’t hate on the art skills.