People often ask what is the hardest part of a new app or game.
The idea? , the research? – no it’s starting with a blank project and getting typing, much like writing a book I guess.
So linking back to my last post (Here) I have decided to do a pseudo 3d racing game.
Firstly why not a real 3d game, well I could fire up Unity , spend about $500 and download 3d track generator, a full racing game engine with physics, AI etc. and have a drivable race going in under a day.
Well reasons are
1) There are thousands of games just like that, it will not stand out.
2) I wouldn’t know what was happening under the hood so could never really take it anywhere.
3) I don’t want that type of racing game!
So anyway back to what I want to create.
Having a heavy cold last week meant I got to do alot of research.
I found this excellent page on Pseudo-3d engines (Lous Pseudo 3d page) and decided I wanted to do true 3d projected segments. So basically a true 3d road but with massive constraints. This will give me the flexibility I am after.
This linked me off to this page (Code inComplete – build a racing game) where someone has made this kinda engine but in Javascript. Was an interesting read and has source code that was good to take a look into but as Javascript works on a pure canvas I have decided to use Gideros it is not totally relevant to me.
I then found this post ((Gideros forum) where someone had attempted with some success to bring that to Gideros, he had numerous problems by going down the wrong path at the start but proved it was sort of possible and once again even had source code (Here) but after taking a look at the code I decided it was not a good starter at all, I guess all of us programmers have different styles.
So I plan to basically do the maths, work it out and write from scratch, if I use anything for reference it will be the Javascript.
He did hit the retained mode issue I thought might be an issue, but honestly I don’t think it will be that big of an issue.
I did think about switching to Monogame or Cocos2dx or something then decided I could not be bothered in learning a new engine and will only do that if I need to. The beauty of Gideros is that it is opensource, so if I need to add some new ‘special’ commands that go into ‘C++’ to do some major maths/hacks whatever for this game I can 🙂
The key to performance is precalculate !
So basically I am at the blank piece of paper stage.
I know I will first create
1) An level overlord class, this is what will control an entire level. Passing in different parameters will make different levels.
2) A road rendering class, this will render the entire road as a single mesh
3) Then add bends
4) Then add hills
5) Then add parallax background
I know up front my game will need to do (in no order)
a) Between 1 and 5 lanes and move between those number of lanes whilst racing
b) Have other cars and road side scenery
c) Tunnels
d) Rain
e) Hills
f) Bends
g) Tyre smoke
h) Puddle splashes
i) Crash animations
j) Night mode
k) Online cross platform score table
l) Mini physics for accel, deaccel, grips and collision (all the examples I found used linear methods which are not right)
m) in game display
(This list could go forever!)
Rest of it all is fuzzy for now, but having some sort of list helps make design decisions as you go because you are writing routines to expand rather than be tight. I always believe in get it working, then optimise, anyway time to start coding for the day and see how far I can get in one day (If I get a straight road it will be a surprise).
Update 1 (1.5hrs in) – I am following the formulas in the purest form and there is alot of floating point math computations taking place each frame – an unnecessary amount, this is not good, double so in Lua. ALOT though can easily be pre-computed, just took at look at the javascript example and wow for each (width/2) is being run 2000 times – lookup anyone?.
But the principles given on the Pseudo 3d site do seem sound and are a perfect starter but not optimised. Plan is to get the entire engine running and then measure it, then go backwards and sort out this pile of unnecessary runtime maths.
So to add to the list
n) Precompute a vast amount of the maths.
But for now I am going to keep all the maths huge, nasty and slow – I am developing on a i7-5820K @ 3.30Ghz with 32GB of DDR4 RAM, so until I need to move to target device I think we can handle this level of maths 🙂
After 4hrs of writing I got my first render under keyboard control, it speeds up, slows down, goes left and right but it is tiny for some reason !
Ok, getting closer
Fixed !
This is fully working and drivable and obviously 60fps- I was hoping to get a car sprite added and moving into curves but I guess that is for next week now before tackling hills. Not sure why it took longer than I thought, but I know I have 90% of hills and curves already in place so maybe that is why.
In my spare cycles this week I will get all the car anim and background graphic renders done.
Here is a video of it going, a bit bland but once I get the car and background in place it will look totally different.