Saturday, September 30, 2006

The FlashRacer Boys Are Back In Town!

Greetings, to all who still have our blog on their RSS feeds after all this time of inactivity.

Obviously the flashracer project has been in a bit of a hiatus these past few months, due to both Tom and I starting new work commitments. For me personally, finding the motivation to work on a programming project after working all day on the computer too has been difficult, but I'm getting used to it.

Anyway, this is a development blog after all, so on to the flashracer news. The major point we would like to announce is a slight change in the direction of flashracer. Since the beginning it was our goal to create a relatively realistic game. The physics system alone should be evident that when we say real, we mean it! However, when translated to the actual game--the design of the tracks especially--it hasn't really worked the way we wanted it to. Having our tracks realistic too turns out to be boring to race on. The straights last too long with nothing to do, and there's not much opportunity to really show off the physics system. This last one is especially disappointing considering the time spent on it!

Something had to change. But change is good, especially since it has enabled us to generate more motivation for ourselves to finish this project. Even though we put in the work at the very beginning to create design documents to help us coordinate our efforts, it doesn't mean that those documents are rigid. All game programmer enthusiasts know that it is a big step between making a game and actually finishing a game, but is it worth putting huge effort into finishing a game that turns out to be boring? Nope. I could go on and on about how design documents should be liquid and change with the project as the project changes, but I'd just be repeating what others have already said and have said better. Instead I'll do what blogs were meant to do, and link to another great post called "You can't design fun on paper" over at the Rampant Games blog, which discusses similar ideas.

The required changes we've decided on, which we hope will help to make flashracer better, is to focus less on realistic tracks. The game will be more of a "rally" style game, with tracks having much more twists and obstacles, and possibly multiple paths per lap (although that last one might cause problems with the AI, as you can imagine!) The controls and "feel" of the cars right now have rally cars similarities anyway, so there's not even much to change on that part. Tom and I feel that a more rally-oriented gameplay will suit flashracer better. Having more interesting tracks will remove those boring long straights, and allow much more "fighting" with the AI to get past them, which should show off the physics more.

The way we're approaching this change is going to be slightly more transparent. We each have goals on our to-do lists appropriate to our skills. I'm continuing with constructing a solid wall system to add more fun to the game; Tom is improving the pseudo-3D structures to add more visual elements. What we're trying to do is break down each thing we have left before we consider the game "done" and estimating how long each thing will take. Hopefully within the next week we'll get together and come up with a realistic date/timeline for a proper "alpha" version. We'll publicly release the date on here so that hopefully, if we're not on target, people will start bugging us. All this is supposed to keep us motivated to finish what we started, since we've really not got that much left on the to-do list. But having targets and meeting them--with people knowing that we've done them and hopefully spurring us along--all helps to reminds us that even though our project has loomed on for much longer than we anticipated, it is still moving forward.

That's it for now. I hope some people are still reading this and are interested in the flashracer project. I hope also that there are other amateur game designers out there learning from our problems!

Friday, June 02, 2006

Hacking By Design

Don't you just wish you could learn without all those mistakes? Such is life...

This week I've been fleshing out the Game Modes we're going to have, after I started on the structure of the Game Mode model (see my last entry.) Unfortunately in doing so I've unconvered a few fundamental design flaws in the way we have written our Race Manager for FlashRacer. It hit me when I came to write our Time Trial Mode, where there will be no AI cars, just the player screaming round the track trying to beat his best lap time. We were pretty smug about ourselves and thought we'd got it right in the way we save all our data in separate XML files; one for individual track data, one for ordering the tracks into various race series. Things like championship mode will use a series to know what order to race the tracks in, etc. Unfortunately our Race Manager assumes that everything will be in some sort of series. Time Trial should let you choose whatever track you want. Race Manager should have been independent of race series! (*sigh*)

So... we can either re-write Race Manager to be series independent, and only load a given map. Lots of work. Or, we can leave it how it is and hack around it. Erm... yeah, we made an executive decision and took the later option! :) Doesn't mean we won't learn from it though, now we know that taking the time to think these things through before we start coding will be quicker in the long run. Race Manager can be designed and refactored accordingly in any upgraded version/sequel. For now though, we're going to create a fake series which holds all the tracks for things like Time Trial and Single Race Modes, and hack to disable AI for single car races. I love the smell of hack in the morning!

