Flash Racer

The FlashRacer Boys Are Back In Town!

2006-09-30T17:32:00.000Z

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!

Hacking By Design

2006-06-02T21:24:00.000Z

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

2006-06-02T15:07:00.000Z

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...

Status

2006-04-28T11:36:00.000Z

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!

Tom.

Building Our Way To Amarillo

2006-02-28T19:21:00.000Z

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.

Through the keyhole

2006-02-22T15:26:00.000Z

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 ;-)

Jon

Tom

Solid Geometry

2006-02-06T13:20:00.000Z

Well,

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 ;-)

Tech Demo Success

2006-02-02T14:28:00.000Z

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!"

Tech Demo Release! (Finally..)

2006-01-23T18:32:00.000Z

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...

Keys:
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)

Finally...

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!

Further Ponderings

2006-01-19T17:01:00.000Z

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.

It's The Final Countdown

2005-12-05T19:37:00.000Z

*do-de-do-da-doo!* I wish I had permed hair like Joey Tempest... *ahem!*

Greetings again!

What I've been up to...

I've been trying to put the implementations for the ingame HUD stuff into Toms nice HUDManager class, which handles how and when to update the race data. Current and best laptimes are currently working nicely, including formatting. The last thing on that list is the race positions, but this is proving harder than I first though. I'm trying to sort the list of objects that contain race info for each car on the track (lap times, waypoint distances, etc.) The problem is, I have to sort by three components - the current lap, the current waypoint, the distance to current waypoint - and each successive sort must not unsort the previous sort. Confused? Believe me, after a week of debugging my attempt at this, I am too!

I had a wacky idea for a completely different approach, but I've since found flaws in it. I was thinking along the lines of using a `linked list' (LL) to hold the list of cars. At the beginning of the race the cars are nicely ordered on the start grid, so each car could only be interested in the car immediately infront of them. I'd only have to check if I'd gone past the car infront (next in the LL), and swap them if that happened. This way I would only ever have to do a positional check between two cars, and not some complicated full list triple sort. I thought it might also help out with collision detections, since I'd only have to check if I hit the car infront too, meaning our horrid O(n^2) way of collision checking would go to something more like O(n) (I think,) which would be nice. Unfortunately this would break when cars are alongside each other. Maybe someone else has tried something like this and can give any help? I might give it a go one day, but it's a major code change, so it won't be in this demo.

I'll just give a brief word about the collisions. I've managed to fix the compatibility issues with the separate physics systems not interacting nicely. Collisions are much better than they were, but still not 100% satisfactory. What is still puzzling me is the `pop's from the Separating Axis Theory are quite visible, when the should not be due to collision responses also moving the cars. I've got a feeling what it is though, I just need to investigate more.

What's left before the demo...

Since we've been careful to tout the upcoming demo as `tech' demo only (basic textures, no sound, limited features, etc,) we still would like some feedback on how it handles and how it runs from people who try it. However, it's just barely running for us! Tom reports a frames-per-second of less than 10 on his computer. I've been trying to `profile' our code a little bit this weekend, and it's the collision detection and collision response that are feasting on the milliseconds at the moment. Now I completely admit the code is in no way optimised whatsoever, but we'd like to attempt to make it run a little quicker before releasing so we can get useful feedback on how the car handles. If by the end of this week we can't get much improvement without a major optimisation operation, then we'll probably release it regardless. It'd be nice to get some fps/cpu stats anyway. Just be prepared to have crappy best lap times :)

Oh, go on then...

Oh alright, here's a sneak preview of me (bottom-right car - only one car skin so far) forcing one of the AI cars off the road. Told you the textures were temporary :)

XML Fun!

2005-11-28T21:11:00.000Z

So,

Its been a while! What have i been upto you may ask, well apart from shifting my life around the country i have been wrapping up our lovely engine into a more presentable game.

As with most of the information in the game we have decided to keep all the menu info in an external XML file, this allows for ease of editing, flexibility and hopefully reusability in any future projects we undertake. An example of the menu XML for the tech demo:

<menus>
<menu>
<title>Main</title>
<orientation>horizontal</orientation>
<x>225</x>
<y>200</y>
<spacing>10</spacing>
<option>
<text>Start Beta</text>
<func>startBeta</func>
<param></param>
</option>
<option>
<text>Credits</text>
<func>gotoMenu</func>
<param>Credits</param>
</option>
</menu>
</menus>

This is parsed and converted to an object structure as the game is displaying the loading screen. The menus are then created on the fly in the right positions and orientations, displaying the right text! When a button is pressed it then calls the appropriate function within the MenuManager Class and passes the appropriate parameters. I have also been working on a new class called HUDManager, this retrieves all the current information about the race (for example, lap times, positions etc) and displays it on the screen... At the moment this is all done in text format but that will be replaced with some flashy graphics in a later release..

