Caaargh Game Development Blog #2

This week has only seen a little time spent on Caaargh, but I’m trying to keep this blog updated, so here goes.

This week I’ve mostly been thinking about the segments of road that make up the race track in the game. To prototype the game and get the development started, I’ve been working with a collection of models bought from the Unity Asset store.

capturea

These got me off to a quick start, but are actually causing some of my biggest gameplay bugs right now and visually I wasn’t totally happy with them.

Visually, I don’t like the fact that the track edges don’t have any depth to them. They end up looking like sheets of paper stuck on the edge of the road. Also, something about the way these were modeled means the road surface and the edge don’t join perfectly so you see a slither of light through the road, and it shows up annoyingly in the shadows these cast onto the ground below. See below.

capture

The road/track shadows might seem like a minor detail given the other major work this game needs, but in Caaargh these shadows are one of the few visual clues that help the player ‘see’ upcoming corners given the deliberately restricted camera view. They also help the player orient themselves in the world after turning many corners. So I decided I needed to fix or replace these track segments because the shadows are important.

From a gameplay point of view, the edges and angles of these tracks were also causing occasional physics based chaos with the car getting stuck, or flipping in ways that weren’t very satisfying for the player. By building new segments myself, I can tweak these until they work just right. Or at least take the blame if they don’t!

Now though, I have a new game design challenge to think about.

The size of these original segments were pretty uniform. E.g. the lengths and widths of each segment were always 16, 32 or 64 units and if they rotate it would be 90 degrees exactly. These could be combined in interesting ways, but essentially created a certain style of track.

E.g. here’s an example when I click the generate random track button…

track

Now that I’m building new segments myself, these can be any size or shape I might want. This could be a good thing, and more interesting segments might lead to more interesting tracks, but it might also be too much. In this game you rarely see the track ahead, and you learn it by failing over and over again. If most of the tracks existence is in the players mind rather than on the screen, simple segments might be the best after all. I don’t know if 29 degree turns are a good idea or not.

capture3

So I’m going to have to test this. I also have to be careful not to the let this opportunity to add more complexity to the game slow down the development overall.

My gut feeling is that the track can be interesting even if the segments are simple, and that that’s more important overall.

capture2

For now though, I’m enjoying this 3D modelling work. 10 years ago, I used to know my way around 3ds Max, but these days Sketchup is doing the job just fine.

Sign-up for my newsletter here.

Loading a new version of jQuery without breaking an old version

Sometimes you’re working on a website that already uses an old version of jQuery and upgrading is not an option at that moment in time; if for example the jQuery library is bundled with a version of Drupal and works with a set of existing plugins.

The following code will allow you to load in a newer version of jQuery and still leave the $ variable assigned to the old version…

The code:

<script type='text/javascript' src='https://www.google.com/jsapi'></script>
<script type='text/javascript'> 
//<![CDATA[
google.load('jquery', '1.7.1'); 
//]]> 
</script>
<script type="text/javascript"> 
// save the new version of jquery to a variable and revert $ to the existing version on the page
var jQuery_1_7_1 = $.noConflict(false); 
</script>

The same code with console logging for testing:

<script type='text/javascript' src='https://www.google.com/jsapi'></script>
<script type='text/javascript'>
// outputs jquery version to Firebug/chrome console to test
console.log("$=" + $().jquery);
//<![CDATA[
google.load('jquery', '1.7.1');
//]]>
</script>
<script type="text/javascript">
console.log("$=" + $().jquery);
// save the new version of jquery to a variable and revert $ to the existing version on the page
var jQuery_1_7_1 = $.noConflict(false);
console.log("$=" + $().jquery);
console.log("jQuery_1_7_1=" + jQuery_1_7_1().jquery);
</script>

After that, you can use jQuery_1_7_1 in place of $ in your newer code.

Hat-tip to the following helpful articles:

Web design in a few years time

Link: Web design in a few years time

The more I learn about CSS3, the less I think that photoshop and the ‘design stage’ of current web design practices will be at all relevant in just a few years time. I think that within a year I’ll have stopped using photoshop on any project I was developing for myself. And for work that other people need to review, new practices will to evolve to cope with that. But it’s enough of a change for me to think that it’s not worth upgrading my own copy of photoshop any more. Design will happen in the browser, and for basic photo adjustments, it’s amazing how much you can achieve with something as simple as picassa.

This change is a challenge to everyone who works in web design and I suspect it will leave a few designers, developers and other webbies in limbo.

P.s. The title (and corresponding link) are not to suggest that CSS3 is not valid right now. Only that working processes will take a little time to catch up with this opportunity.