The finishing of all these Game Modes will be done a little later; Game Modes unify lots of things under one controller, and I've got to the point where some of those things are not implemented yet! So, I'm going to move to the next on my TODO list -- immovable collisions. Pretty soon we will finally have race track boundary walls and those 3D objects will be solid too. Expect to be smashing into tyre walls and bouncing all over the place in the next release!

We've a few other big changes and ideas that will be filling the next few blogs. The menu system will most probably be simplified - there are a few too many limitations in our current XML version. Some pretty sweet ideas Tom and I have had about upgrading the AI thanks to the new waylines Tom has done will be discussed also.

Hyperplanes, Normals & Vectors

Lot's of work over this week including a major overhaul of the waypoints system which was far from ideal. Previously the vehicles aimed for specific points on the track, a distance check was then used to decide whether the car had reached the waypoint - this resulted in a circular detection area.

The major drawbacks of this approach are that if you drive off the track you can completly miss a waypoint without realising and the lap wont be counted, ai cars all aim for the same point which results in them driving in a line on the same route and the start finish line is actually a circle! The solution has been to replace points with lines, the ai can then pick different points on the line to aim for resulting in a more unpredictable race. It is also possible to find if a waypoint has been passed by calculating the normal of the line and projecting the distance from the car to the line onto that - if the number is below zero then the line has been passed. For this Metanet has been a great help as always! The other great thing about this method is that the line never has to be phyisically touched as it is calculated as if the line continutes into infinity in both directions...

I have also integrated waypoint editing / saving / loading into the track editor. The ends of lines can be dragged to move the waypoint and the red arrow signifies direction. (The track is displayed half size in the editor)

I think once the AI cars are more aware of the other vehicles around them this will provide a really good level of challange, at the moment they like to cross each others paths too often, which results in cars scraping along next to each other...

Friday, April 28, 2006


Hey all,

After two months with no update from me and Jon i thought it worth posting what has been going on. I would love to say that we've both been working on the game so hard there has simply been no time.. however, this is not the case!

We have both been busy with other commitments, at my end this has been coursework and exams which will be ongoing for a few more weeks yet. After that i start a new job, which for the project is actually a good thing as i will have time in the evenings to work on the game instead of coursework and revision.

Hopefully, the next post will be sooner rather than later!


Tuesday, February 28, 2006

Building Our Way To Amarillo

Hey there bloggers! ( Can you guess what I watch on Sunday nights on E4? )

There's been a bit of a lull in the development this past few weeks, but I do have some things to inform you of to fill the gaps. I've been revamping our Track Editor as I said I would, filling it to spilling point full of sexy edity type features. The multi-tile copy-paste is working nicely now. Tiles can be fully edited with selectable textures, and hitTest ( tile shape ) information is selected with a two key combination. Think of the square made on your keyboard with corners at 1, 4, Z and V and the perimeter keys are the start and end points of the tile shape. The other feature added to the Editor is basic 3D editing ready for when Tom has added that to the race engine. At the moment this is achieved with an extra 2D tile layer, so it keeps the editor nice and simple to work with, without cluttering it up with full 3D information.

The last two things that we need to add to a map are the waypoints for AI cars and the grid positions. I've been putting this off for a week now, because this type of data is independent of tile data. I'm starting to think that a different edit mode would be too much hassle to add into the Editor, since we could just drive round in the map in the proper game engine and add waypoints as we go around ( which is the way we did before ). Grid positions also are not so amazingly complicated that they can't be added in by hand too. I know it's not the best solution, but it makes sense in the long run - we have an editor that can do the most complicated parts well enough now, that's the main thing.

Thought Crime

It's this stage of programming a game to which I admit I am new too. Many games made, especially by the hobbyist game programmer, are designed to play all the way through linearly. Start to throw in multiple game modes and there is now the new problem that the engine you already have needs to be enhanced to accommodate this dynamic use. So I've started thinking seriously about the way to make different game modes. The way I think we will need to do this here is to build a new "engine" around the old one; We have a race engine, but not a game engine. I haven't started to implement anything yet, but here's my best idea so far:

We can't do ( OOP ) interfaces in AS 1.0, so it'll have to be a super-class workaround, but the idea is to have a GameMode class that defines a set of events. These will be called such things like onLapComplete, onRaceComplete, etc, and each game mode will implement these events differently. For example, a time trial game will check after each lap if your best time has been beaten and keep on going, whereas a normal race will check if you've just completed the last lap, and so on. More importantly, at the end of each race, something different needs to happen. At the end of a time-trial you would go back to the menu where you can choose what track to race around, but at the end of a race in a championship, the menu needs to know what race will be next. I think that this events system will be able to give us everything we want to achieve for the alpha demo in terms of how the game can be played.