In other news we have been largly bug fixing since the last post, Jon is still working on the broken collision response while i have been tidying up code all over the game in order to get it ready to show you all! Thanks for the support - keep checking back (or subscribe to our Atom feed!) - were getting closer!

Seven Weeks Of... ?

2005-10-20T13:47:00.000Z

Hi folks,

Tom and I wish we could show you seven weeks of work, and a demo of how things are going. Unfortunately that is not the case just yet. We were abducted by aliens and forced to work as male concubines to a cephalopod-based lifeform that desires, above all, the sexy form of a human body. Luckily we managed to escape using our charm, some tin foil and a fork.

Hello? Can you hear me?

Of course in reality we merely had a temporary communications blackout :-). As some of you may have spotted in the comments for the previous blog, Tom had to move house, and then moved back to Uni., both times meaning no 'net connection. Even though we knew this would happen, it was slightly longer than expected.

It brings up the interesting scenario when working within teams formed from afar: When the internet is the only form of communication between members of your team, what is the best way to continue in the event of no communication? We knew what tasks had to be done, so tried to share out some of the main ones that we could work on individually, knowing that each would not overlap on the others progress. Although we have these plans of what we want achieved written down, with some basic design documents, I don't personally think a full detailed plan of the entire development process would work (at least, not in an amateur team who are doing it for fun.) That's part of the enjoyment for me, the spontaneity of development. Not to mention, any plan needs to be flexible at the same time. I would love to hear from any other people, who have also worked as part of a team, what methods were used to coordinate the development process.

Of course, `I love it when a plan comes together' goes without saying :-).

Coding news, now with 50% more tips!

On the coding front, there are a few lasting `niggles' that need to be ironed out before a demo is released. I've been working to add a few more `game' features to the current build. Adding lap timers, with best-times saved, etc. is almost complete. However, I somehow broke the collision response system... oops :-). Here's a tip: when using a version control system to maintain your code, don't try to do many things at once, just update for little things that you know work! Here's another tip that I could give after the last few weeks - always, always put a default return statement in a function, even if you think it'll never get there (like a default statement in a switch case block.) This was my problem with the colldet:

The function that does the SAT routine determines that two cars are overlapping. It then calls another function that checks all the corners of the cars with hitTest() to find which corner is hitting (a bit of a hack, I know.) Here's where the subtle bug creeps in. These functions use different methods--custom maths for the SAT, built in flash functions for the hitTest--and those methods have different accuracies. The corner hitTest function should return the first corner it finds, but I never bothered to do anything if no hitTest returned! I had assumed that one corner would return, because of the previous SAT result. So this means that collision responses now only happen on a few of the collisions, when the hitTest works. That little mistake took me a frustratingly long time to spot.

Thanks for all the fish.

Finally, we'd both like to thank everyone who has been following this blog and your patience. The amount of site hits and feedback had definitely spurred us both on to keep this project going. If any of you have, or know of, any other blogs that outline the process of developing a game--no matter what level--please let us know and we can start to share some links to others blogs in return.

The first `tech' demo is coming, we promise!

All That Jazz

2005-08-30T22:23:00.000Z

The project has been moving forward quickly since we started working using the SVN system, having a central store of the games code that both of us can work from has been invaluable.

Since the last update I have been working on the file manager almost exclusively. Early on we decided that most of the games resources should be kept in external files for easy editing and loaded into the game engine on runtime. This includes things like; race, track and car data aswell as all the in game graphics (which are stored in external SWFs)... All of these files need to be loaded and parsed correctly so that the data is accessible within the game. This is now almost entirely finished.

I have also done a large clear up aswell as adding some small features like 'pause' and a countdown on the grid at the beginning of a race.

We are hoping to post a 'tech demo' of the game on here fairly soon, which is guaranteed to impress, so keep checking back!

We Are Gathered Here Today...

2005-08-24T12:04:00.000Z

...to witness the joining of AI and Physics :)

Yep, after much scratching of heads, and copious amounts of cursing, Tom and I have tonight completed one of our biggest hurdles to date. So far we've been working independently on different areas, but we have now successfully merged our two efforts into one. This evening has been more sickness than health though!

Using the classes outlined last week, a good skeleton to build a game upon is emerging. We now have cars that can drive themselves around the test track, and that have accurate collision detection thanks to the separating axis code. At this early stage after merging (we literally just finished now!) the cars do not react to a collision as well as we want them to. It seems the cars' grip on the road is too strong, and/or the forces due to collision are not quite strong enough. We will need some testing and tweaking of parameters for it to look good, but at least the hard part is out of the way.

