First Day of Rules of the Game

6:00am - Woke up, as the information from yesterday flooded into my head. I set some water to boil for coffee while I head into the shower. I take my time and let the water drip down on me, brainstorming today's todo. (Create a point distribution spreadsheet, game synopsis, produce a 3D demo of a moveable object, RoG (Rules of the Game)).

6:30 am - I decide to forgo coffee, and instead move onto some cereal. I drop my recording of yesterday's lecture and begin to listen to them while eating.

7:00 am - After running through the syllabus, and reviewing everything from yesterday I begin to recreate the point distribution spread sheet for the team.

8:00 am - I head out to campus for our schedule group meeting.

9:00 am - Seeing a lot of familiar faces in SGP-2 I spend most of the time socializing until Casey shows up, followed by Charlie. We discuss the spread sheet, deciding that we will attempt many at many new boundaries. We intend to implement Shaders (vertex shaders, pixel shaders), particle effects, and even fluid dynamics most likely using D3D terrains. We also work out the game synopsis, thanks to Charlie's great creative writing skill which I will no doubt fall back on in the future.

12:00 pm - We split up and head for lunch, before I do I meet up with Dan who is part of the only group attempting 3D in the month ahead. I try to size up the scope and depth of his project, and it's quite impressive, at the same time I become very excited. After all it is much easier to follow someone's else's footsteps, and hopefully make some new ones along the way.