Wednesday, February 22, 2006

Through the keyhole

What kind of person would code in a place like this? A little insight into our work holes, where we spend hours perfecting blog posts like this for you guys and then a couple of minutes on the game ;-)


Monday, February 06, 2006

Solid Geometry


Since the demo i have been working hard on ironing out the little issues we had left and adding some new 3D features into the engine.

I thought i would write my first indepth post on the technology behind the game, and explain how we are achieving 3d objects while maintaining (hopefully!) high frame rates. I am using a technique that was explained to me by kirill mourzenko several years ago, and i used a less advanced version in my earlier (unfinished) game Felony (on which Jon helped with the physics, and is actually how we hooked up for this game!)

Faking It

The 3d objects in Flash Racer are faked through a combination of clever scaling, animation and paralax scrolling. Firstly, for each object the distance is found between it and the center of the screen. For buildings, this distance is then used to offset the roof by an amount depending on the buildings height. So, as the building moves further from the center of the screen the roof becomes more offset, this creates the impression of perspective.

See how the building to the left appears to be leaning more? Of course for taller buildings this effect is even more dramatically increased. The roof of the building is also scaled up according to its height as objects closer to the camera should appear bigger!

The walls are wedge shaped images that are simply scaled to fit between the base of the building and the side of the roof, at the moment this calculation is performed every frame in the Camera Class, however this could be reduced for lower spec machines and i am looking into making this one of the many graphics options we are likly to include!

The final piece of the puzzle is to skew the wall image so that it fits when the roof is no longer above the building base. This is predone animation, with one keyframe for every single pixel of movement (81 keyframes in total), this is a very efficient way of achieveing the right look.

On a side note, i have noticed that you can now dynamically skew images in flash 8, this would have been ideal for this, however we are currently coding for flash player 6 in AS1 so it would be unreasonable to code only one feature in the brand new flash player! Maybe in a future version?

Pseudo Speed

These tall objects are great, because they add that extra level of depth to the game and just as importantly - because they are closer to the camera, they move faster and dramatically increase the feel of speed when racing! All we need now is a little blurring...

Any questions? Just leave a comment! Extra points if you can work out the cryptic title ;-)

Thursday, February 02, 2006

Tech Demo Success

A big thankyou to everyone who played and gave feedback on our first playable demo, released last week. It was very satisfying indeed to see so many people with an interest in our game.

All feedback is good feedback

The feedback we received via the flashkit thread showed that our fear that the game might not run at a playable speed for slower CPU's was thankfully misguided! There were times during the development process prior to release where the frames per second were into single digits, but even the slower processors tested by flashkit memebers were all above 20 fps. You can't win everything though! The game may have coped running at fast enough fps, but many people felt that the cars did not go fast enough. This is something we will be taking into consideration for the next release. Although it must be considered that the track is lacking in detail, which can only help in delivering more sense of speed, cars will become faster. We hope to eventually have multiple cars with differing properties, so the cars in the tech demo will most likely be the `slow' cars you can get at the start of the game. All games must prove a challenge and a reward for completion of the challenge, so winning races should eventually gain players access to the faster cars.

What are we going to do next?

"Whatever we feel like of course! Gosh!" ( Sorry, I've watched Napoleon Dynamite twice already this week... ) Well, Tom and I have discussed this and have both taken on one `big' task, and one `small' task to tackle next in the development process. I think this is a good idea personally - having a few small things on the to-do list can help when you get stuck or just need a break from the main tasks, but you still want to do some work. I'm going to concentrate on developing the Track Editor so that game modes can be worked on, with my secondary task of continually tweaking the physics and collisions systems - possibly start optimising the slow bits. Tom is going to be working on adding some pseudo-3D elements to the engine, like the old GTA games had. I am looking forward to some 3D trees immensly! He's also going to add some Shared Object abilities to our FileManager class to help save championship progress and fastest laps times, etc.

Things I've done this week

The Track Editor has had a big clean up already this week, with ability to load maps to re-edit the one we already have. It's gone a bit more OOP in structure too with the addition of a Brush class, which I'm hoping will be easy be add a "copy" feature to grab multiple tiles off the map to paste elsewhere. The next thing to add though will be selecting the textures of the Brush, since the Editor was originally written only to make boolean hitTest information. Now we have several surfaces/textures rather then just grass and tarmac, we really need to be able to select them :) So that's what I've done and what I will be doing for this week.

