- Demo coming November 2oth, 2009 -

Now, the reason that we did not have a meeting last week is pretty crazy. 2 weeks ago, a Microsoft representative came to our school looking for members from our club to join in Imagine Cup. For those of you who have not heard about Imagine Cup, it is an annual Microsoft competition designed for software engineers to compete in create software that helps the world in some way. This year, a few of our club members are taking part in this year’s Game Design competition to develop an XNA game in pretty much 6 weeks. The team is as follows:

Bryan Carter, Michelle O’Donnel, Myself (Koray Hagen), and David Young.

Frankly, we needed last Tuesday to work on the game, and it is definitely progressing nicely. In fact this Thursday we will be talking about game engines, and part of that will include how our team is going about building an entire XNA 2D engine in 2-3 weeks. If you guys have more questions about Imagine Cup, please ask them on Thursday or email us at cppgamedesign@gmail.com, or comment below!

The Cal State Fullerton Video Game Design Club has somehow managed to get Jim Rivers from Obsidian Entertainment (Hiring manager at the company), to come give a presentation in the Titan Theater of Cal State Fullerton from 5PM to whenever. This is an incredible opportunity to come get industry information from a man that David, John, and I met at last year’s Game Developer’s Conference. If you are interested in going to this event, please comment below this post and perhaps we can form a group together to go (I’m sure as hell going).

And now, for the list of discussion topics for the 2009 – 2010 school year:

Programming

• Game Engine Architecture
  • Abstraction
  • State machines
  • Audio
  • Physics
  • Mathematics
  • Graphics
  • Networking
  • Timing
• API’s / Framworks / Languages
  • Lua, C++, C#, XML, ActionScript
  • XNA
  • DirectX
  • OpenGL
  • OpenAL
• Engine Case Studies
• Hardware limitations

Art

• Interface Design
• Conceptual Art
• Character Modeling
• Animation
• Background Modeling
• Textures
• Software Limitations
• Music and sound effects

Production

• Marketing
• Competitive Analysis
• Roles in the industry
• Scheduling
• Software Engineering Practices
• Franchises, Licenses, Brands

Design

• Story Telling in Games
• Character / Weapon Design
• Genre Analysis
  • Strategy
  • Shooters
  • Role-playing Games
  • Massively Multiplayer Online Games
  • Action
  • Stealth
  • Adventure
  • Casual
• Hybrid Genres
• Level Design
• Game-play Systems
• The fun factor
• Puzzle Design

Breaking In

• Resume writing
• Portfolio analysis
• Networking with developers
• Conferences and local meetings

Other

• Game Developer’s Conference Recap
• CS499 student projects
• Industry / faculty guest speakers

Lastly, our first meeting of the year will take place not this Thursday but the next. Expect to see an official announcement and fliers around school sometime near the end of next week. We hope to see many of you on October 1st at Cal State Fullerton, as well as in 2 weeks for our next meeting.

I’d like to take this moment to announce a shout out to a couple of our members. First on the list is Philip Garabedian, a Graphic Design major who has been helping the club out with his artistic talents. Philip has been designing a great template for our fliers, which you will be seeing around campus shortly. He has devoted a good chunk of his time for free just to help us art-handicapped people out. Thank you very much Philip for devoting so much time to the project — it is well appreciated (plus, it just looks damn cool). Our next shout out is to Robert Muller, who will not be joining us this year for our weekly meetings. Robert is a good friend of mine — who helped on our CS499 project PHASE — and he will be out for the majority of this year doing an internship up in northern California. On that same note, Robert will also be contributing to our blog and resources section with updates from his new work, as well adding more tutorials in the Resources section of our website.

Now for some general updates. Along with Robert’s work, other members will be contributing to the resources section as well. We are looking to really bolster the tutorials section with some useful information; however some of the tutorials will be specific in nature. A good example of this is a new upcoming tutorial on writing games for the Zune HD using Microsoft’s XNA framework. We’re also hoping to get some non-programming tutorials up as well. On that note, you are probably starting to notices a general trend — we are severely lacking in writers / presenters / members with non-programming ability regarding game development. If anybody is interested in helping us out with this, please drop us a line on the subject. This includes topics such as modeling, animation, level design, and other things of that nature — you get the point.

