Frame Rate

So here I am.
It's Saturday, the sun is shinning, there is even a small street parade along the main street outside, and I'm in here working on the game.

It sucks to be them, you know, not working on a game. My current mission is to figure out why our debug frame rate is 10 Frame Per Second (FPS). Debug the solution has become really hard when the frame rate is literally unplayable.

Warning...longish post ahead!!!

In what must be something of a first, I managed to get a blame 3 times in row! It started with memory leaks, followed by a heap corruption, followed by another memory leak just for good measure. All of these I readily uploaded to our repository in good faith whilst proclaiming loudly each time that "...this time it's working, really!...". Thanks to some great debugging team work from Andrew and Josh, the twisty logic that I was working on succumbed to their combined mental might, and the code was uploaded cleanly much to our relief.

Which leads me to conclude that the more well planned a design is, the easier the implementation will be. Now for me, I had previously thought the creation of a game was an almost organic process, with the element of what we call "fun" something that emerges out of playing and tweaking and developing during the writing of the software. However, with a more detailed plan of the logic and complex interactions that I was attempting to code, I might not have spent so long debugging the errors.

What I'm thinking of is, if you take any game, say Monopoly for example, it has a set of clearly defined rules and interactions that dictate exactly what may happen at each step of the game, and clearly specified results. If an interaction occurs in some point of the game that is not specified by the rules, it is then over to the players to work out amongst themselves what outcomes should apply. Generally this is not a desirable thing to occur for a board game, and should be minimised with clearly thought out and detailed rules, but does not necessarily prevent the game from continuing provided the players agree on a compromise and then proceed with the players next turn.

However, what happens with a computer game when something occurs that is outside of the logic that has been written for the game?...Well, one of two things...either the event cannot occur, which is a powerful feature of computer games, automatic enforcement of a gameworld for a player to express themselves in...or, in a more dramatic scenario, the software will simply crash or hang, leaving the game player stuck with no other option but to restart the game, or give up entirely as the prospect of having it crash again may be too discouraging.

So then, to my long beleagured point, it's clear that the details really are the most important thing to pay attention to when designing a game. It may occur to some (such as myself) as killing the creative process by requiring a fixed design from the start. This is not really the case, as there is always scope to make changes if necessary.

The real benefit comes from being able to quickly create the software of a good design, as the logic has already been thought out in advance and the actual implementation becomes trivial. As the development time to get something up and running is now shorter, this allows for more playtesting of the actual game to take place, which in turn allows more time for tweaking and adjusting to balance all the elements into something known as "fun"!

ergo, do not skimp on planning and design!
Paul

p.s. Milestone submission was a day of intense focus and rapid last minute debugging. With plenty of time to spare (30 seconds to be precise) the submission was electronically sent at 4:59pm today and we all left to get some much needed sleep!

Another one bites the dust!

With another week at it's end we are just scrambling to get this milestone built. With the code base for the game growing and growing it takes much longer for the game to compile, every day it is a longer wait to test the game.

Hurry up everyone 5 minutes to go!

Back next week for our Beta build.

Pulling it together

Well, tomorrow is it. Submission of the Alpha build of our game. It's been 4 short weeks since we started production and time seems to be standing still while we work our collective butts off to get this thing finished. I honestly don't know what I'm going to do with myself when this course ends...sleep probably...just need to stay focused for one more day, make sure everything is getting done that needs to get done and we have a playable submission by tomorrow afternoon.

...oh...and then we have one more week to play test and polish the game to get it ready for the Beta...followed by 3 days of final bug-fixing before the Gold release, and then a post-mortem analysis of how we went...