"Tina, come get some ham!"

Monday, January 23, 2006

Tech Demo Release! (Finally..)

At last, the first major milestone in this mammoth project has been reached, we've kept you hanging since well before Christmas for a working demo, but now is the time! Me and Jon have been laboring all weekend over the last of our goals for this tech demo in order to get it into the wild today...

Current Features
- Different surfaces affect handling
- All game data loaded from external XML files
- Accurate collision detection
- AI with up to 6 cars on track
- HUD including lap times / lap counter and race positions
- Dynamic camera, that can swap between racers

Future Features
- More tracks
- Larger tracks
- Accurate collision response
- Solid & Tire Walls
- 3D Structures
- More advanced AI with more varied racing lines
- Career mode, saving of all race data / lap times etc
- Graphics options for slower computers
- Cheats
- Sound

Known Issues
- You can drive off the map
- Collision response not finished

We Need You

What we would love it some feedback on the engine so far, your opinions on every aspect of the game and how it can be improved in future revisions. Some information that would be nice when you comment:
  • CPU speed
  • Flash player version
  • frames per second ( top-right corner ) - min/max/average would be great!

Enough Babble, I Want To Play!

You can play the flashracer tech demo using the following controls...

UP arrow - Accelerate
DOWN arrow - Brake
LEFT and RIGHT arrows - Steering
SPACE bar - Handbrake
1 - 4 numbers - Change camera view to other cars

The Sexy Temporary Graphics

(Jon getting beats by the computer)


Enjoy the demo, let us know what you think in the comments for this post or on the flashkit thread which can be found here. Don't forget, this is just a tech demo, showing the engine we have achieved so far - there is much more to add and many more updates left to come so stay tuned!

Thursday, January 19, 2006

Further Ponderings

I hope anyone that's following this project has guessed that the whole Christmas and New Years thing sort of got in the way a bit... we're still committed to releasing the demo `by the end of the week', only now it's this week instead :)

Thanks for the comments we received on the last entry. I wanted to explain a few things that I obviously didn't explain too well the last time :)

Race Positions

I mentioned last time the three criteria needed to determine the order of cars in the race. I hadn't talked to Tom about how I was going to attempt this, so it's my fault he misunderstood the method I was trying. I was trying to sort the array of cars via laps completed first. Then take smaller sections within that array that all had the same lap number and sub-sort them based on the next criteria - waypoint number. Then re-sort again all those sub-sub-sections that had exactly the same laps and waypoint number, but this time on waypoint distance.

All this seems obviously stupid and overly complicated after reading the great idea left in a comment by Leyenda. His much simpler method required calculating a single `fitting' value from the three criteria for each car, then sorting the array once via this new parameter. No more multi-sub-sorting for me :) Having thought exactly what this `fitness' function could be, I came across the obvious one of percentage of the race completed. This has the extra advantage when it comes to waypoints, because they are all different distances apart, and using percentages normalises them all. The only extra required data I needed was the exact distances between successive waypoints. Since these never change throughout the race, it's nice and simple to calculate them once before the race starts and keep them in a look-up array for after - one of the first tricks you learn in game optimisation club.

So the situation now is that we now have working race positions! For each car I calculate the percentage of the race completed using the same three criteria discussed. For the sorting I wanted to use one of the built-in flash array sort mechanisms - less work for me, and I'm hoping they shouldn't be terribly slow. Array.sortOn() looked the right choice. I needed to obviously sort the array via percentage complete, but keep the car ID's stuck to the corresponding percentages Sticking the ID and percent into an object, then pushing all those into a temporary array and sortOn("percent") did the trick. All that was left was to loop back through the ordered temporary array and save the race positions back to the correct car ID again.

90/10 Rule

The only thing the more pedantic side of me is complaining about is that this solution isn't very `elegant'. The entire car list is getting updated each time, when most of the time there is no difference. A better approach would be to only swap race positions of cars when they are near enough to each other that they could overtake. This is where the linked list idea could help. But at the moment I am just reminded of a rule that I have spotted on several game related websites over the years, called the 90/10 rule. It suggests 90% of the work is done by 10% of the code. Race positions is working. It's not the most elegant solution just yet, but it's working. Since it's not the most time sensitive code we have (it's only running once per several frames anyway), it's better to spend the time refining the physics and collision code.

CPU's To The Ready!

I'm hoping everyone reading this who has a fast enough chip can help us and give us feedback on the upcoming tech demo! See you on the other side.