There are a few thing to keep in mind event-wise as well for the upcoming year. If you are interested in making a game in a team setting, myself and David Young are going to be taking CS499 during Spring Quarter 2010, and we would highly recommend you taking it as well. Dr. Kerbs runs a very free and fun class, and it is definitely a learning experience creating a game from literally nothing. Our primary advice is to make sure that you are ready for it skillfully and time wise. Dr. Kerbs does not teach in this class, and you are expected to learn everything on your own. Everything. Heed that word. A few of us are also planning to attend the Game Developers Conference this year as well. More details on that later, but basically it’s a great 2 day trip up to San Francisco, filled with games, booze, talking about games, and praying someone will take your resume seriously. Take a look at our photos from last year!

Two final things. Promise. Dr. Craig Rich (our new adviser) is helping us get onto Science Council for this year. What does this mean? Money. What does that mean? Partially paid travel expenses to GDC in March. The details have not been ironed out yet, but this is definitely something that is going to happen. Our site’s forums are working too, so if you have something you would like to discuss, posting topics and replies no longer takes you to a blank page.

Thanks for reading the wall of text guys, next update will probably be centered around a specific list of topics/presentations for the year. And of course, any questions or comments can be directed to our email at cppgamedesign@gmail.com.

To start, some definitions:

High Resolution: this means that small increments of time can be discerned. Usually in games this means around the tens of milliseconds to nanoseconds range when talking about video games.

Low Resolution: this means that only large increments of time can be measured. Anything above one second (minutes, hours, months, years, centuries… etc.) is considered low resolution for a video game

Refresh rate: how many times a monitor or LCD is refreshed. Almost certainly going to be between 60 -85 Hz (60- 85 times a second).

Frame rate: how many times the image for the game is changed. Your screen will always be refreshed 60 times a second but if your game takes half a second (0.5 seconds) to compute player positions, collision,  awesome particle effects, and then display the changes; your frame rate is going to be 2 (the screen will be refreshed 30 times with the same image because your game hasn’t gotten around to changing the memory where your video is stored but spent time doing other game logic stuff).

Game-Speed / Time Step: Game speed is totally different concept than fps or refresh although they can be dependant on one another. A constant game-speed is desired for anyone who plays your video game so that you can design a fair game with predictable results.  All the concepts presented here are basically to achieve a constant rate for gameplay despite varying cpu and fps changes. A time step is just the time that goes by in any simulation – Sometimes there are multiple time steps that happen in a frame to increase the accuracy of the simulation

Ok, hopefully you understand most of that. Next, here is a brief explanation of the three main timing techniques used for games

Technique #1 –  Non-Stop Game-Loop with loop delays

This is by far the most used way to time video games on older generation video game consoles and computers – DON’T DO IT!!!. Rendering the graphics and doing game logic were developed with particular machines with a particular cpu speed and with the expectation that the video game will not have full control of all computing resources and will not share it.

while(!ending)
{
    runGame(); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
}
void runGame()
{
    float unit = 4.5;
    xTransformSprite(unit);
}

In the main game-loop, which is running constantly, a tiny loop that does nothing inside of it but waste time by counting to some constant, is tweaked by the programmer (sometimes user defined) and is used to delay for a certain period until the program updates at the desired frame rate.

As you can see, downsides to this approach include a barrier of putting hard-coded values in your code, that when your program take longer than you anticipated for the game-loop, all those values have to be accommodated for a slower frame rate.

Technique #2 – Callbacks and Interrupts

This process is actually still very common and is very similar to the previous technique except for 2 small differences. The first is that instead of using a loop, it requests the Operating System to wait for a specified period of time and then come back. The other difference and advantage is that this gives other programs a chance to run.

a call-back for a game loop might look something like this using Allegro