1:00 pm - ROG begins.
1:15 pm - Apparently this class is being taught by a new instructor, and not Dave the creator of Dungeons and Dragons. I do not mind. Steve VanZandt comes off as well informed, and a well organized instructor. In fact I would go as far as to say that he is a good example of a college level teacher (by normal standards). On that note, when role was called I was rather unoptimistic in saying 'here'. He replied back saying, 'awe you must be the invisible type'. While maybe those weren't his exact words, and they were said in such a way that I may be the only one that heard them. I noticed he did not pay very much attention to me for the duration of the class, except for several glances to make sure I'm paying attention (I'm a little worried about my GPS).
3:00pm - On that note we began lab early, being told that we will continue lecture after lunch break. So based on my first impression to the teacher, or at least my assumption to that impression, I decided to make a point to stand out. I raised my hand several times, and when we broke out in order to play board games ( a supposedly education process ), I choose to persue the simpler board game (Blokus). While it was my first time playing this game, I decided I could do much better in this game compared to the other games which had either intricate rules, or a rather large luck factor. In short, I wanted to win.

5:00pm - By the time lunch time came around we had played five games. My first game, I feel I got rather lucky and made correct decisions. Everyone at the table had been a first timer. I managed to win with 25 points ( a perfect score ). After winning the first game, and also sharing several of strategies, I did not fair nearly as well in the second game and had got -18 still coming in a far second. For the third game I managed to pull a not perfect victory with -7, this time beating our past DirectX teacher Chuck. Chuck is a great guy, and was pretty good at the game, so I really enjoyed it. With each consecutive game, it became harder and harder to win, and the competition became more and more fierce. By this point everyone was keeping track of the number of pieces left over, blocking others, and quickly making aggressive cuts into territory. Being experienced in both spatial tactics of chess, and go I was well aware in the idea of over expanding and being too passive. The fifth game was incredibly dominating. I managed to squeeze off a third of the board to myself, completely blocking any and all crosses using the double eye strategy common in GO. I ended up being able to take all my turns without waiting as no one really could cross into my territory. I won with a -4.

6:00pm - Lunch was brief, ate Chinese, and was pretty relaxing. Spending time not working on the SGP game became incredibly daunting. In fact by this point that's all I could think about. After lunch I spent the time drawing enemies, and thinking of game mechanics. This made the following lecture even more so daunting. I simply was not interested in the fluff. Game Design? Please, that's not what I'm paying the money for, and as shallow as that may sound I can not feel like this is yet another repeat of something I've already experienced, partially or totally. ECG, Behavioral Science, HAM, and the two day GameDesign track at last year's GDC have been plenty. I can make a card board game, all I care about now is how to make it render.

9:27pm - I'm home, I've finished my green tea, and wrapping up this blog post. Going to shower and begin working DXUTMesh which is by no means straight forward. I also intended to write about 3D Fundamentals, but I think I will leave that for a later post.

Oh Man, Best Game Ever

GDC08 First Keynote Announced!

This is big news! As some of you know I will be attending GDC08 this year, this time without a scholarship to lean on, I am more determined than ever to make the most of it. So after I opened my e-mail today I find that they have begun to announce the keynotes. Last year's being Miyamoto, and Phil Harrison; suffice to say that's one tough act to follow. So to my surprise I was too ignorant not to recognize a name as famous as Ray Kurzweil. But after doing minimal research on this man, he has quickly grown on me as an inspirational figure.

Ray Kurzweil has been described as “the restless genius” by the Wall Street Journal, and “the ultimate thinking machine” by Forbes. Inc. magazine ranked him #8 among entrepreneurs in the United States, calling him the “rightful heir to Thomas Edison,” and PBS included Ray as one of 16 “revolutionaries who made America,” along with other inventors of the past two centuries.



As one of the leading inventors of our time, Ray was the principal developer of the first CCD flat-bed scanner, the first omni-font optical character recognition, the first print-to-speech reading machine for the blind, the first text-to-speech synthesizer, the first music synthesizer capable of recreating the grand piano and other orchestral instruments, and the first commercially marketed large-vocabulary speech recognition. Ray’s web site Kurzweil AI.net has over one million readers.

Among Ray’s many honors, he is the recipient of the $500,000 MIT-Lemelson Prize, the world's largest for innovation. In 1999, he received the National Medal of Technology, the nation's highest honor in technology, from President Clinton in a White House ceremony. And in 2002, he was inducted into the National Inventor's Hall of Fame , established by the US Patent Office.

He has received fifteen honorary Doctorates and honors from three U.S. presidents.

Ray has written five books, four of which have been national best sellers. The Age of Spiritual Machines has been translated into 9 languages and was the #1 best selling book on Amazon in science. Ray’s latest book, The Singularity is Near, was a New York Times best seller, and has been the #1 book on Amazon in both science and philosophy.

Yakuza 3 - Oh Snap!

Tooo Cool

You gotta check out this trailer.

Games Noir

A game Noir, as described by Steve Gaynor in the recent publication on Gamasutra, is a B grade game that is budgeted to not be as risky as a triple A title, and yet having enough content and quality to be noticed by the mass consumer. So what does this imply for the Game Design? As the author pointed out, the comparison for a Game Noir does necessarily mean we should mimic the style of a film Noir, which after all is not an interactive form of media, and while a strong story is one way to sell a B budget game, it is not the only. Steve suggests experimentation in game play, and several of the earlier comments below the article mention games like Portal. While a game like Portal would certainly classify, it got me wondering what kind of games could I come up with under such limitations. So this is what I came up with, and while keeping such innovative ideas a secret did cross my mind, I also think it will be a few years before I'm in any position to make them, at which point they will no longer be as innovative, and their will be new technology, and a new ideas to draw from.

Title: Water
Concept: There are very few games that truly explore the water world, and the fun possibilities that lie with it. Most water based games fall into the category of races, which while it may be fun, is no different than racing on sand, in space, or on dirt. No this game should put the player in a position where water is used as underlying game play mechanic.
Gameplay: So imagine for instant that you play a silver surfer type of character, who can generate generate waves that can be used as weapons, or ramps for other players. Imagine a form of capture the flag in this style of gameplay, or football-isc rules. As long as the development is constantly thinking about how to make water more and more fun, and not throwing in any half-baked side elements this would be a truly fun game to play.
Story: This really wasn't about Story, but I believe unless the game is built as a multiplayer only title such as Warhawk, than a story should have as much care as the game play. There is nothing worse than progressing, through a game without a feeling of discovery. I believe that's what a good story does for simple games such as this. So, if it were entirely up to me, I would have this game be a growing up tale, about a boy who goes onto compete in a large arena. Imagine any story about a professional athlete being told from his child hood and eventually taking him to the Majors.

Title: Kendo with a Paintbrush
Concept: Painting has been demonstrated as a feasible game mechanic by Okami. In fact it was incredibly well executed, but than that was it. Is it that we as an industry are too afraid to draw from the same because we would be copying? Or are we too short sighted at other alternatives to painting in a video game. In fact by only utilizing the freeze time + analog sticks paint mechanic and drawing not a single thing more from the game Okami, some truly original ideas begin to come to mind, and playing Kendo is just but one of them. Kendo is about reading an opponent's next move, sort of like chess, it is about looking for patterns, and being creative.
Gameplay: Your weapon is a brush and your face to face against an imminent threat. As mentioned earlier, I see nothing wrong with using the time manipulating game mechanic from Okami. But to make things a bit more interesting, you can only paint within a much smaller radius of your brush, and when you choose to paint you can only slow time down, you don't freeze time. This will allow for your opponent to react but in a much slower fashion. Imagine now the sort of effect that would follow such slow motion sequences that would be exchanged between each player or computer player. Player one begins to draw a projectile circle (keeping in mind that this uses a lot more paint and the circle must be completely closed), he aims for the head. Player two, noticing the shape, steps to the side, and while watching his own avatar slowly begin to move, he begins to draw his own attack. Blocks, Strikes, Parries, fencing or Kendo this is the core of the game play.
Story: Hmm, well could we do something similar to the above? Yea sure, it would work, but for the sake of being original and daring as a Noir title should be. Let us take on the role of a girl. Why a girl? Because Kendo would be out of place for a girl, that statement in itself not being entirely accurate, that is half the reason. The other half of the reason is it can be quite interesting for boys playing this game who may or may not yet understand girls or woman for that matter and have the story be told about a serious issue from her point of view. For example, how time keeps passing her buy, and she's getting older and older and still not sure of what to do with her future. Will she practice Paintbrush Kendo for the rest of her life? That can't possibly be it, but yet her grades limit her options. It could be a story about her pursuing a meaningful life, and overcoming challanges. The use of a girl as a main character is in fact completely irrelevant towards how the story would unfold, unless there is a hint of romance involved in which case boys and girls act differently.

Anyways, I feel that from this little exercise I've learned two things about making a great Noir game. Focus on only one key gameplay mechanic, than focus even more on the story. Keep things from being repetitive buy using the gameplay as a reward, rather than the other way around.

Hope you liked these ideas, and will inspire who ever you are to come up with some of your own. Oh and if your a famous game designer yourself, with some hiring power, I got a lot more haha : )