I've finally fixed myself up with a new computer and we've successfully migrated to a SVN server to ease multi-developer collaboration, so things should start speeding up a little. Here's a quick screenshot of it in action just after the start of a race... just imagine really nice graphics ;)

Soon we will update the track to the new tiles and produce an early `tech demo' of what we have achieved so far.

ActionScript Corner: Sloped Tiles

2005-08-18T15:56:00.000Z

I thought I'd finally get round to sharing my current method for creating slopes in a tile-based game engine. It's not the most robust method in the world, it simply tests a given point and returns a Boolean result saying whether the point is hitting a solid part of the tile or not. However, it's fast and allows almost as many shapes as you can imagine, including curves if you know how. I think it’s a good start for anyone looking to break up the sometimes monotonous grid structure in their tile-based game worlds.

Standard tile-based methods are used here – a 2D array is used to store the map. Just like you will have a limited number of tile graphics to build the world, there’s a limited number of tile shapes to use too. (It’s obvious you can get greater flexibility if you do not use the same array for both – so you’ll need two 2D arrays or one 3D array for this). Each tile then has an associated function that contains an equation, which describes the shape of the tile.

To test whether a point (x, y) in the game world is hitting a solid part or not you’ll need a few things. First, look up the tile shape number from the map array. You’ll also need the test point coordinates in the tiles local frame of reference. Either subtract the tile dimensions enough times, or just use the modulo operator. It would be best if you also normalised (scale it between 0 and 1) that local coordinate too, so the equations are generic for every tile size. The local coordinate is what is passed into the custom hit-test function, as well as the tile number.

As a small example I'll show how to make the most basic 6-tile set, shown in the picture below.

Here are the individual tile functions, named `tileHitN’, where N is the number of the tile.

function tileHit1(x, y) {
return false;
}
function tileHit2(x, y) {
return true;
}
function tileHit3(x, y) {
return y > 1 - x;
}
function tileHit4(x, y) {
return y < 1 - x;
}
function tileHit5(x, y) {
return y > x;
}
function tileHit6(x, y) {
return y < x;
}

Now to the generic `test a point’ function that you will use whenever you want to perform the test. Here I assume you’ve already looked up the current `tile’ reference number and normalised the tile local coordinates, `x’ and `y’. You could always just pass in the world coordinates and have this function do all that for you.

function hitTestTile(tile, x, y) {
 return [“tileHit”+tile](x, y);
}

That’s it :) The square brackets dynamically construct the correct function name, and passes on the coordinates to the equation that does the actual hit-test stuff. Of course, you are left with what to do when the result is true, like unstick something from inside a wall...

I’m hoping for this project that I can get away with this simple method for the track boundaries, a more robust method will require a lot more work. Our tile-shape set has over 80 tiles in it – more than enough to make some nice smooth looking tracks to drive around in. One of our goals was to break away from the boring 90 degree corners other car games using the tile-based method have, whilst still retaining the speed that tiles allow. Here’s a quick screenshot of the early (and very basic) tile editor showing some different curves that can be made.

P.S. I miscalculated the 150+ tiles last time – we’re planning to have 2 `layers’ of these 80+ tiles, so that’s where the 150+ came from.

Back of the Class

2005-08-12T23:50:00.000Z

It seems like a long time since i last updated here... i have spent a lot of time on the engine today, mainly organising code and class structure after a lengthy discussion with Jon last night. We have decided on a system of 'Manager' classes to keep the code in order, the main one's being:

PlayerManager

keeps track of players career status and track records

RaceManager

holds information only for the current race and functions for starting / stopping / pausing

SoundManager

loading, starting, stopping and deletion of all the sounds within the game

FileManager

loading and saving of track, player and tileset data

Im hoping to post more technical details here over the coming weeks, aswell as hopefully some interesting code and in depth theory!

Another One Bytes The Dust

2005-08-10T15:04:00.000Z

I've had a little bit of a break this week, after an initial attempt at joining Toms' AI with my rigid-body physics. We have both found some design issues that need to be cleared up before we can start to pull our efforts together into something that more resembles a game. I was hoping to get to that stage within about a week or so, but something unexpected happened last night.

Yep, development will now be delayed slightly due to my dev computer blowing up. *Poof!* Nasty smell. Smokey haze. Tears.

After a bit of a rummage this morning, I spotted this.

I think it's some kind of MOSFE Transistor, but I know that it's got a big crack down it :) I can't believe it produced all that smell, so maybe something else has blown. I was hoping it was just my PSU, which I've suspected of being near the end for some time now, but this looks just a bit more serious.

I've been pondering the possibility of an upgrade for a while, so now I have a perfect excuse! Besides, when you find cobwebs in your case I think it's about time for a (late) Spring Clean...

However, I will be posting a small `article' style blog on the method I am using for sloped tiles. It's all done, but the code snippets are playing havoc with the formatting on this blog, so give me a day or two for that one.