Goodnight for now, and as Ace(Rimmer's alter-ego) said on Red Dwarf, "...smoke me a kipper, I'll be back for breakfast!" ...or perhaps more pertinently..."I am a fish!"

Paul

Its getting closer

We work tirlessly to have somthing worthy to show for our up in coming alpha milestone, its nice to see all the little things coming togther. Lighting effects and flash loading screens. While I know we we all enjoy the day when wethe game meets our highest expectations.

Until then our game doesnt have bugs it just devlops random features.

Crunchy Chickens

So it's the night before the second milestone.

I'm going to have a long night working on collisions. I can only hope that Santa smiles upon me and grants me Uber Leet Programming skills and I get it done in a few hours.

One day

Greetings,

One day away from the Alpha Milestone. Things are getting stressful and thing.

I'm going to sleep now.

getting closer!

We had a lot of seperate bits of code on different team members computers that hadn't been committed to our code base, so part of today was spent updating and committing everyone's code so that we are now all working off the same base code. For some reason, drawing of the bullets disappeared after this process was complete. We've got someone working on that.

Many elements are coming together, and the feature freeze for our code is to take effect tomorrow evening, leaving Friday free for documentation and last minute bug fixes and polish.

cheers,
Paul

Maths

I've been given a lot of maths tasks over the last few days. I don't mind, in fact I love working out all the different ways to do something. The problem arises when the solution you come up with isn't as great as you thought it would be. Just like everything else these days, it always seems to come back to planning.

Tomorrow should be interesting, when I get to see if my logic is either flawed or flawless for our rotating wall. Here's hoping!

"Imagination is more important than knowledge. For knowledge is limited to all we now know and understand, while imagination embraces the entire world, and all there ever will be to know and understand."

- Albert Einstein

Misconfudulation

Greetings,

Communication is key in the games industry. If you can't communicate efficiently and effectively, you put yourself in a very problematic position. Today, I was in that position.

It all started this morning at our round table meeting, when I complained about the fact that I couldn't start the HUD until we had written another piece of code that supports it (a dynamic buffer class). I also mentioned that one of the tasks I was working on yesterday couldn't be completed, due to that same piece of code. In the spirit of team-ship, my colleagues suggested a simple solution to the problem: "do it yourself." :P.

For the next few hours, I set about writing the dynamic buffer class. Little did I know, Nick (who sits directly opposite me) was working on the exact same piece of code...

Damnit.

So basically, I just did a lot of work, for nothing... And we're behind schedule... And now I have to go, because I've got to work on the HUD.

Speed Bumps

Today, apart from the usual revising the schedule and making sure people are on track with their tasks, I've been re-writing a piece of code that creates new objects every single frame of the game. This is a rather time-consuming operation, so I'm adapting so that it takes up considerably less time, hopefully with the effect of gaining a few frames per second on the frame rate. We'll know more tomorrow!

Paul

Ripples

Today I've had one of those days where you are tasked with a whole lot of little things. Each individual task doesn't seem to take long, but the effects stack up into some big results in the game.

One of this small tasks was to implement collision between walls and other objects. The challenge here is that most objects in the game have bounding spheres and radii, however this doesn't seem logical when the walls are more squarish - actually some might be so bold as to say that they are very squarish.

Long story short, I've implemented the functionality. The draw back is that our game is currently running at around 15 frames a second, which means that the collisions checks aren't as accurate as I would like them to be. I hope to go through the code and weed out all the sloppy loops that could be slowing it down.

The wall walker

The game is progressing nicely, but there is still a long way to go in order to get it to an acceptable state for the milestone this week. The player is moving and shooting, we have sound, AI critters, Mini turrets, and the walls are up, though from time to time the player manages to “pass through” a wall. Hmmm…need to think more on this one.

Sound

Hey there,

For the last few days I've been working on implementing the game's sound. The sound is being set up so that if there are two players then there will be two channels of sound. One channel that plays all the sound that player one can hear and one that plays all player two's sound. Hopefully this sounds a good in practice. We should find out on Wednesday when the play testers come in to play our game.

-Nick

Making headway

Hello dear readers,

Many elements of the game are nearing completion and have started being tested in the game. Two players, sounds, shooting, the core time-travel mechanic, path-finding, stationary shooting turrets, ability for the player to place items on the map, a computer controlled enemy, animations for the time-travel/level reset graphics, keyboard/mouse and XBox 360 controller functionality, 3rd person camera with zoom, collision detection, mines, and the famed temporal anchor device have made an appearance in the game engine today. Though some are not quite in their final form of polished gameplay, it's good to see some visible results from our efforts over the past 3 weeks of development.

The plan is to wrap up most core development on the game Wednesday night, leaving us Thursday to iron-out bugs and Friday to tidy up the game, finish documentation and prepare for submission on Friday afternoon.

Onwards Ho!
Paul

Bringing it togther.

And now we have reached that time to start bringing the "succinct units of functionality" together. I always liked that sentence. It pretty much sums up exactly how code should be.
It seems now the fun things are starting to appear in the game. Lots shooting action, 2 players, visual effects, and this strange thing that the camera does that makes it look like you’re going through hyperspace.
As we work harder to reach our milestone this Friday, we are thankful to have tutors on hand as we need them. Without them I don’t know what we’d do.

Seeing Squares and Circles

Today, for me, has been a day of maths. I was given the task of calculating the rotations for our rotating wall taking into account the position of the collision and the direction the collision object was heading. It didn't take me too long to nut out a solution, however I haven't had a chance to test it so fingers crossed.

I also worked on sphere-square collision. My solution to the problem was to calculate the distance from the center of the sphere to the closest point on a line and then subtract off the radius. Yay Science!!

-IOU One Title-

I started off this week by learning how to implement and code threads. Threads are kind of like tiny little sub-programs, which act together to form a larger program. Threads are given their own small amount of processing time, and can even reserve a little bit of memory for themselves too. For example, most games split off a seperate thread for sound/music. This means that if a game is busy loading (or stalling), the music continues, regardless of what's happening with the rest of the game. The same thing happens with MMO games. Have you ever noticed when your internet connection stalls but everything in the game world keeps on rendering? That's because there are separate threads to handle rendering and internet stuff.

This is all well and good, but its a pain in the aft-end to debug. One thread by itself can be a lot of trouble to manage, and up until now, we've never used multiple threads in our projects. Introducing another thread into the mix is going to be like lighting both ends of a firework...

But you never know, it might go off without a bang.

Here are some of the photos from the team.
More to come I am sure!
Keep posting and commenting.
Steph