DXUT Game Architecture Part One

Understanding *.VSPROJ

I’m of course referring to a standard Visual Studio Project. In order to understand DXUT and for that any API integration, it is quite vital to understand project dependencies and settings. So this first tutorial will focus on just that with emphasis on DXUT project settings.

On quick thing to make a note of is that a visual studio project are the multiple project builds. Most books on this topic already assume you understand this, but for those with less experience in this area due to one reason or another I’ll quickly explain this concept.

A project build are unique project settings often to do with the compiler, and the linker. The most common three types of builds are the Debug, Release, and the Profile build.

The Debug build is usually the configuration you use while trying to test, solve problems, or quite simply debug. This includes enabling things like symbolic debug information, and disabling any form of code optimization such as inline functions for example.

The release build is by far the easiest one to understand because it is what you’ll be providing the end user with. With that being said you want to omit any unnecessary debug information, and include any form of code optimization.

The debug and release builds are what is defaulted during development using Visual Studio. You will then be expected to make any additional builds on your own (doing so is easy, just do some research). The question would than arise, as to what the purpose of these extra builds might be, and this is what I believe a Profile build that is often regarded as in programming books. The profile build or whatever you choose to call it, may be a build specifically designed to run a specific piece of hardware; such as a cell phone, a PlayStation, a different operating system, or it may quite simply act as a midpoint between a Debug and a Release build for testers etc. As long as you understand this, than choosing the appropriate settings for a Profile build or choosing to omit it entirely becomes a simple mater.

Now that’s out of the way, in Visual Studio switching configurations is as simple as choosing one from the drop down list above. Make sure to note the “All Configurations” option which will allow you to make consistent changes to all current builds.

Next you must decide on how you wish for your project to be organized. There is nothing wrong with using the default directory structure that Visual Studio sets up for you, but after reading Mike McShaffry’s Game Coding Complete, I feel in love with his design which you can find on page 93 of his publication. This is roughly what it looks like:

• Project Code Name
  • Docs
    • Documentation, game concepts, etc.
  • Media
  • Folder belongs to the artists, raw .psd, and high res textures
  • Source
  • The source code, .sln and .vproj belong here
  • Obj
  • The junk, SCC, OBJ, SBR, ILK, and PCH files.
  • Deleting the contents of this folder will cause a complete rebuild
  • Bin
  • Game files only.
  • Executables
  • Zipping up this folder should contain everything necessary to play your game.
  • Test
    • Debug and Profile targets of the game, and any utilities useful for the test team.

[Configuration Properties]

[General]

• Output Directory, your output directory is where you can expect to find your .exe
• Intermediate Directory, compiler specific files, this should probably be configured to point inside your Obj folder if you choose to follow the advised dir structure.
• Extensions to Delete on Clean, during the rebuild step the following are the file extensions you would like to be deleted. If you’re confident in what you’re doing this is a great opportunity to delete unwanted logs etc…
• Build Log File, I have never utilized the following log file, but it should be clear as to what to expect here.
• Inherited Project Property Sheets, this is important if you are setting up your project from an empty project with absolutely no defaulted settings. Feel free to read more on this topic if you wish, but for a DXUT project set it to
• $(VCInstallDir)VCProjectDefaults\UpgradeFromVC71.vsprops
• Configuration Type, the following drop down list determines exactly what your project is built to do. If your building an application (*.exe), a static library(*.lib), a dynamic library (*.dll).
• Use of MFC, set the following to Use Standard Windows Libraries
• Use of ATL, set the following to Not Using ATL
• Minimize CRT Use in ATL, think about this for a sec. Are we using ATL? Then set this to No.
• Character Set, DXUT is infamous to using Unicode and not Multibyte which is more common to hand written DirectX. Remember a character set is not something that can’t be changed if you wish by using prefixes such as L, or T.
• Common Language Runtime support, No Common Language Runtime support.
• Whole Program Optimization, No Whole Program Optimization. Remember what we discussed earlier with various build types.

I’ve went into a lot of detail when it comes to General Configuration, from here on out I will not spend the time to explain settings that are build specific, or that have nothing to do with enabling DXUT. Remember that it is important to learn how to do your research here, and I believe I’ve provided you with the stepping stones to do so.

After creating your project and going through the steps of configuring your $(IntDir), $(OutDir), and various build options you should install the latest DirectX Distribution. Each distribution should come with the latest DXUT files usually located in (C:\Program Files\Microsoft DirectX SDK (November 2007)\Samples\C++\DXUT). A good way to find it is to perform a search for dxut.h on your entire computer. Eventually you will two folders, [Core] and [Optional]. What is this you might be wondering? The core folder is where you’ll find dxut.h and other essential header files involved with successfully compiling DXUT code. In other words you’ll defiantly need these files. On the other hand Optional contains the majority of the DirectX wrappers for game development. Please be aware that DXUT does not document the optional wrappers and is not truly part of the API but are provided as sample code for producing your own wrappers to do the same. With that being said, I don’t copy both folders directly, but instead make a new folder in my project source directory called DXUT and paste the appropriate header and cpp files.

Now you’re going to want to right click on your project and add existing files that you just copied into your project. Second, you want to go back into Project Properties and navigate to Configuration Properties -> C/C++ -> Additional Include Directories. Than point once again to the DXUT folder w/ respect to your *.vsproj file. Assuming it is inside your Source folder, simply typing in DXUT; is sufficient.

* If you don’t see the C/C++ tab inside your Configuration File it is most likely due to the fact that Visual Studio has not yet identified your project as a C++ project. To do this simply create a .cpp file such as WinMain.cpp. And open up properties again.

This concludes Part 1 of the tutorial. If you would like to continue without waiting for my next update, feel free to purchase Game Coding Complete or you could simply navigate to Mike McShaffry’s forums at http://www.mcshaffry.com/GameCode/board.php. Something to note about the way Mike sets up his DXUT is by building a separate project with its own precompiled header, and outputting a *.lib. He then sets up his next project that being the Game Architecture project and set’s it to be dependent on the DXUT build. He also does his #include for DXUT files inside his Game Architecture project and not the DXUT project. Hopefully you’ll figure it out. Or feel free to wait for my next update where I’ll try to take this tutorial all the way to rendering a blue screen via the DXUT function calls.