Artificial Intelligence Update

2005-07-27T23:27:00.000Z

I've been hard at work on this the past few days. As my part of the engine now stands the AI car races around the track with ease, braking at the appropriate places - it also has the ability to recover after an accident.

Elsewhere, i have corrected a few bugs that were causing problems on certain shapes of corner and in the process simplified some of the calculations. I have also added a handbrake to the physics model, allowing you to perform handbrake turns!

I will try and post a demo (recorded or realtime) here in the next week.

Rigid Body Physics Demo

2005-07-27T20:29:00.000Z

A little later than promised - a small demo of the new rigid body physics system that the cars will eventually be made with.

Rigid Body Physics - Bullet Demo

This shows one very heavy `bullet' smashing into several lighter bodies. Almost like rectangular ten-pin bowling :) As you can see, the problem of objects becoming interpenetrated and sticking together has completely gone. It doesn't stop them from overlapping entirely - sometimes several rectangles grouped together may overlap - but they won't stay that way for long. They will quickly be projected away from each other.

A note on the limitations of this demo: This demo is not actually the proper real-time simulation - it is a recording. Because the recording takes snap shots a bit slower than the original framerate, it doesn't look as smooth. When the game engine is a bit more complete we'll get round to showing some real-time stuff. It's much smoother, trust me :) The other thing is that there are no realistic collisions with the walls just yet. For now their centre of masses bounce off the walls like point masses. I'm still working on the `car-to-wall' collisions, but it's basically the same theory.

Next time... possibly something to do with the tilesets used to contruct tracks. 150+ tile shapes!

Artificial Intelligence

2005-07-23T12:40:00.000Z

Over the past couple of nights i have been working on a basic AI, the aim for this is simply to get the car to drive around the track, when this is complete it will be advanced with braking etc. I also hope to add the ability to avoid other vehicles and recover from any accidents...

This screen shows the current engine with debugging lines displayed, the car works out the trajectory to the next 'waypoint' (which are poistioned at critical points around the track) and adjusts its steering accordingly.

First Post!

2005-07-21T19:10:00.000Z

Hello world!

For my first post I'm just filling in what I've done so far for this project. I first started on the modelling of rigid body dynamics for Tom's game Felony, about 2 year ago. It progressed slowly, and although it was quite good for a physics simulation, the speed and stability wasn't exactly great for a game. A year passed, and no work was done on it. Recently both Tom and I decided to resurrect the idea of putting realistic car collisions into a flash game. This racer project was born :)

I've re-implemented the original collision detection scheme to use the separating axis theorem (SAT). This gives a quick and accurate collision detection, as well as information about where the collision happened. I've used that to project apart any cars that are overlapping. Gone now is the old problem of cars getting stuck together. The old impulse based method of `bouncing' the cars apart is basically the same as it used to be.

Some articles on the old method, as well as some old and messy source code are on my website. There will be an article on the SAT method soonish. I'll be putting up some basic source code examples in the tutorials, however from this point on the full col-det/response code will not be open source.

Next I will be trying to outline the racetracks boundaries so that the car also bounces and crashed away from the barriers realistically. Still thinking of the best way to do this :)

I made a nice demo of a heavy car smashing into some parked light cars to show how the rigid body dynamics has improved in stability, but that will have to wait until the weekend to be uploaded...

Progress

2005-07-20T23:04:00.000Z

I thought i had better let you know the progress so far, as this blog has been started a few weeks into the project.

Me and Jon started chucking ideas around a couple of weeks back and working on a design document with features we hope to implement (this will later be expanded into how!) We decided to tackle what appeared to be the most difficult sections first, so jonmack began work on a collision detection and response system (for both rigid bodies and the track) which i hope he will post about here soon and i began to develop the car handling, camera and a basic AI model.

As the project currently stands the collision detection and response are both semi complete, although not quite 'solid' enough yet, the camera is complete, a handling model is implemented and i have just started the AI this evening!

Phew.

I should update more specific details on the AI tomorrow...

Welcome!

2005-07-19T22:29:00.000Z

Welcome to the racer blog, the basic idea is to document the development of a game from start to finish, with all the problems and success' that we encounter along the way! Hopefully these pages will be updated fairly regularly...

T.