We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Game and Simulator Physics for Developers, Gamers and Petrol Heads

00:00

Formale Metadaten

Titel
Game and Simulator Physics for Developers, Gamers and Petrol Heads
Serientitel
Anzahl der Teile
170
Autor
Lizenz
CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
This entertaining and demo intensive session will lift thelid on the black art of physics simulation in computer games. The samplescenario will be the re-writing and testing of the physics engine in a sample3D driving game. Starting with the basics of force, mass and acceleration thesimulation will be gradually enhanced to include lateral and vertical g-force,tire slip, down-force and collision detection. The addition of a drag reductionsystem (DRS) and kinetic energy recovery system (KERS) will round off the demo,and add a strategic element to the game. The techniques demonstrated can easily be applied to 2D and3D games on any technology to improve the responsiveness, feel and overallplayability of the game. The trade-off between the purity of the simulation andthe all-out fun of arcade style games will be discussed and demonstrated, alongwith plenty of tips for developing, testing and fine-tuning the physics model. Whether you are learning to develop 3D games in Unity,MonoGame or another technology, interested in learning more about what makesgaming physics simulations tick, or just want to kick back and see how much funyou can have with C#, this session will have something for you. You will alsohave the chance to install and play the game, test the physics implementationfor real time and compete with other attendees for the best lap time!
SoftwareentwicklerSimulationSpieltheorieTheoretische PhysikSchreiben <Datenverarbeitung>StichprobeComputersimulationQuellcodeATMWeg <Topologie>StatistikWeb SiteTextur-MappingDesintegration <Mathematik>Dienst <Informatik>InformationsspeicherungForcingAusdruck <Logik>Dienst <Informatik>SpieltheorieKartesische KoordinatenVisualisierungWeb logSystemplattformBestimmtheitsmaßBildschirmfensterMultiplikationsoperatorTextur-MappingBitInformationsspeicherungCoxeter-GruppeWeb SiteWeg <Topologie>ATMSoftwareentwicklerProjektive EbeneProzess <Informatik>BenutzerschnittstellenverwaltungssystemComputersimulationSelbst organisierendes SystemQuellcodeAngewandte PhysikStabilitätstheorie <Logik>PhysikalismusTeilbarkeitFokalpunktPunktwolkeTypentheoriePhysikalischer EffektRechenbuchHorizontaleGeradeBenutzeroberflächeDatenstromCloud ComputingRFIDCodeRückkopplungGüte der AnpassungIntegralGamecontrollerOffene MengeErschütterungSchreib-Lese-KopfKlasse <Mathematik>MathematikFächer <Mathematik>Leistung <Physik>Virtuelle MaschineLesezeichen <Internet>StichprobenumfangEDV-BeratungBus <Informatik>TabelleCodierungGebäude <Mathematik>Faktor <Algebra>Computeranimation
SimulationVideokonferenzSpieltheoriePhysikalismusWellenpaketBitIntegralCloud ComputingSimulationEntscheidungstheorieComputersimulationKartesische KoordinatenArithmetisches MittelService providerBildschirmmaskeFaktor <Algebra>Ausdruck <Logik>SoftwaretestComputeranimation
SimulationSoftwaretestAusdruck <Logik>Virtuelle MaschineAbtrieb <Aerodynamik>Weg <Topologie>WinkelWasserdampftafelGebäude <Mathematik>TypentheorieData MiningComputeranimationBesprechung/Interview
Web-SeiteSpieltheorieTypentheorieData MiningBitrateSpieltheorieComputersimulationFokalpunktSimulationOvalComputeranimation
Gebäude <Mathematik>SimulationKartesische KoordinatenTeilbarkeitSpieltheorieAusdruck <Logik>MultiplikationsoperatorComputeranimation
SimulationTheoretische PhysikComputerSpieltheorieSimulationVideospielSoundverarbeitungWeb SiteComputerspielPhysikalismusOffice-PaketGebäude <Mathematik>DialektComputeranimationJSON
SpieltheorieAuflösung <Mathematik>SoftwareentwicklerStichprobenumfangAngewandte PhysikCodeBitSchnittmengePhysikalismusVHDSLSimulationInformationsspeicherungKreisbewegungSchnelltastePolarkoordinatenReibungswärmeVersionsverwaltungFamilie <Mathematik>EinsMultiplikationsoperatorComputeranimation
Theoretische PhysikSchreiben <Datenverarbeitung>SpieltheorieCodeMathematikStichprobeEinsCodeLastMAPKartesische KoordinatenKomplex <Algebra>Nichtlineares GleichungssystemSpieltheorieWeg <Topologie>MathematikBitVektorraumMatrizenrechnungAngewandte PhysikProgrammierumgebungDifferenteObjekt <Kategorie>VisualisierungProgrammPhysikalismusDienst <Informatik>Gewicht <Ausgleichsrechnung>StichprobenumfangEinsInelastischer StoßAusnahmebehandlungTeilbarkeitKollisionserkennungSoftwareentwicklerForcingMultiplikationsoperatorCoxeter-GruppeWorkstation <Musikinstrument>CASE <Informatik>SystemplattformGebäude <Mathematik>GrundraumSimulationComputeranimation
BenutzeroberflächeForcingZahlenbereichSpieltheorieAutomatische HandlungsplanungMultiplikationsoperatorKollisionserkennungPolarkoordinatenWeg <Topologie>PhysikalismusSimulationWechselsprungNichtlineares GleichungssystemLoopProgrammschleifeGebäude <Mathematik>FlächeninhaltRahmenproblemZweiVideospielProgrammfehlerComputeranimationVorlesung/Konferenz
RahmenproblemYouTubeSpieltheorieComputersimulationPhysikalismusHorizontaleRenderingGarbentheorieEnergiedichteComputeranimation
ATMSpieltheoriePhysikalismusEnergiedichteSoftwaretestAngewandte PhysikKartesische KoordinatenZweiTestbedForcingSystemaufrufComputeranimation
Theoretische PhysikDemoszene <Programmierung>GravitationPhysikalische TheorieGesetz <Physik>Newton, IsaacGraphEulersches PolygonzugverfahrenRechnernetzDatenbankFacebookTwitter <Softwareplattform>SimulationEuler, LeonhardKraftDruckspannungReibungswärmeRuhmassePunktRahmenproblemDesintegration <Mathematik>GeschwindigkeitSchwimmkörperSinusfunktionRadiusLoopSpieltheorieVolumenvisualisierungOvalTeilbarkeitRechenbuchMatrizenrechnungPhysikalismusDemo <Programm>BitForcingMetropolitan area networkEnergiedichteDateiformatSpieltheorieTypentheorieSystemplattformSummierbarkeitAbtrieb <Aerodynamik>MatrizenrechnungZweiTwitter <Softwareplattform>DatensatzMessage-PassingRechenbuchThermodynamisches GleichgewichtRahmenproblemFacebookDruckspannungKomplex <Algebra>Physikalische TheorieGravitationGeschwindigkeitAusdruck <Logik>GravitationsgesetzImpulsRadikal <Mathematik>MultiplikationsoperatorGraphRenderingObjekt <Kategorie>BruchrechnungReibungswärmeRelativitätstheorieNewton, IsaacVideospielIntegralTouchscreenDisplacement MappingQuadratzahlRadiusEin-AusgabeWeg <Topologie>GasströmungDifferenteVersionsverwaltungWinkelTreiber <Programm>FeuchteleitungAutomatische HandlungsplanungTeilbarkeitOrtsoperatorSimulationInverser LimesNormalvektorStrömungswiderstandLoopKnotenmengeVariablePunktRuhmasseAngewandte PhysikAuflösung <Mathematik>DatenstrukturComputersimulationQuick-SortFramework <Informatik>DiagrammFunktion <Mathematik>MultiplikationTangente <Mathematik>Kategorie <Mathematik>GamecontrollerVektorraumSondierungTermAuswahlverfahrenRechter WinkelHardwareMehrrechnersystemDesign by ContractBenutzerschnittstellenverwaltungssystemVerdeckungsrechnungEinfügungsdämpfungGesetz <Physik>KonstanteMechanismus-Design-TheorieTropfenPolarkoordinatenSystem DynamicsVorzeichen <Mathematik>Dienst <Informatik>DatenfeldSchnelltasteQuaderEinsComputeranimationDiagramm
OvalSpieltheorieRahmenproblemTeilbarkeitSchwimmkörperTheoretische PhysikRechenbuchMatrizenrechnungLeistung <Physik>DickeEin-AusgabeNamensraumKonstanteKoeffizientReibungswärmeCliquenweiteVariableOrtsoperatorPunktMathematikRichtungGeschwindigkeitVektorraumVektor <Datentyp>Minkowski-MetrikAdditionKraftResultanteAbtrieb <Aerodynamik>GravitationGruppoidBinärdatenProdukt <Mathematik>EbeneVerschränktes ProduktRechter WinkelAlgebraische ZahlFolge <Mathematik>ZahlenbereichGrößenordnungSkalarproduktRichtungOrtsoperatorVektorraumForcingCoxeter-GruppeAutomatische HandlungsplanungAusdruck <Logik>ComputersimulationPunktKonstanteTreiber <Programm>MultiplikationsoperatorReelle ZahlRechenschieberLoopBitFokalpunktReibungswärmeRahmenproblemGebäude <Mathematik>RechenbuchDimensionsanalyseKlasse <Mathematik>OrdnungsreduktionMinimumMixed RealityDifferenteKoordinatenDickeRechenwerkKartesische KoordinatenBildschirmfensterAbtrieb <Aerodynamik>VariableProdukt <Mathematik>Weg <Topologie>MatrizenrechnungEinsSpieltheorieStrömungswiderstandGeschwindigkeitHyperbelverfahrenQuick-SortVektorrechnungTypentheorieNormalvektorPolarkoordinatenPhysikalismusSkalarproduktAngewandte PhysikGravitationsgesetzDatenstrukturVideospielAbstandVorzeichen <Mathematik>Objekt <Kategorie>Nachlauf <Strömungsmechanik>SoftwaretestMathematikWinkelGarbentheorieCodeHill-DifferentialgleichungGravitationTouchscreenProgrammschleifeRuhmasseSimulationTelekommunikationTeilbarkeitStrömungsrichtungHilfesystemTermersetzungssystemKomplex <Algebra>KontrollstrukturSoundverarbeitungDemo <Programm>WechselsprungUnrundheitDienst <Informatik>MehrrechnersystemMultiplikationZahlenbereichResultanteLeistung <Physik>GefangenendilemmaAggregatzustandDatenfeldLesen <Datenverarbeitung>Computeranimation
RechenwerkSpieltheorieMultiplikationsoperatorKreisflächeUnrundheitQuadratzahlPlastikkarteWeg <Topologie>Maskierung <Informatik>Patch <Software>GraphiktablettFahne <Mathematik>VolumenvisualisierungComputeranimationBesprechung/InterviewProgramm/Quellcode
DefaultPlastikkarteBildschirmmaskeLambda-KalkülEin-AusgabeAusdruck <Logik>ComputersimulationStandardabweichungSummierbarkeitVariableKurvenanpassungMathematikVersionsverwaltungGeschwindigkeitWinkelBitrateFlächentheorieFormation <Mathematik>Funktion <Mathematik>BitRechenschieberKurvenanpassungWeg <Topologie>Ein-AusgabeMultiplikationsoperatorComputersimulationZahlenbereichReibungswärmeAusdruck <Logik>SpieltheorieKollisionserkennungKreisflächePlastikkarteKontrollstrukturImplementierungCodeComputeranimation
KurvenanpassungKraftWinkelRückkopplungBillard <Mathematik>Gesetz der großen ZahlenSpannweite <Stochastik>Theoretische PhysikEin-AusgabeGeschwindigkeitGraphEinfügungsdämpfungFächer <Mathematik>ElementargeometrieCodeAusdruck <Logik>ImplementierungBeamerVideospielPhysikalismusBitForcingATMGraphiktablettSpieltheorieRegulärer GraphAngewandte PhysikComputeranimation
Gesetz <Physik>Physikalisches SystemWiederherstellung <Informatik>EnergiedichteKinetische EnergieBestimmtheitsmaßMultiplikationsoperatorGamecontrollerPunktWechselsprungGarbentheorieWeg <Topologie>HyperbelverfahrenSplineCase-ModdingBitEin-AusgabeFeuchteleitungSpieltheoriePhysikalismusDimension 3ProgrammschleifeTypentheorieVollständigkeitVorzeichen <Mathematik>RechenbuchGeradeMessage-PassingMinkowski-MetrikWärmeübergangProzess <Informatik>Güte der AnpassungSystemzusammenbruchWeb SiteMeterComputersimulationMathematikComputeranimation
ExpertensystemInstallation <Informatik>Treiber <Programm>Ein-AusgabeEnergiedichteKinetische EnergiePhysikalisches SystemWiederherstellung <Informatik>ReduktionssystemGasströmungEin-AusgabeMessage-PassingMultiplikationsoperatorDienst <Informatik>Treiber <Programm>Ausdruck <Logik>Bus <Informatik>Angewandte PhysikPhysikalisches SystemKinetische EnergieProzess <Informatik>SprachsyntheseWiederherstellung <Informatik>SpieltheorieKurvenanpassungAbtrieb <Aerodynamik>PhysikalismusForcingTouchscreenWeg <Topologie>BitDiagrammÄquivalenzklasseStrategisches SpielLokales MinimumSoundverarbeitungStrömungswiderstandGarbentheorieVideospielMinkowski-MetrikSoftwaretestBenutzerfreundlichkeitGasströmungMereologieSimulationTermComputeranimationDiagramm
Weg <Topologie>SpieltheorieGarbentheorieAbtrieb <Aerodynamik>Case-ModdingGesetz <Physik>GeradeGamecontrollerQuaderComputeranimation
Theoretische PhysikSpannweite <Stochastik>DatensatzDivergente ReiheStrömungswiderstandVorzeichen <Mathematik>GarbentheoriePhysikalismusYouTubePhysikalischer EffektRadikal <Mathematik>Dienst <Informatik>Elektronisches ForumGeschwindigkeitComputeranimation
ATMTouchscreenFormation <Mathematik>Divergente ReiheVariableTheoretische PhysikVektorraumGravitationGeschwindigkeitWarpingOrtsoperatorNP-hartes ProblemTranslation <Mathematik>OvalKraftKalkülResultanteRechenbuchVektor <Datentyp>PartitionsfunktionPhysikalismusRadikal <Mathematik>SystemzusammenbruchBitSpieltheorieSoftwaretestSchreib-Lese-KopfVersionsverwaltungReibungswärmeOrtsoperatorGeschwindigkeitArithmetisches MittelSpezielle unitäre GruppeKonfiguration <Informatik>KoeffizientKlasse <Mathematik>RahmenproblemRichtungComputersimulationForcingMathematikZweiVektorraumBruchrechnungTouchscreenMultiplikationsoperatorDickeGasströmungTVD-VerfahrenRechenschieberApp <Programm>KonstanteWeg <Topologie>VariableRechenbuchMeterRuhmasseStrömungswiderstandCodeResultantePunktSoftwareTeilbarkeitDifferenteZentrische StreckungGravitationZahlenbereichObjekt <Kategorie>SoundverarbeitungPrimidealInstantiierungComputeranimationVorlesung/Konferenz
ExpertensystemGeschwindigkeitOrtsoperatorMultiplikationsoperatorSpieltheorieGarbentheoriePhysikalismusBitBildschirmfensterWeg <Topologie>Güte der AnpassungWellenpaketKonzentrizitätNP-hartes ProblemProjektive EbeneStereometrieSystemzusammenbruchGrundraumSkalarproduktProgrammTouchscreenTypentheorieComputeranimation
Theoretische PhysikInformationsspeicherungWindows AzureRankingAtomarität <Informatik>SpieltheorieBitTypentheorieInformationsspeicherungPunktwolkeMultiplikationsoperatorCloud ComputingPersonal Area NetworkWeb SiteInternet der DingeProjektive EbenePhysikalisches SystemProzess <Informatik>Dienst <Informatik>TabelleBildschirmfensterTopologieEinsPlastikkarteFlächeninhaltCOMComputeranimation
SpieltheorieEinsSpieltheoriePhysikalismusTypentheorieInelastischer StoßMathematikTreiber <Programm>QuellcodeVideokonferenzPay-TVAusdruck <Logik>Angewandte PhysikDatensatzMaschinenschreibenQuick-SortPhysikalische TheorieBildschirmfenster
Ausdruck <Logik>BildschirmfensterComputeranimation
Transkript: Englisch(automatisch erzeugt)
Good afternoon, and welcome to the session that I'm going to be delivering on game and simulator physics for developers, gamers, and petrolheads. My name's Alan Smith, I work for a consultancy company in Stockholm called Active Solution. You can probably tell from my accent that I'm not from Sweden, I'm actually from the UK.
My main focus is working on Windows Azure, cloud computing, and working with customers who are moving applications to the cloud and want to leverage Windows Azure services. I recorded a course for Pluralsight, and during recording that course I wanted something that was going to be a fun way of showing how we can leverage Azure services.
I took a sample game that Microsoft had developed on the XNA platform, integrated it with Azure services. During the development I got a bit carried away with looking into the game code. Gaming and game code is very addictive. If you start playing around with this stuff on Friday afternoon, kiss the weekend, goodbye, you're going to be spending all weekend playing around with this stuff.
It's great fun, you can get addicted. I did spend a lot of time looking into working with physics and simulations in the actual game to try and get the game a bit more realistic. I've been doing some presentations on this, so I'm not a game developer. I don't really do this as a full-time job, this is more of a hobby session. I think there's a lot of stuff that we can learn with building applications where there's some kind of visual user interface.
It really helps and makes the applications feel better. Strange concept, you don't actually touch the application, you see it and hear it and maybe feel it a bit if it's got some vibration or tactile feedback in a controller or in a phone. You talk about the feel of an application, you can really increase that if you understand a bit about how physics works.
The project that I've been working on with integrating a racing game with Azure, I've given it the title of Red Dog Racing. If you watch any Formula One, you'll have heard of Red Bull Racing, who is a Formula One team. If you've followed Windows Azure, you'll know that Red Dog was the actual original code name for some of the Windows Azure technologies.
So I kind of mixed those two together and came up with that actual name for the game. Disclaimer, I've done this session a few times and another session on the Azure integration and telemetry and stuff. People come out of the session with the assumption that I've actually written the game. I did not write the game, it's developed by Microsoft. It's available as a sample application for the XNA platform, which is now available on Coplex.
If you want to play around with this stuff, you can go and download the full source code and models available at that URI. If you just go in and search for XNA racing game, you'll get the actual codes to download and play around with. What I have done though is done lots of modifications on the game. I've rewritten the physics engine completely for the way the car interacts with the track and all of the actual forces.
Modified some of the textures to actually customize it to put the Windows Azure logo in it and our company logo in it. Modified the track layouts, integrated the game with Azure services. The replay data for Ghost Cars is going into blob storage, lap times and telemetry data into table storage. I'm using the Azure service bus for telemetry data streams.
I'm not going to talk too much about that today. That's the Azure and cloud computing side of things. I've built a website that shows the gaming stats. You will see your lap times and telemetry data available on that website if you're working on the game. I've also added a camera track mode and been playing around with various bits during the game.
Why am I doing all this? I'm really passionate about Microsoft Azure, as it's now called, and cloud computing. I think there's some massive opportunities for organizations and for developers to start leveraging these cloud-based services. That's basically what my main focus is. I was kind of a physics geek at school, so I was really into all this kind of stuff.
Forces, masses, accelerations, vectors, and doing all these types of calculations. It's something that I could naturally do and naturally get my head around when I was sat in the class at school. Probably one of the only things I could naturally get my head around. I'm a Formula One fan, so I'm watching the races every weekend. I'm really interested in the technology and the physics that goes into making these machines work.
The Lotus team is actually sponsored by Microsoft and Avanade. A lot of work has gone into using the services in Windows Azure to get the telemetry data from the car to the pit lane and then back to the actual factory in the UK so they can see what's going on in the actual racing as well.
I like playing driving games. Forza Horizon is one of my favorites. I like the way it's not a serious racing game. It's kind of an open world, but with good physics and good playability. I'm kind of more into that style of games. As I mentioned, the main scenario behind this is to provide an integration between the application and Azure.
I deliver a lot of sessions on this. I use this in my training courses. I do racing game workshops where you can do hands-on labs integrating this stuff with Azure. It's kind of a nice way of showing something that people can relate to and how it works with a cloud computing platform. A bit about the game and simulator physics. Really, when you're thinking about building physics into a game or into an application,
you've got to make a lot of decisions. One of those is, are you going to focus on building a simulation or are you going to focus on playability? A couple of videos are going to show what I mean by that. When you look at a pure simulation, it's going to be something like this.
This is at the actual Red Bull factory in the UK. This is the actual simulation rigs that they use for Formula 1 cars. They cost millions and millions of dollars. They're highly complex and they're really designed to provide the most accurate simulation as they can on the actual car. They're limited in testing in Formula 1, so if they put a new front wing on the car,
they want to be able to model the downforce that that particular design of front wing will place on the car and how that will affect the car going around the track. These fantastically complicated machines are basically what they're really focused on. They're going in for this pure simulation angle of things. If you look at what people start doing at home, is anybody into sim racing and building these kind of rigs at home?
I have a couple of friends in Sweden and down in their basement, they basically do things like this. They spend thousands and thousands on just building these types of things. A friend of mine from his wife for Christmas, he got two 27-inch monitors to go next to the other 27-inch monitor
that he'd got in his basement to basically build one of these driving rigs. They're basically highly complex, a lot of money that they put into these. Really, this is a game going towards the simulation side of things. These people get really offended if you say that they're playing games.
They're not playing games, they're driving a simulator. It's not a game, it's a sim. They focus on those types of things, spending thousands of kronor on a gear stick or 10,000 kronor on a racing seat just so they're going to get that simulation. If you think these guys are bad, you should see what the actual flight sim people build.
These basically flight sim rigs, they get incredibly complex. This is the one I was looking for. Imagine what the wife approval factor of building that in your dining room is going to be. They're really focused on the simulation side of things. They really want the pure racing angle, whether it's flying or whether it's racing cars. However, maybe that's not going to be the thing that makes a game playable
or makes an application worthwhile for the user. I take to have a Formula 1 racing game where I'm driving for over an hour and then the engine overheats or one of the tires bursts. Because that would happen in Formula 1. If I was pressing the accelerator pedal too hard or if I was driving too fast around corners, it would destroy the tires
and the tires would burst as it sometimes does during racing. You've always got this compromise between building in some playability and actually having the total accurate simulation for the people who are going to be actually driving these games. I saw this quote. I love this quote.
I can't remember where I saw it, if it was on a t-shirt or if somebody tweeted it or if it was just on a sticker on a website. It's talking about the way that we can get immersed in computer games. Much to the effect that the computer game physics seems more realistic than the real world. I remember playing Quake and then going around the supermarket.
You get this thing where you're going around the aisle expecting a rocket to come down the aisle because you've been so immersed in that game world it was starting to impinge into the actual real world. Really thinking about when you're actually building the physics into a game, that's one thing you have to think about. The original XNA racing game, I've got a sample here which is based on using the original physics engine in the game.
The idea behind this game was to develop something that was playable. It used a lot of the XNA features. But what was not a high priority in the development of this game was implementing a physics engine. One of the things that the developer decided not to do was to actually reach out and use a commercial physics engine
and bring that code into the game. If we actually go in, I'm just going to change the actual settings so it looks a bit more appealing on the actual resolution. We go in and start the race. You can actually go around. I think that considering the physics is so basic it does have a fairly nice feel to the game. You get the acceleration. In this modified version, you can see the ghost cars coming from Azoblob storage from the other players in the lab.
If you start to actually think about what happens and how they've implemented it, they've done a lot of shortcuts. It's a question of does the player notice these shortcuts. The car does not steer. The car rotates. If I'm moving the mouse, we've got this kind of rotation. You remember Asteroids in the 80s, that little ship that rotated.
It's the same thing as that. When you're going around a corner, you get around a corner if you can actually move the mouse quick enough to rotate the car and change its direction as you're going around the corner. There's no such thing as centrifugal force. I took that corner at a really high speed. In a real world, the car would have slid.
There would have been some tire friction. That's not present in the game. What I did when I was working with this game, I put this game out on a click once deploy and a couple of my friends played it. One of them who played it was my friend who's got this big sim rig in his basement who plays at sim racing a lot. His comment was the game is okay. It's fun. It's a good way of showing off as well.
However, the physics in it is terrible. It doesn't actually do physics at all. You may as well be steering a banana around the actual track. You're just steering an object around a 3D landscape and there's nothing related to physics. I thought, okay, if that's a problem, I'm a developer. I'll go in and I'll fix that problem. What I decided to do, and this was over Christmas,
was to actually rewrite the physics engine for this game. What I was going to do, I was going to start with the XNA Racer code. I wasn't going to build my own game. That's got a lot of the stuff in there that I need to play around with. All I'm going to do is swap out and swap in my own physics engine. The game style I'm going to play on is going to be fun, arcade-style gameplay.
I do these racing game workshops where people come in. The people who come to these workshops are mostly not really into the simulation. They just want something that's going to be nice and playable and maybe have a nicer feel to it. I'm more focusing on the arcade-style gameplay than the actual realistic simulation. The code that I was going to use
and the ideas that I was going to base this on was going to be on the physics I learned at school. Another scenario of this, I think it would be a great way of communicating with kids about getting them into programming and games. Also, reinforcing the stuff they're learning in school about vectors and matrices actually has real-world uses when you think about using them in games
because it is literally the stuff I was learning when I was 14, 15, 16 years old in the math lessons at school. That's basically the level of maths and physics. I'm not going to go into advanced physics or university-level physics. I'm going to keep it at the actual school-kid level. I wanted to learn a little bit about game physics. I've been playing games for a long time, and I wanted to know about what goes into making those games at work.
What I was not going to do is to go into loads of massive complex equations and build realistic sim-style physics. I didn't want to bring in an existing physics engine or start reading people's blog posts or start copying and pasting big chunks of code into the application. I wanted it to be really a learning exercise for myself.
As I mentioned, I wasn't going to take in an existing code sample for this. I wasn't going to build on Unity. Unity, the game development platform, actually has a lot of physics services built into it, its own physics engine. It's got things like wheel colliders that you can use. I, because the people who come to my workshops and I present to are .NET developers,
they want to be working in Visual Studio. Unity, although you can use Visual Studio, has a very different development environment. I wanted to keep people happy when they're actually working out with a game. This is what I did. I basically went in and I rewrote the physics engine without really thinking too much about what I was doing and without actually doing any planning. The first thing was to get the car stationary on the track
with no external forces acting on the car whatsoever. The second thing was collision detection. I wanted a realistic way where the actual car would collide with the track in a realistic way. Also, when you collided with a barrier, you should actually be pushed back onto the track. One thing I wanted to include that's not in the original game is jump physics. I wanted to have a realistic way
where you could actually jump, and when the actual car landed, it would properly simulate the way that the car collided with the ground and maybe put in some damage simulation to actually get that to work correctly. As you can see, all of the physics is going wrong here. The other thing was loops as well.
There are loops in the game, and I wanted to get a realistic simulation of how the actual car travels around a loop with centrifugal force. Watch the MPH on the car when we hit the earth. The car actually gets to a speed of 44 times the speed of sound, some of the actual segments in this. This was great fun. My daughter loved it.
She kept wanting to have this game with a flying car and have these cars flying around. I find it really funny, just playing around with these numbers and equations and this starts happening, and you're trying to debug. Debugging something that runs at 100 frames a second or 50 frames a second is very challenging to do. I stepped back from there and said,
I did get a bit depressed for a while until I started going around on YouTube and looking at what happens in real commercial games as well. That was Scandia Truck Simulator. I'm not sure what this game is, but there's something going on with the physics. This one's GTA. I thought the physics was good.
I just included this in because there is actually no car. For some reason it's missing out at the rendering of the car. Forza Horizon, one of my favorite games, is this glitch where the car actually can go off the end of the world. You can see that two of the wheels are actually working on the actual ground, but the other two aren't. There's this beautiful section here
where you drive through and it kind of falls through the game world. I'm glad that it's not just me who sees the underside of a game world with the actual car falling and spiraling away like that. I really like the energy that people put into games and physics. One of my favorite examples is this, which was available on Steam.
This was a game called The Next Car Game. Excuse the advert, but it will come up in a couple of seconds. I can skip this. What they did was they put out this kind of test bed application to test the actual physics engine so players could go around and have fun with it. The thing was that this actual test bed application
was actually a lot more fun than the game that was produced out of it. So many people were just going in and downloading this demo to run through the actual physics. The destruction physics that they've put in to actually make it this isn't real world, but they're simulating a lot of the forces on the car in the destruction physics. That's really what they're going for. I think it's a fantastic user experience
to actually see how this works and what happens when you drive through like a mangling machine, all of the bits flying around and doing stuff. The car can still reverse and go through the next one. It comes out like that and bounces around. The engine still works and the wheels still rotate even when the car is in that type of format.
It's really impressive what they can do with putting the amount of energy into working with those formulas. Also, the gaming platforms that are coming out can actually do the sums that make this type of stuff possible. Does anybody know who this guy is? Isaac Newton. It's not James May from Top Gear,
although it does look very like him. Everybody learns about him at school. He came up with the laws of motions and the theories of gravitation. Really famous for that. A lot of the stuff that I've used in the game is based on those laws of motion and laws of gravitation. This one's a bit harder. Euler. You're the first person who's got that and I've done this session a lot of times.
You've also pronounced it correctly as well. Leonard Euler. A couple of things that he was responsible for. One of them is the Euler integration, which is a basic way of doing simulation in game physics. I'll talk about how that works so it works a bit later on. It's not the best way to do it, but it's probably the easiest way to get in and start simulating physics.
When I was reading up on him, another thing that he had worked with is graph theory, which was really interesting because this is now becoming something that's really talked about with graph databases, social networks, Twitter and Facebook and all of the actual relations and how you follow certain people and certain people follow you. All that type of stuff
was something that he was also behind coming up with a lot of the actual ground theory for that. What I started doing was working out the actual forces that are going to be applied to a car. There's a car. We've got, obviously, gravity pulling the car down onto the track. The car's going to be going forwards. We've got an engine which is powering it,
so we've got some kind of tractional force. We've also got some kind of rolling friction. As the car starts to move, this is the friction in the wheels going around, the tires on the road, all of the actual mechanical joints within the car. When the car starts, when you start pushing a car, it is that getting the car to move, the actual momentum
and the rolling friction that you're overcoming. At low speeds, rolling friction is going to be the biggest inhibitor on the car. As the car accelerates, aerodynamical drag is going to overtake the rolling friction. Does anybody know why? Rolling friction is proportional to your velocity.
If you double your velocity, you get two times the rolling friction. Aerodynamical drag is proportional to the velocity squared. If you double your velocity, you get four times the aerodynamical drag. Aerodrag is one of the really big forces on the car. That's why if you accelerate from the difference between 100 kilometers an hour and 110 kilometers an hour,
the fuel efficiency of your car drops off a lot because there's a lot more aerodynamical drag for that smaller extra speed. If your car is designed correctly, if it's a racing car, and this is what they really go into in Formula 1 with their simulations and the way they design the cars, is the actual downforce. You're going to get more downforce, which is pushing the car down on the track,
and that means that you can go around corners faster because the ratio between your downforce and the actual sideways, the centrifugal force, is going to be greater, and that's going to actually hold the car on the track. Formula 1 drivers are really into maximizing of the downforce. Once we've calculated these forces, we can work out the acceleration on the car because, as Newton says,
force is equal to mass times acceleration, so acceleration is equal to the force divided by the mass. The weight of the car is going to determine how fast the car is going to accelerate. So applying these basic laws of motion to, say, a car driving off a barrier like that, what you'd be doing is doing something like this. S equals ut plus half at squared.
Again, this is physics that you learn at school. The displacement is s, which is going to be where you're going to land. U is the initial velocity, and if you're talking about the vertical velocity, that's going to be zero. T is the actual time, and then a is the acceleration. So you can basically calculate, and this is what you do to pass exams at school,
where the car is going to land based on how fast it's traveling, how high the actual barrier is. But you make some assumptions. First of all, you may assume that there's no air resistance. Secondly, you may assume that the earth is flat, which you can do in these actual simulations where you're talking about a small game world. So the Euler integration basically says,
okay, we're going to do these same calculations again. However, we're going to be doing them a lot of times. We're going to be doing them multiple times a second. And you will have a frame rate for your game, which is every time this calculation is done before you actually do your rendering. So what the Euler integration will do is start doing these calculations at multiple times. So you end up with something like that.
And this is where the inaccuracies come in. And I've noticed this in the game that because the XNA for its vectors uses floats rather than doubles, you get a lot of floating point inaccuracies. And if the game is running at 50 frames a second, the car will accelerate a lot faster and go faster than if the game is running at 100 frames a second.
Because you're doing a lot more calculations and you get a lot more inaccuracies in the actual engine. And I had scenarios where sometimes I'd run in a low resolution. The game would be running at 250 frames a second and the car just wouldn't accelerate. So we do need to go in and put in more compensations for that. Again, it's the thing. Are you going for playability or are you going for an actual proper physical simulation there?
Terminal velocity is another thing. Terminal velocity is something that is very misunderstood. The people who really understand it best are skydivers because they need to because their life depends on it. Terminal velocity is basically you get an object and it's when the force due to gravity
is equal to the force due to the aerodynamical drag. And you'll basically reach an equilibrium where you'll be actually free falling at a constant speed. So for a skydiver falling out of a plane in the actual position when they're like that with the wind going against their stomach, they will fall at about 125 miles an hour. The world record for speed skiing
is close to 200 miles an hour. They may have exceeded 200 miles an hour which is 75 miles an hour faster than skydivers fall because the speed skiers go into an actual tucked position. Snow has a very low terminal velocity because it has a low mass compared to its air resistance. So the gravitational forces that load up,
that falls very slowly. So terminal velocity isn't a constant. Things fall at different speeds because of the air resistance. Now if we turn that the other way around, the car will have a terminal velocity because eventually the aerodynamical drag is going to be equal to the force that's put in by the engine and the car won't be able to accelerate any faster than that. And it gets more complex when you start to bring in gear ratios
and max RPM and rev limiters like they'll have in Formula 1. Normally they'll reach a terminal velocity when they reach the rev limiter in the actual fastest gear that they've got. Another thing that we've got to think about is how the car is going to go around corners. Now as I mentioned in the original version of the driving game,
the actual car rotated and I wanted the car to steer. So I started drawing all these diagrams on bits of paper and saying, well, if the wheels turn like this, then we've got a turning and we've got a wheel base. From the actual angle that we've got, we need to calculate the actual turn radius. So we're doing various sums to be able to actually get these calculations working.
And this was, again, stuff that I did with a pencil and paper and just figured out from stuff I'd learnt at school. We're using sines, cosines, tangents to take these various angles and calculate what the various outputs are going to be. So I've got a lot of formulas like that where I'm returning one property based on various other properties
in the actual engine. And what's going to happen as you go around a corner is you're going to get lateral force. The lateral force is going to be pulling the car sideways and you've got to start calculating about how that's going to play in with all of the other forces that are coming into the car. Within the game, we typically have something called a game loop.
Now the game loop looks something like this. While you're playing the game, you're going to get the player input and that's going to be coming from the keyboard, from the mouse, from an Xbox controller. Once you've got the player input, you can actually feed that input into the physics engine. So then you're going to be doing the actual oil integration calculation, calculating all the game physics, and that's going to figure out where everything is going to be during the game.
After that, the next thing you're going to be doing is just rendering the stuff and putting that on the screen. So you're just going to be whizzing around that loop 50 times a second if you're running on fairly decent hardware, maybe sort of 80 or 100 times a second, 30 times a second. And I've actually built the game to run as a variable framework. So it will take into account the actual frame rate time
that we get from the game engine every time it's doing this calculation. Sometimes when you get more objects on the screen, the frame rate will slow down, but the calculations of the speed per second, the car should always feel that it's traveling at the same speed, even if the actual frame rate of the game is going to be changing, which it will do if you've got different things going on.
As you can see, this is what I'm doing. When I actually call into the game and this is X and A code, I'm getting this floating point value, which is the move factor. The move factor will be fractions per second. So if you're running at 10 frames a second, it's going to be 0.1. If you're running at 100 frames a second, 0.01, and so on. I then go into the physics engine and pass in this actual variable.
It does all of the calculations based on that particular move factor. And then we're basically updating the car's position. We have a matrix data structure. And you'll have matrices. You've got them in X and A, and you've got them in Unity as well. It's basically going to describe how the car is displayed on the screen. We call this method to update the car matrix and the camera.
And that will basically give us the position of the car. And then we can actually place the car on the track. Now that's very simplified from what it looks like in the game. It is quite a bit more complex than that. So when I've basically gone through and come up with the formulas, what I did before actually going into the 3D world, because that's where everything weren't really pear-shaped when I actually tried to code it off the top of my head,
I decided to simplify things a bit. So what I did was decided and says, okay, let's start this off in 2D and see what happens when we build a 2D simulation. So this was kind of what I was playing around with first. It's a very simple Windows presentation found application with a timer going in the background.
And what I'm doing is that calculation that I had in the slide deck is basically this here. I'm figuring out what the steering angle of the actual wheels are. And then if we apply some throttle to that, you can see I've got some basic telemetry data that I use for debugging coming out on the bottom of the screen. We can give the car some velocity, and then I can start doing some turns. The wheels actually, I colored it
so the wheels will actually turn red when the car starts sliding. So you can see at slow speeds that we can turn okay. However, as a car increases, if we try to make too much of a sharp turn, it basically slides and it slides out like that. And what I was focusing on this was looking and trying and getting some fairly realistic variables
in the way we actually define the car. So what I'd done here was I thought about all of the actual dimensions of the car. So we've got a bunch of constants. These are going to be stuff that does not change. Now if you're building different car models in the game, you'd be basically swapping out those constants. So you'd have different mass, different acceleration, different engine power, different wheel base,
maybe different friction coefficients if you're doing that sort of thing. And if you're playing Forza, you can go in and customize your car, which will affect lots of stuff in the actual physics engine, affect these constants. I've got the driver input, which is steering angle, throttle percent, brakes percent. I've also got KERS and DRS, which if you're a Formula 1 fan, you'll probably know what that means,
and I'll talk about that stuff a bit later on. Then I've got the variables, the position, which is going to be a point. Then I've got the direction downforce, and I'm using 2D vectors here for velocities and things like that. Now when I was playing around with this stuff, I was kind of taking a mix between, okay, let's do the physical simulation, but really the main thing is how does this feel,
that when I do that, does this feel like the car is sliding around a corner? Does it feel like it's sliding correctly? And I have been playing around with these variables a lot, so it may not be simulated as it should. But I was really focusing on the feel. Now a couple of things I am simulating as well here is the actual downforce.
If we use the drag reduction system, that will basically reduce the actual downforce on the car, make the car go faster, but it also means that the actual downforce will be a lot less, reduces drag and reduces downforce, which means that you are going to be sliding off around the corners a lot more there.
So I was really just doing the simulations to see how that worked. When I was kind of happy with that, I moved on to the 3D world and started thinking about actually getting it implemented in the game. So the 3D gaming, we are going to be going back to school and working with vectors and matrices. However, instead of the 2D vectors,
we are going to be looking at a lot of 3D vectors. And this is the same if you are using X and A and if you are using the Unity. They both have this vector class with these three points. You also have 2D vectors and 4D vectors as well for all the things that you are going to be looking at in the game. So this is fairly simple. You've got a point, it's going to be this on the X, Y, Z axis, and that's going to basically project out to a vector like this.
Nothing too complex about that. And then there is how vectors are used. Vectors are used a lot in X and A for different things. Now, you could argue that a position is a point. Well, a point is just really a data structure that contains an X, Y, and Z coordinate. So they basically use the vector as an actual point as well. And you can think of it as maybe a vector.
It's kind of the distance that you are from 0, 0, 0 in the actual game world. So it can be used for the actual position out of the car. All of the actual items will have a position in the 3D game world. Then you've got the direction. Where is the car facing? Which direction is it pointing in? You also use the 3D vectors for those. These are basically often known as normalized vectors.
So the length of the vector will always be 1. But its X, Y, and Z value will sort of determine which direction that 1 unit vector is pointing in. Things like velocity, the speed, and the direction, which is very important. The speed and direction of travel is also a vector. And then you've got the acceleration. The change in velocity is also another vector.
And all of the forces on the car, like gravity, they're also going to be vectors as well. So what we're doing really in the actual game is doing these calculations. We've got the weight of the car. We've got the engine force. We've got the road friction. We've got the aerodynamical drag. And we've got the down force. And what we're really doing is taking these vectors and doing this calculation to actually just add them together.
And that actual resultant force that we're going to get is going to be the force that's supplied on the car. And then force is equal to mass times acceleration so we can calculate the acceleration on the car. So this is an actual snippet from the game code where I'm using the Vector3 class and saying, well, the force is going to be gravity multiplied by mass plus the engine force plus the friction
plus the drag plus the down force. And that's going to tell us what's happening to the car. This all didn't go according to plan. Some things did go wrong. One of the classic things was getting down force the wrong way around. I forgot to use a minus sign for the actual down force. So down force was up force. So I went really, really fast and then went off a jump. And the car had basically up force on it.
And it just basically took off like a plane and flew off. And then eventually the wind resistance brought it down to the ground. But you can just change a few things around and you're building a flight simulator rather than a driving simulator once you've got those calculations. A couple of things that are useful with vectors that you may remember from school or you may have forgotten
is cross product. So this is basically taking the direction and the up angle of an object and being able to figure out whereabouts the right position is for this. So if your car is going forwards and you know which direction is up for the car, you can actually figure out which direction the centrifugal force will be acting on the car
by using the cross product. And that's used quite a lot in the game. The right direction of the car is equal to vector3.cross passing in the actual direction we're traveling in and the up vector. And a lot of calculations that use that. Dot product is used for taking a couple of vectors and calculating the proportion of one vector
that is acting in the direction of the other vector. So here we're interested in the actual force of the car on the actual track. So that's going to be the mass multiplied by the dot product of the gravity and down. And as the down vector of the car, and as the slope gets steeper, the actual force of the car on the actual slope
is going to be less and the wheels are going to start slipping. So the homebrew physics engine that I've built, and again, this is something that I wanted to build myself rather than looking at how the actual physics engines worked. This is what I did. I basically calculated based on the forced acceleration where the car wanted to be at the actual next frame.
This type of calculation is fairly straightforward. The car is going off a cliff. It's going to be traveling at a certain speed. The next frame position based on all of my calculations is going to be putting the car there. And that's no problem. It's going to be there. However, if we're going along a straight road, the car wants to be there. However, it's not going to be there because the road is blocking it from falling there.
The car is actually going to be there. So what I did then is calculated, well, actually the car is going to be there. This is the difference between where the car wants to be and where the car is going to be. And that difference we can treat as an acceleration. We can basically say the force acting on the car is going to be proportional to the length of that line. And that would allow me to calculate the downforce
on the actual track because downforce and gravity are pushing it down and we're going to reposition the car and then calculate the actual force and that's going to give us the actual downforce, the force on the tires. And that's how I'm calculating downforce. So if we've got a track section that looks like this, the car wants to be here. However, it's going to be here and the actual force is going to be greater.
And I put, looking at the telemetry data, when the car goes at full speed around one of the loops in the game, I think there's 44G that's being placed on the actual car. Massive gravitational force there. And again, it's back to SIM versus the real world. Do you really want to model what would happen if you drove a real car around a loop and got 44G on it? It would break. Do you want that to happen in the game?
Or do you just want to make a game that's fun to play? So thinking about things like that as well. And then if you're going over a crest of a hill, then the car wants to be here and you've got this very little force on here. So certain sections of the game, if you're going over the top of a hill and you attempt to make a corner, the car's just going to slide because there's no real force between,
or very small force between the car and the track. And it's going to take a low bit of centrifugal force to actually make the car slide around. So after I played around in the 2D world, what I did was I went into the 3D world and I was really inspired by what they'd done in that next car game demo.
And I says, okay, well, let's do the same thing where I've got this kind of test track like I had in the 2D world. And again, focus on the actual feel of how the car is going to feel when driving. I spent quite a lot of time watching this, which was a clip from BBC's Top Gear presentation. Again, apologies for the advert there.
Well, they took three high-performance cars and they went out to a beach in Wales and just spent a lot of time driving them round and round in circles in the sand. And I kind of thought the actual feel and the look of the way that car looks as it's sliding around these corners, it would be fun to have a driving game that did that. So that's kind of one of the things
that I was kind of looking at as I was focusing on the actual game engine that I was working on. So going into the actual game engine itself, this is basically, I got a flag here called skid pad, which I can set to true. And if skid pad is set to true, it doesn't render the track. It just basically renders this square. And we actually got the car driving around
on that actual test track. So it looks something like this if I just go in and go to the actual track. And kind of what I wanted to simulate, I have actually hard-coded in, so we leave tire tracks even when we're not skidding. And this is just so I could see where the car has driven.
So the wheels aren't skidding there. It's just leaving tire tracks like it would do in the sand. And then I was saying, well, here's the car actually sliding around. You can see that it's doing a corner slide here. And then I can use brakes, use acceleration, and then basically simulate how the car drives. And I kind of wanted to get happy with that kind of model
before I started focusing on and getting the car to actually run on the track with all of the collision detection and stuff like that. So I spent quite a bit of time trying to get the numbers right so it would actually feel a bit like a car sliding around a track. Now I'm making really simple assumptions here. If you're thinking about going into doing more serious simulations, there's a magic formula,
which I'm not going to attempt to pronounce. But this is basically what a lot of the racing games use. It's a certain formula that somebody has come out with to basically calculate what's called a tire friction curve, which is basically simulating for each of the four wheels on the car how the actual tire is going to slip
based on various inputs that we put into the formula. So it generates curves like these. And you can see the actual code for the actual formula is very complex. There are also C-sharp implementations of this actual formula here if you want to plug them in.
Has the projector gone all together? But that magic formula, as they call it, will basically give you something like this
based on the actual force. That's what you can do. I really didn't want to copy-paste that big chunk of code in and I wanted to stick to something a bit more basic for the actual physics simulations. So what I can do now is basically set the skip pad equal to false. And what that's going to do is to drop the game back
into the regular game mode. And this should hopefully give us the actual physics engine working in the actual game itself. So if I go to play, and I'll actually go on the Azure car and I'll go on to the actual middle track here.
And I think I can switch out to the actual Xbox controller and use that. The XNA driving game does support the Xbox inputs there. So I do have my KERS and my DRS. I'll talk about that a bit later on. So the KERS allows me to accelerate. The DRS also reduces my friction here. So you should hopefully see the jump physics coming into the game.
And I wanted to make it so you could jump through the loops on the other tracks and land like that. Also, if I attempt to drive at full speed around a corner, I'm going to slide off and I'm going to crash. And I kind of wanted to build in that type of physics there. You can see that there's a couple of glitches in here,
especially when you hit the barriers. But even when you're just driving in a straight line, I'm still trying to iron out. And I'm figuring out that this is probably related to the floating point calculations that we're doing in the actual game. So I'm going to try and figure out how to actually iron those out and get the game running a bit more playable. There are certain sections in the game where you will actually fly off the track
if you're basically driving and you hit a jump. There are so many sections where the car will actually leave the track. And I've kind of designed the actual track layouts to make it so there are these sections in just to make it a bit challenging. Incidentally, if you're playing around with the game, one thing I really liked about this game
was the way that the actual track design works. The track designs are basically so for one of the tracks, you've got about 15 points in 3D space. And it calculates a 3D spline and then basically creates the actual track from that 3D spline. It puts in all of the barriers. It puts in all of the lights. It puts in warning signs when you've got corners and stuff.
So you don't have to design the track completely. You can just change the points in 3D space, raise points by 10 meters, and it will draw the entire track going over that jump. So it makes it really easy to do the actual track mods in the game. And I've spent quite a lot of time modding those tracks.
So onto the Curzon DRS. One of the things I'm doing with this game is storing out the telemetry data. So I think I can show you this on, I don't have too much data in the actual website, but on the website itself, if I go to the Red Dog Racing website, we should be able to go into the actual lap data for Alan
and see the actual laps I've driven and select one of the actual laps here. And when you actually select the lap, it's going to show us the telemetry data for that lap. So this is being sampled by the driving game, sampling this 10 times a second, sending messages once a second to the service bus.
This is the same thing they do in Formula 1. They talk a lot about telemetry data and comparing telemetry data and various things like that. They process gigabytes of this stuff every weekend after the actual races that they've done. So this is the speed and the actual damage. You can see every time I crash, the damage is increased on the car and the speed will decrease. Here's the actual driver input
showing the steering, the brakes, and the throttles and so on. Now, this is simplified telemetry. The physics engine that I'm working on, I've included the kinetic energy recovery system, which is kind of like a battery system that they have in Formula 1. So when you accelerate, you can press the curse button, and that gives you extra horsepower. Your car accelerates more.
When you come into the corner, it's kind of like a Honda Prius. If you use the brakes, it uses a generator of braking to charge up the battery. So you'll get the battery charged up. You can go around the corner and then accelerate out of the curve. I did that for a couple of reasons. Firstly, a lot of people playing driving games don't use the brakes, which is a really bad idea because the lap time is really set by effective braking.
So it encourages people to brake. Also, it puts a bit of a strategy into the game. When do you use curves? When is the best place to actually deploy the curves to accelerate the car? And comparing the telemetry data between two different laps is going to allow you to analyze that as well. I also put the DRS in as well because they've got that on Formula One. That was to make the cars go faster,
reduce the aerodynamical drag, and also reduce the downforce. So I've basically put those in the game, and you can see that when I was actually playing the game, those two actual forces, and I'll basically show you how that works. So the curse system has this battery you can use to accelerate, as I mentioned, and then when you brake, it's going to charge up, and we see that graphic on the screen.
DRS system. On a Formula One car, I've done this really cheesy diagram here, but basically what happens is you've got this flap that does this, and it changes the downforce and the aerodynamical drag. It's quite a small effect in Formula One. I think they get something like 17 kilometers an hour of extra speed, so I've really exaggerated the speed effect that you will get in the game
based on using the actual system like that. So I've talked a lot about downforce. One of the things that's always astounded me about Formula One physics is that the downforce on a Formula One car traveling at full speed can be as much as a force. I mean, forces are measured in newtons, but the force is equivalent to about 2,500 kilograms.
The Formula One car, I think the minimum weight is something like 750 kilograms. They maybe typically weigh around 800 kilograms when they've got a bit of fuel in them in the driver. So that's going to mean that the actual downforce on the actual car is far, far more than the actual weight of the car. So that's going to be really what's keeping the car on the track
as we go around the corner. Theoretically, a Formula One car could drive upside down on the roof because there's so much downforce above a certain speed. Never happens in real life, but when they go to the Belgian Grand Prix, when they're driving up a corner called Eau Rouge, when they go out the top of that corner, there's actually a negative 1g on the actual driver. So if it wasn't for the downforce,
the car would fly off the track. If the driver wasn't strapped in, the driver would fly out of the car as he actually went around that corner because there's so much downforce pushing it down. So it must feel incredible for the actual drivers driving the car. It really blows my mind how they can do this. When you think about the size of a wing on an aeroplane that requires it to take off, and then you look at the size
on the wings of that car that's producing 2,500 kilograms equivalent force down on the car with these tiny wings, they're really trying to make this as effective as possible. So we can't do this in real life. We can't drive Formula One. The car's upside down. However, in the simulation,
I did add the code so that we can turn the game world upside down. I just wanted to do this to actually test if the car would stay on the actual track because of the actual downforce. One of the things I'm going to do with the track mods is I'm going to mod the track so there will be a section of track that goes upside down. So you have to drive at a certain speed on that section of track if you're going to actually stay on the track.
So what I should be able to do is to go in and start the game. I'm going to select the beginner track here. A couple of other controls that I've put on the Xbox is on these buttons. I can actually do that with the game world and move it around here.
So let's just see if I can get up to the appropriate speed. There is a fairly straight section of track where I should be able to rotate the game world and just see if we've got enough downforce to stay upside down. So let's give it a big boost on the actual DRS
and then just see if we can do this. So we are driving upside down now and if I do crash or if I do break eventually we're going to fall off the game world and it is going to actually do that. We can turn the game world back upside down and get back onto the track again. So I would really like to put in that section of track.
I've not seen it done in a driving game where you can use downforce to drive upside down but it must be quite a fun thing to make that stuff happen because it would actually happen according to the laws of physics if not according to the laws of the road.
Finally, one of the things that interests me is the top gear and the crazy stuff they do with cars. Did anybody see this episode? They had like a Porsche and a VW Beetle and they did a drag race between the Porsche and the Beetle. Now obviously the Porsche is going to win the drag race. So what they decided to do to make things a little more fair was to actually take the VW Beetle one mile above the desert
by helicopter and then drop the Beetle and see if the actual Porsche could complete the one mile section before the actual Beetle managed to land on the ground. There is a clip of YouTube basically showing that happens. So if we go on to... Yeah, I did bookmark it here, yeah.
So this was Richard Hammond with the actual cars and then he starts talking about physics and how all the physics means. Again, this is all this stuff about terminal velocity, the speed of the Beetle and what the acceleration of the Porsche is going to be. Again, if it is theoretically possible for this to happen. Then they go and test it for real world. I'm kind of a bit concerned that he's wearing a crash helmet.
It's not really going to be that much protection if the car lands on his head. But basically they went through and they did this at this test. I kind of thought, well, how can we make this happen in the game world? So what I did, and I can switch back to the workshop version of the game,
was I decided to make that happen. I actually did this this morning in the hotel room. So I've basically built this Top Gear test car which is an actual class. I really wanted to show a bit about how that Euler calculation works because in the actual game model itself there's so many different variables going on that it's kind of a challenge to actually show that code on the screen. But this is a bit more basic.
It's just a falling object that we're going to be simulating. So again, I'm starting off with my constants. We've got an actual friction coefficient. We've got the mass of the car. We've got the gravity, 9.8 meters per second. We've got the upper direction and the forward direction. We've got the position where the car is going to land. We've got the height in meters where we're going to drop the car from.
And we've got the actual track sector in the game world where the car is going to hit the track. And that's basically used to calculate when the car hits the track, are we before or after that particular track sector. That's going to decide if we've actually passed the Top Gear challenge or not. Variables. We've got position, velocity, and then sort of whether the challenge is complete. And what I'm doing really is basically when we create a new instance,
we basically put the car at the full position plus the height. And again, these are Vector 3 calculations I'm using. So I'm figuring out where the car is going to be when it starts off. The velocity is going to be zero and challenge complete is going to be false. So this happens when we start a lap. And then we've got the actual oil app physics method here, the update method.
And again, this is kind of what I was talking about on the slides where we're going to be getting the frame time. And the frame time is going to be in fractions of a second. So the first thing that we do is we calculate the aerodynamical drag force on the car. And remember, that's equal to the velocity squared multiplied by the drag coefficient.
Now, because these are vectors, the drag force is going to be a negative force. It's going to be slowing things down. So I take minus velocity. Now, this is a vector quantity. Now, because we're squaring it, we multiply it by the scalar quantity, which is the length of the velocity vector, and then multiply it by the actual friction coefficient. So that's the drag force, the aerodynamical drag force.
We then figure out the gravity, which is equal to mg, mass times the gravitational coefficient there. And then we can actually figure out the resultant force on the car, which is this vector 3 here. Acceleration force is equal to mass times acceleration. So again, this is school kid physics. We work out the acceleration. We then work out the velocity by adding the acceleration to the velocity
and then taking into account the frame time. So the change in velocity is going to be a lot smaller as the frame time gets smaller. So that's going to mean it's going to fall at the same speed if the frame frame varies. We do the same thing with position. We recalculate the actual position there.
Okay, so let's just see if this is going to work. What this should hopefully simulate is that same challenge that we had on top gear here. I'm going to see if I can do this, because it was quite a challenge to actually get this working. So let's go into the options. I'm going to drop this. I'm going to take off post screen effects, because that does all of this lens blur
and stuff with the sun reflecting off objects, which kind of means that it's kind of challenging to actually see the falling car. But I'm going to go and select the Windows Azov car and then select this track here. Now what you should see is a small dot in the top of the screen,
which is the actual car that's falling, and that car will gradually fall down to earth as I'm actually driving around the game. If I don't crash, I did actually crash there, so maybe I'm not going to actually make the challenge this time. You can see that the car is getting a bit closer to the earth, and it's looking like I'm not going to make it this time yet. So the actual challenge failed.
The car actually had hit the track before I got to that section of the track there. So let's just see if I can do that again and actually make this actual happen and succeed. It is the last session and we could be here a long time if I don't manage to nail it this time. We'll concentrate a bit more and try and stop talking as I do this.
This is looking better. I'm going to do that one more time. Sorry about that.
This is looking better. Yeah, I think I managed to do that.
Thanks for that. I think there's an opportunity there. I kind of like those Top Gear challenges. Is there anybody doing a driving game where the driving game is based on doing Top Gear challenges? I think that would be good fun to do to have all this crazy stuff in there as a good marketing opportunity. So just rounding off the session,
I've talked a lot about my hobby project with physics and playing around with stuff like that. Game development is great. It's really, really creative. It's great fun to work with. There are marketing opportunities to be made there. However, the people I've talked to who've been involved in the games industry have said it is a lot of hard work. There's maybe not that much money unless you're doing it.
It's just out of interest. Is anybody working in game development? Solid game development here. Basically, I think hobby projects. It is good stuff to play around with. I think it's a good way. I do a lot of training. One of the things I was thinking of doing is going to schools, universities, and talking about physics and games and how this stuff relates.
It's good fun to play around with. It is pretty addictive. You can spend an unhealthy amount of time focusing and playing around and trying to get this stuff to work. It's great fun in a way of being able to build up your coding skills. I do have a few more resources if you are interested in looking a bit more into the actual game programming,
game development, and that type of thing. First of all, the Plural site that I did, this isn't really related to the game development itself. It's more related to how we can integrate a game with cloud services like Windows Azure. There I talk about using blob storage for the ghost cars, table storage for the actual lap time data and telemetry data,
and how I can basically queue the telemetry data and get that into the cloud for processing. I kind of think that telemetry and the Internet of Things is going to be the next big thing. There are going to be a lot of scenarios where I think what you can do with telemetry data in a Raspberry Pi and a fleet of taxis being able to actually push telemetry data into a cloud-based service using some kind of a connected device.
Coffee machines, heating systems are going to be automated. People are doing hobby projects that do home automation, integrating with cloud services. It's the same techniques as using in the game that I'm talking about there as the actual telemetry processing. This guy, Gary Simmons, at gameinstitute.com,
he's done a course on how to build a racing game in Unity. If you subscribe to that site, and it's currently, I think, $49.95 to actually get a year's subscription to that gaming institute, which is a really good price, you actually get the source code for that game. The quality of the videos that he's done are incredible. He's talking about how the driver AI works,
how the physics works. He's based on the Unity physics engine, so he's using all of the Unity wheel colliders and all that type of stuff. I think I record my own courses, and I was really impressed by the way that he goes out with a film crew to a motor museum and does a lot of talking about the actual theory behind it, behind working with the game. There is some really good stuff there.
You also get, if you want to work more with Unity than XNA, the actual Unity source code to that racing game that you can customize and experiment with and change as you want to. Thanks very much for listening. My name's Alan Smith. I'm going to be around for a bit. I've got to run off and catch my flight, so unfortunately I won't be around this evening. If you do have any questions about Windows Azure, about games, about XNA, physics, or Formula One,
I will be hanging around for a few minutes. Thanks very much. Enjoy the evening and the rest of the conference.