I’ve started to watch the, not so small, library of UDK video tutorials recently put out by Epic. After watching the Skeletal Mesh pipeline which includes things like character animation, model morphing, skeletal meshes and mirrors, textures, etc. I am beginning to think that procedural synthesis is going to take a rather venerable hold in the industry in the years to come; due to storage or throughput limitations of distribution mediums if nothing else. I for one welcome our new algorithmically generated game asset overlords.
Posts Tagged ‘Game Development’
UDK experience so far
Monday, December 7th, 2009Code Style is not Subjective p.2
Monday, August 10th, 2009Now for a bit about JavaScript and C-style code. First and foremost, if you are unfamiliar or think you are familiar, but really aren’t, (because of say, the welcoming C-style syntax) with JavaScript consider reading JavaScript: The Good Parts. It is a quick, light read that provides invaluable insight into the language. JS is an immensely expressive language but some of the baggage surrounding it can make it seem like little more than a toy language that is intolerable to code in and should generally be avoided at all costs. This simply isn’t true, so go on, have a read.
Update: Indentation and brace style should follow the 1TBS/OTBS style.
When programming in JS always keep in mind that JS doesn’t come with a linker, so everything is put in the global namespace unless you explicitly state not to. All program variables should be kept either within a lambda scope e.g.
(function () {
var a = ‘foo’,
b = function () {…},
c = ‘bar’, …
)());
var a = ‘foo’,
b = function () {…},
c = ‘bar’, …
)());
or within a namespace e.g.
MYPROGRAM = window.MYPROGRAM || {};
MYPROGRAM.a = ‘foo’;
MYPROGRAM.b = function b (…) {…};
MYPROGRAM.c = ‘bar’;
MYPROGRAM.a = ‘foo’;
MYPROGRAM.b = function b (…) {…};
MYPROGRAM.c = ‘bar’;
-or-
MYPROGRAM = window.MYPROGRAM || {
a: ‘foo’,
b: function b (…) {…},
c: ‘bar’
};
a: ‘foo’,
b: function b (…) {…},
c: ‘bar’
};
Also, all variables should be declared with the var keyword, otherwise the JS interpreter will automatically link it to the global object. Further, unlike many other C-style languages JS does not have block scope (neither does PHP for that matter). In languages with block scope it is suggested to not declare variables until they are used. Since both PHP and JS only have functional scope, variables should be declared at the top of the function in which they are used rather than right before they are used.
Since JS provides no linkeranything can overwrite anything else, and no runtime warning or errors are provided when such an event occurs. A lot of code in JS seems to be copied and pasted from elsewhere and this code could very well have strange interactions with your programs if the original author forgot to properly declare a variable or named one of his functions the same as yours. Always encapsulate your program variables and keep them out of the global namespace. When using a namespace, keep the namespace as all caps, this is to differentiate it from other methods or functions.
Generally, when naming function or methods, the name should start with a lower case letter, unless it is a constructor function. If it is a constructor function it should start with an upper case letter. e.g.
function Foo (bar) {
this.hello = function () {
alert(bar);
}
}
this.hello = function () {
alert(bar);
}
}
var myFoo = new Foo("bar");
myFoo.hello(); //"bar"
Since we are primarily dealing with web languages it is best not to mix up code style between different C-style languages such as JS and PHP, as during the course of a day you will most likely be working in many languages. In either language either of the following are acceptable:
if (foo) {
bar;
}
bar;
}
if (foo)
{
bar;
}
if (foo)
bar;
However, the first is the preferred way of writing it. This is due to a limitation in JS. JS implicitly inserts end of statement characters on new lines. So something like:
return
{
foo: ‘bar’
};
{
foo: ‘bar’
};
may look like it is returning a new object with the property foo with the value ‘bar.’ However, it is actually returning undefined and the object literal statement is never reached. What is really meant is:
return {
foo: ‘bar’
};
foo: ‘bar’
};
Moreover, it is very easy to make a mistake such as:
if (foo)
bar();
baz();
bar();
baz();
which was meant to mean:
if (foo) {
bar();
baz();
}
bar();
baz();
}
but really means:
if (foo) {
bar();
}
baz();
bar();
}
baz();
It is preferred that when declaring arrays or objects that their literal forms are used. So instead of:
a = new Object();
b = new Array();
b = new Array();
write:
a = {};
b = [];
b = [];
The use of whitespace is paramount when writing code. It increases legibility significantly. The suggested use of whitespace is as follows:
- Use a space before and after any operator e.g. /, +, *, -, &&, etc.
- Use a space after a function declaration and the beginning and end of the argument definition e.g. function foo (a, b, c) { }. This helps differentiate between a function definition and a function invocation.
- Use a space after semi-colons
When testing for values in JS always use === or !== operators. Their == and != counterparts do not do what you might think they do and should generally be avoided.
If a function requires many arguments consider putting the arguments in an options object and passing the object into the function instead of having a long list of arguments which may or may not be optional. This alleviates the need to have to remember the order of all the arguments and allows for more verbose code, too. For example:
function foo (bar, baz, qoz, …) { … };
foo(1, 2, 3);
foo(1, 2, 3);
can be rewritten as
function foo (args) { … };
foo({
bar: 1,
qoz: 2,
baz: 3
});
foo({
bar: 1,
qoz: 2,
baz: 3
});
More to come later…
Radial Breakout Woes
Sunday, March 15th, 2009For a project in CS U540 I had to create an interactive 2D program that supported a few linear transformation (e.g. scaling, rotation, reflection, etc.). I decided to make a break out type game. However, I didn’t want to create a normal break out clone as that seemed a little boring. In hindsight I should have. Getting the physics right on this game has proven to be quite a challenge. Moreover, I shouldn’t have chosen Java as the language to write it in. I still can’t figure out a way to keep the mouse pointer inside the game window while the game has focus and keeping it cross platform. Below is a screenshot of the game in an early stage:
Radial Breakout Screenshot
Basically I now have several issues:
- The game is a CPU hog. Coding it to use Windows messages will limit it to running on Windows only. Using a Java timer for updates will mess around with the fluidity and essentially keep it being a CPU hog, just one that hogs slightly less often.
- The only way I have found to get the mouse to stay within the game window is to use the Robot class. This unfortunately would fail if I wanted to distribute the game using applets or Java Web Start.
- The hit detection for the paddles isn’t quite where I want it to be.
- The ball movement isn’t quite right either. This stems from the rather messed up deflection algorithm I am using:
- If the ball hits a paddle. Determine the intersection of the ball’s current vector with the tangent line crossing the apex of the paddle. Determine the angle between the normal of the ball’s velocity vector and the intersection. Rotate the ball’s movement vector by this angle. (Currently this is not only slow, but buggy)
- If the ball hits a paddle and after rotation it is still going out of bounds reflect the ball back in bounds. (This should never have to be done.
- If the ball hits a brick swap the movement vectors. Essentially reflecting the ball 90 degrees.
- The ball ends up moving so fast that it becomes very difficult to play.
- If I stuck with my original intention of having the bricks damage, stun, or anything else detrimental to the paddles the game wouldn’t be very fun or playable.
So I’m not really sure what I’m going to do now. I’m thinking of scrapping the project all together as far as its Java implementation goes and starting it back up in C#/XNA. I think having two joysticks to control the paddle(s) rather than a mouse and key modifiers will feel much more natural. Plus it will give me some nice experience with XNA.
For those interested. The Functional Specification and Game Files for the first build of Radial Breakout are available. The jar inside the game files archive is executable and all source code as well as a manual is there as well.