while(!ending)
{
    runGame(); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
    rest(50); // tells the system to take back control and return in 50 milliseconds
}
void runGame()
{
    float unit = 4.5;
    xTransformSprite(unit);
}

For handheld systems, hardware interrupts are a way of performing this exact task they are similar to callbacks except they are a very reliable way of timing your game. On the Game boy advance, for example, all the game logic and drawing has to be done in between the screen refresh, and it is called from the beginning every time the screen is rendered. On the GBA the screen Refresh, FPS and Game-loop are all synchronized. As long as you have complete control of the hardware as in the case of the GBA, this method is a very suitable way to time your game. Even If you don’t have control over the hardware, no-one will probably get on your case if you stick with this method if your game is fairly simple.

Technique #3 – Delta Time

This is where things start to get hairy. Depending on the language you use and the OS, getting current system time at a high resolution can be very different. One way to solve this is to use a High Resolution Timer Library where someone has done all the hard work.

The basic idea is that all systems are generally guaranteed to provide accurate time up to the second but no more. Access to the OS’s API probably reveals functions that aren’t very friendly to timing your games in tenths or hundredths of a second but probably in “Clock Ticks”,  and may even provide a clock ticks per second function. Although the thought of learning windows programming may be strike fear in the novice programmer, like I said before, there are other options: Java and C# have pretty good timer functions. For C++, there are many game and general utility libraries also provide a high-resolution timer function that is easy to use in game. The following is usually how it’s done if you get your time in milliseconds -

int last = System.getTimeMillisecond(); //our timing library function in milliseconds
int current = last;
while(!ending)
{
    runGame(current – last); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
    last = current;
    current = System.getTimeMillisecond();
}
void runGame(int delta)
{
    float secondsSinceLastFrame = delta / 1000.0;
    float unit = 4.5;
    xTransformSpriteUnitsPerSecond(unit *secondsSinceLastFrame);
}

And that’s it! I think Koray has done some Windows API timing so well see if that stuff makes it in here.

This is just a rough draft so please email me of missing/wrong information or what you would want in simulations 102 (particles anyone?).

http://gamedeveloper.texterity.com/gamedeveloper/2009fall/

First off, I have added an embedded forum into the site. There are still a few glitches with posting topics, but I will be continuing to update it as needed. If it looks simple, that’s because it’s meant to be. And yes, posting does require registering with the site. In any case, feel free to talk about whatever you wish — we don’t mind language, and please, think before you post.

Secondly, I’m sure many of you are wondering what exactly we do in GDAC during the school year. In a nutshell, every week we will take you through the development process of a game. Each of those weeks we will switch between doing a technical and non-technical topic for the hour that we have. For example, one week we may do a case-study on Half Life from a designer and artistic standpoint, and in the next week we will do an introduction to Lua scripting. Granted some of the technical topics will be math and code heavy — if we say we’re going to do a 3 week presentation on 3D game engine architecture, you can expect to see an amazing amount of C++ and matrix math / trigonometry. Please do not let this deter you from joining us on those days however. We do not tip toe around topics in GDAC, we take them directly on and it is the best way to learn the hard stuff.

And lastly, we will be adding many more new resources to the site as time progresses. This will include more tool / engine reviews by our team, book reviews, more tutorials, and even the possibility of more video-based content like on our PHASE page. We intend to make this site a true hub for all things game development. If you have a feature that you would like to suggest, please feel free to tell us below or email us at cppgamedesign@gmail.

I can tell you right now that this is going to be a very fun school year. Last year the club was really just an experiment to gauge and see what people did and did not want. Now that we’ve gotten a large amount of feedback over that period, it’s time to take GDAC to the next level. Join us this upcoming Fall as we delve into the greatest entertainment medium of our generation.

The entire game, from design to  artwork to implementation of the game was done withing the 72 hour period. It features push/pop game-states, particles, sound, graphics and implements constant time! At the start of the contest the following set of requirements were generated:

It was tough, but a lot of fun and a great learning experience! Speedhacks are a great way to learn how games work and gave me the motivation to keep pursuing game programming. Just do it!