Games Project Hovercats (OFFICIAL TITLE FINALIZED) - Procedural arcade racer

downloading it now, thanks.

EDIT: after the download, I'm now at the screen where it asks me to install it, everything looks good until i realize it wont let me press "install". I've followed all the instructions, so I don't know what's happening here. Developer mode is enabled and so is "Unknown resources".

 

Ok... what phone/tablet do you have?

 

Yea, the controls will be updated soon with an option to use on-screen ones instead. As for the menu screen... did it look like a tiled image? if it did, then that's probably the stupid bloom effect not setting the right format again... (It did that on one of my friend's devices!)

Either way, weird menu isn't your fault, it's actually the wiiBloom effect I built!

 

Ok guys, new beta build:
ChangeLog:
VISUALS:
- Removed bloom effect from main menu: This change is to fix the main menu being corrupted on some devices. Still yet to find out what's causing it...
- Removed shock-wave distortion on explosions: these were lagging...

- CORE:
Changed collision detection method to continuous dynamic: Whether this adds a speed gain or not is uncertain, I will have to test this.
- Track Generation parameters changed: Now item boxes don't spawn as much. This is to prevent too many multi-item pickups at once.
- Fixed frame rate adjustment: I am preparing to try and fix up discrete collisions, and hopefully, this results in a faster game. Result fixed frame-rate now: 60fps (30 before)
(This should also result in smoother motion when using high-framerate mode)
- Some other minor adjustments to the physics: these were meant to correct the new fixed frame-rate breaking some acceleration values, causing them to go up to top speed too quickly!

ISSUES:
- High CPU usage on some Intel Atom systems (PC Only): This causes the game to periodically lock up then start again, of which is pretty off-putting. (This is on default "no fancy stuff" settings of course) The cause is that the CPU gets maxed out, and windows stops it from doing anything. A temporary fix is to set the affinity to "High" of which stops the locking. (The framerate drop that proceeds it still occurs though)

The cause could be collisions being continuous, but it only seemed to appear also after implementing multi-item pickup... (In other words, some instances of this bug screams GC hang-up issues... again) The issue is hopefully remedied somewhat by changing the item generation parameters.

Jet Rat Speedway Ver. 0.4.5:
LINK: https://drive.google.com/file/d/0B2tqYgzg1_lWREdGellCTU5QS1U/view?usp=sharing
File Size: 27,334 KB (26.7 MB)

Enjoy! For those who got the corrupted screen bug, let me know if this update fixes it.

 

Actually, good question; does your phone/tablet have an accelerometer? (Most devices should)

EDIT: For those reading this in 2016, that's actually a standard sensor, the gyroscope isn't. I don't use that though.

 

Change-Log:

VISUALS:
- Further tweaked the explosion: Now the debris that files out is less, and particle collisions are no longer used. This may help lag caused by these.

CORE:
- New engine sounds mixed: I did a good deal of googling to find a good source for producing engine sounds manually. I ended up mixing THREE different sounds (a mix I did for the first sounds, white noise with the EQ modified, and a 2000 Hz saw-tooth/sine wave) together to get the desired sound. (It sounds AMAZING at the start of the race when the engines are firing up! )
- Mixed and added a countdown: Now an announcer shouts "3! 2! 1! GO!"
- Hover engine script tweaked so that engine noise gradually rises up at start: Makes for a very tense countdown!
- Countdown now starts at "5" rather than "3:" This was changed so that the startup sequence sounded right. (On 3, the "engines" hadn't spun up fully yet, and sounded ridiculous when the jet rats took off!)
- Switched to discrete collision detection: I have made a big step here, as it may allow a better margin for adding additional features without breaking game performance.

ISSUES:
- (Possibly Fixed) High CPU usage on some platforms and devices.
- (Minor Regression) When boosting, collision detection fails in some places: This only really occurs a lot in the forest environment... maybe the road should be widened a bit? (The rocks are very close to the road!)

A new playthrough will hopefully come tomorrow sometime! And hopefully by then, I will have the new control schemes in!

Also... a mini-poll for everyone; Do you think I should start offering standalone beta builds too? The reason I ask this is because I will be releasing this game for PC at a later date. (Hopefully with enhanced visuals! )

 

I think I found the issue; is device administrators activated on your device? there's a very small chance that your phone/tablet is locking you out because you're not authorized to install anything. (Odd, I know, but apparently, device admins can do this)

 

Thanks! Now it works, I was able to get it to install easily. I'm going to try it out now.

EDIT: Okay, I've tried out all levels, and here's my feedback.

I think an option for tilt sensitivity would be good, as at times it was too high for my liking. I'd also suggest an option to turn up render distance because one of my main issues was that I was driving really fast but kept crashing into everything because I couldn't see anything 20ft in front of me. Reminded me a lot of Mario Kart, which is awesome! On the graphics/performance side of things, I was getting a solid 60 FPS on any level without any of the settings turned on, and around 30 or less with them all turned on. I'm using Android 5.2, and a Galaxy S4.

Overall I found it entertaining, great work!

 

Yep exactly what happened...

 

Ok then, will take note of those. Yea, I know the render distance is terrible in some places, but that was the trade-off I had to take to get it to run on my Pendo Pad smoothly. (It can't handle too many polys at once, and the forest is notorious for high poly counts!) I'm taking a guess the forest was one of the most difficult? I ask because that's the stage ravaged most by the distance fog!

So... current todo/coming soon list:
- Control schemes. This will be in next beta build.
- Accelerometer Sensitivity: Maybe in next beta...
- Acceleration type setting: This will have two modes; on/off toggle and a pulse button for more precise throttle control. (Will come with control schemes, and will be in next beta)
- Customization. This includes rat fur and eye colors as well as jet bike customization and selection!
- Two new environments: A volcanic environment and some sort of beach. (Not sure about the beach, due to how the track generator works!)
- Render distance adjustment. Also coming in next beta.
- A more distributed rendering calculation for reflection mapping. (Currently does no time slicing, which is the reason for the performance drop with this on!) Hopefully coming in next beta!
- Online and (hopefully...) local multiplayer: This one could be tricky though, as I haven't really used UNET before!
- Good music tracks: Hopefully today I'll have something for this one!
- Finalized mode layout: Modes I have considered; an arcade grand prix, battle mode, instant action, online grand prix/battle mode.

That's it for now guys!

EDIT: Also, impressive phone!

 

In that case, I want device specs, as that may reveal the component that's doing it. (I will see what I can do about grabbing device specs off the other device that had this issue as well)

 

Yes, forest was most definitely the hardest.

 

They kinda suck, thats probably the reason.
CPU: Dual-core 1.2GHz MSM8610, 512MB RAM, thats all I could find, it should be enough though.

 

Again, FuzzyQuills, I'd be very interested to check out some of your code for unoptimized stuff that could be made better, all for free. I enjoy doing these kinds of things. I'd like to see it succeed.

 

Heh... in that case, I can give you the entire codebase to look at if you like. I've optimized where I can though, I think my only bottleneck is a lack of object pooling (result: Instantiate/Destroy is sued a fair bit for items and explosions) for things like items, explosions, etc. (This is simply because I don't know much on how that works... )

And on the flip side of the coin, I like optimizing shaders...

EDIT: Oh yea, a warning; if I do give you the source to look at, it's a bit of a mess...

EDIT2: Another thing is that I will be going offline soon, once I'm back on, I will send you a PM.

My Pendo Pad's specs are similar...
(Except for the RAM and CPU type, I think mine has 1GB in it, and an Allwinner A10)
Any GPU info you can provide? I would recommend either CPU-Z or something else to find it. (Beware however, CPU-Z does have ads, so turn off your data connection first!) Reason I ask; the GPU is usually the culprit when it comes to bugs like what you found. (I have confirmed that for once it isn't mali-400 devices with the issue)

 

Sure, that works.

 

ChangeLog:
VISUALS:
- Changed the main menu up a bit.

I also fixed the demo track geometry up a bit.
- New in-game UI:

The UI now shows your speed and engine power. (They're more there for convenience than usefulness... Speedo isn't quite accurate yet either)
- As a result of the new UI, moved the rank indicator to top-left.
- LATE ADDITION: current build now has a higher draw distance! In affected levels, I upped the fog distance to allow for better visibility, a factor that is of utmost importance when going at high speeds.

CORE:
- Control schemes implemented! Now there's a dropdown (or more a drop-up, it opens upwards for some reason... ) that allows you to select whether to use steering arrows or the accelerometer (named "gyroscope" in the options menu) Also, acceleration is different; the green button in the circle above will turn light-green when accelerating, and be dark green when it's off. Pulse button above it doesn't work yet though. (See "issues" below for more details)

As an added indicator, if the gyroscope is on, the game will show "using gyro" instead of showing the arrows.

- Sensitivity adjustment: As temporary compensation, I reduced the sensitivity a little bit to make it easier to control using the arrows. (This will be further amended with a sensitivity slider soon)

- Switched to using CrossPlatformInput for input calls. This was needed to get the control schemes to work.

ISSUES:
- The sensitivity can be a bit high at times when using the arrows: This will be amended with the sensitivity slider, of which will appear next beta build.
- The "acceleration pulse" button (i.e. manual acceleration button above the normal one) isn't working yet: This I think is due to a conflict with the auto-control, and will be fixed soon.
- Speedometer doesn't show a realistic speed yet: This one will require some math to fix... *cracks knuckles*

COMING SOON:
- Extra environmental elements: This one keeps popping up because I haven't implemented this yet. (Been too busy with other aspects to add it in!) When it is put in, the desert should look better than it's current generic appearance.
- Multi-coloured rats: For rat genetics nuts; I will be using actual rat coat patterns for reference when I get around to making these!
- More bikes: What's a racing game without variety in the vehicles too?
- Music: I'm now working on this one. Hopefully I can get something decent out soon. (Maybe even next beta, don't know how long it will take)
- Two more environments: A volcanic base and a beach base will be coming soon. That leaves ONE slot left to add in one more environment. Feel free to throw some ideas around for this one!

 

A little progress report. Since working on a title for the unity dev contest 2016, I haven't touched this project much...
However, now that the deadline's fulfilled, I can now start working on it again. And alas, I will show what I did do when fiddling around with getting a good "lava in the cracks of rocks" effect...

For those Pikmin fans out there, yes, I admit that looks a bit like a bomb-rock... The model is a mesh I built myself, and the lava uses Blender Cycle's blackbody node to great effect. The bomb-rock I used for inspiration for the test rendering.

Hopefully, I can get lava this pretty into the game without slowdown. I was also considering re-doing lighting to make performance a bit better on some devices. (If anything, Unity 5.3.2's the real bottleneck, due to performance regressions on android... again)

Another challenge I might run into is making the primary lava pool at the bottom always visible, since the track generator, to avoid loops overlapping, has segments going into the sky!

 

This is why I quite trying to make 3D mobile games, to much work.

It looks really cool though, I hope it runs good on the performance side.

Looking forward to seeing more!

 

are the tracks randomly generated? if not that would be badass and replayable till death

 

Yes... Of course, I can easily make pre-built tracks, since all I do is have a script layout 5 types of segments for it. (It has one segment for the start, three for straight roads and turns, and an end segment) This gives a fairly good level of tweakability, such as number of turns, number of straights, how long the track goes for (actual track length can change a little from the number set though, due to the formula I use to work out the randomness in the tracks)

I will probably be doing pre-building for any type of grand-prix mode. Otherwise, it will use several levels of generation complexity to challenge the player in such modes. As

 

What about verticality? Also, any multipliayer support (even local would be fine)?

 

I definitely have multiplayer planned for this game. In fact, it's purpose is to give me a good, fun, playable testbed for implementing UNET properly for the first time.

And what do you mean by verticality? If you mean tracks on their side... that could need a bit of re-coding for the hover engines! I could at least make loops usable. (atm, the jet bikes can only rotate on the local Y axis, of which increases stability, but then... )

 

no like tracks going verticaly up or down. for the jet bikes, you could raycast downwards and increase the distance based on the RaycastHit

 

Ah, that sort. I could, maybe... the main limit's the fact that I don't have any way yet of detecting if two roads cross each other, of which can render the game unplayable if the geometry has walls in it. But, for a straight segment, it could work.

There's only one small thing; the current jet bikes can fly off things, but an elevation that's too small is counteracted by the hoverbike's grip on the track. (A measure I put in to stop PhysX adding "realism" to my bikes!) I use a raycast downwards to repel when too close, then drop down if too high up. If it's way high up though, the grip no longer works, hence the need for a high ramp to launch off!

 

i feel like your wasting cpu on physics, when all of the hovering and grounding could be coded instead.
what about tracks that loop?

 

I've actually been thinking about this one very very hard... What I would need is some sort of algorithm where the last destination point is the starting point. (Currently, the tracks are one lap, and have a start-end point, kind of like the track layout style some of the old rally games had) Or I could do some visual trickery, and have a portal as a lap line, showing the next track segment and have the cars/bikes teleported to a known point, but that would probably be way out of a mobile device's league.

As for wasting CPU... That was why I was considering integrating bullet. It's a beautifully written physics engine for those who can use it. (I am actually using it in an experimental game engine I wrote) Currently, the bikes use one raycast to repel/grip the track, and accelerate/deccelerate (and turn) all by modifying the velocity directly, for better physics stability.

Of course, if you think you know a better way and wish to share it, PM me on it, I wouldn't mind having a mini-discussion on this stuff, especially when it's going to go towards having a better performing game. (I find the bottlenecks are actually in my rendering pipe, which is typical Unity stuffing things around... )

EDIT: and additional issue with the looping tracks is that the tracks themselves slowly rise up into the sky. re-modelling the mesh would obviously help, but then...

 

UPDATE!!!

It's been a while (a LOOONG while) since I last posted here, but today, I've got some things done!
So... Latest changelog:

VISUALS:
- Rats now have animations: Before, only the start line showed an animation on them. Now if a rat gets hit by an item, they'll lose their grip and climb back up. This is purely an aesthetic change, and doesn't affect gameplay.
- Track generator now properly batches the track segments: I finally got sick of seeing some of the stupidly high draw call counts, and did something about it; now the track generator batches lots of track segments together, improving performance. (Nearly a whopping 85 less draw calls in the futuristic level!) This also unintentionally boosted rendering of reflections a little bit, due to it only capturing level geometry.
- Internal resolution now sets itself to 640x360 instead of the native resolution of device: This is purely a performance increasing change. I will be adding a native resolution toggle to the options soon.

CORE:
- Upgraded project to Unity 5.3.4: It's actually performing well now!
- (May not be relevant to mobile...) Added proper Xbox360 pad support: now the pause button on PC builds work as intended. (Reason it may have not before was due to the fact that I only just got mine for PC gaming, and the button mappings are so weird on them... XD)
- In PC builds, pressing start at the main screen with a controller (or pressing Esc on the keyboard) takes you to the main menu.
- Unless this was mentioned previously, the physics for the bikes have been changed: Kind of like F-ZERO GX's physics, the bikes now "stick" to the track, but going over a sharp enough ramp with nothing behind it will launch the vehicle. This helped get rid of some collision detection problems.
- Occasional High CPU usage lockups on Intel Atom CPUs no longer happen: This was actually fixed by upgrading to Unity 5.3.4, which must have fixed whatever was causing it. The device I tested it on has also gone through some odd things lately...
- Switched to using OGV files for cutscene at start: This was to get around Apple's BS decision to stop supporting Quicktime for Windows...

ISSUES:
- Control scheme for no gyro accelerometer still too sensitive with the steering arrows (And STILL no gyro slider... :-/ ): They can be used quite lightly however, I'll leave beta testing to prove if this is needing a fix.
- GUI alone eats up 16 draw calls: I have NO CLUE why Unity isn't batching the UI properly, and thus, I'm planning a redesign for the interface to be less heavy.
- Reflections are still heavier than they could be: Granted, it is rendering at 1/4 the max framerate, but it still renders them all at once. I'll be putting a sequential rendering of all the active reflective objects soon to remedy this a bit.

UPCOMING CHANGES/COMING SOON:
- Speedometer will be removed: There's no real reason to have one there... XD
- Extra track elements: This one's still in the works, but being that I have been at Uni, to utilize time better, I've had a bigger focus at the core game rather than visuals. (Not to say this won't affect the game though; the upcoming lava environment might have a surprise or two!)
- Upcoming new environment: I will be starting on the volcanic environment soon. I also hope to integrate extra track elements at the same time, as I go an idea for this environment that would need them present to work well.
- Possibly a new power-up: I got an idea yesterday for a power-up... it's going to be literally a piece of cheese! The way it works: it's a small catch-22 when you suddenly find yourself with a piece of cheese after picking up an item... should it be eaten or tossed away? If you toss it away... Other opponents won't be able to resist temptation, and slow down their bike to eat it diligently. If however, you choose to eat it... you'll slow down for a few seconds! However, after you finish eating, there's a big comeback you make...

1. if you picked it up off the track, you'll get a normal speed boost after finishing the cheese.
2. if you chose to eat it when you got it from the box, you'll get a speed boost that's two thirds longer than a normal boost!

So, in the long run... maybe stopping to eat is a good idea after all! Not a good idea though if you got the food off the ground...

- GUI design planned: This is due to the current one taking too many draw calls. I also plan on changing the "buttons" control scheme, as it's not that good atm. (And an automatic button might confuse a few people...)

And that's it for now. Being that I'm typing this from an old laptop, I won't have the next build up right away, but I will put them up later. This time round, I'll include a PC build!

 

Changelog:

VISUALS:
- GUI re-implemented:

Behold the new clean UI! Note that the touch controls are turned off, due to being in standalone player mode.

Now it's much cleaner and nicer to look at. It also reduced UI draw calls to about 3 instead of 18 like it was before. The touch screen controls are next on my UI to-do list, so stay tuned!
- Removed speedometer and power level meter: There was no reason to have them there, and they were contributing to the mess that was my previous UI.
- Removed animated FuzzyLogic Studios splash: I unfortunately had to let go my animated splash screen for standalone builds, due to a crash that was only occurring in the Linux player. (I tracked it down to the movie texture functions causing a SIGABRT when they were called, I am going to file a bug report on it soon. Android was unaffected by this crash, as it uses Handheld.PlayMovie for it's splash screen)

Likewise, if this crash gets fixed... it'll be coming back. For now, a screen similar to Miraien Tournament's initial screen is used as a placeholder. (Android might get this too, but I'm not sure yet)
- Item window transition changed: After constantly running into positioning bugs related to the GUI resizing on player start, I ended up changing the transition to fix it. Now the item window uses a scale-based transition instead of a position-based one. (It actually turned out really nice and unobtrusive) No more scaling issues on weird aspect ratios!

CORE:
- Nothing here really... Item and AI balance changes will show up later.

ISSUES:
- Item balance is a bit wonky: Sometimes, players in first get a whole ton of bombs, making it unfair for the other players. I'll be adding balance changes soon to fix this, along with a little bit of rubber-banding from the AIs... they're too easy atm, and it's easy to implement a speed-based rubber-banding to help them catch up.
- There's no way of turning off low-res mode yet: As a result, the game fires up at 640x360, regardless of the target platform. I'll be adding a switch soon for both mobile and PC when I get the chance.
- Shaders are due to be optimized again: With so many polys at times, the lighting calculations are a bit heavy now, despite being per-vertex. Next post will be detailing the changes I may be making to the game visually to help it along on low-end devices. (My mother's phone runs the game fine, but my chinese tablet is a bit too laggy at times...)
- Reflection script is due for optimization: This is due to it rendering all the views at once. I did find that having only one visible's good though, so a 1-reflection-per-frame update may be the only thing I need to fix the lag.
- (Caught during testing a while ago) Sometimes, loading a stage results in an infinite loading loop: I'm not sure what's causing this, and it only seems to affect release builds... I think it might be a failed async operation, but chances are, some time-scale-changing code's messing up... EDIT: This may have been a corner-case unity engine bug, as it no longer exists in 2017's new builds.

 

Rubber Band AI incoming. It's in a working state actually, I'm currently balance-testing it and making adjustments, we don't want a repeat of Mario Kart 64, do we? that, and they're doing some weird stuff at the start line sometimes...

I am implementing the rubber banding AI now, likewise and it works well, apart from balance issues... Let em explain how it works:
Essentially, AIs have two variables that affect their speed now: their own position in total, and their position relative to the player. For this I have four states that are smooth-damped between each other, depending on the race conditions according to them. (My local two-player doesn't take the second player into account yet however... that's going to take longer to implement once I put in a split-screen option for standalone builds)

Here they are:

• State 1: I am in first, I will become a bit slower for others. I will especially slow down for the human to make things easier for them.
• State 2: I am a higher rank than the human player, but I am also falling behind everyone else... I shall keep my speed low enough for the human, but attempt to beat non-humans.
• State 3: I am beating my AI friends, but I am being beaten by the human player, let's speed up a little to eventually overtake them
• State 4: I am losing to everyone, I'll give it all I've got to get in first.

And there you go, the four thought patterns of my rubber-band AIs. atm, this doesn't affect their item usage, so with items, they're still a bit of a force to be reckoned with, even though they're trying to make things easier, lol.

Anyway, that's all I've got for new stuff for now, stay tuned.

EDIT: balance testing's done, it's ready! now the AIs give a much better challenge for human players, even with items and dash panels on! Yet, it's still possible to beat them... That's a good thing at least, we don't want terminator worming his way into the speedway! XD

EDIT2: there's also an oversight that causes the AIs to go normal speed if they're 2nd place and you're in first, I might need to re-tune it again...

 

The mice look funny . You got my interest.

 

LOL, they're rats... XD

Quick update; apart from an odd behaviour if the player's in first, the AIs ready!
EDIT: Also, once I reboot the computer I'm typing this from, expect new beta builds!

EDIT2: SInce atm I don't have a Mac system, is there someone who would be willing to do a test iOS build for me, and report back how it runs on an iOS device? I've often wondered if it would be a good idea to start getting my iOS tools together. (Also means I need to go download a playback engine...)

 

Jet Rat Speedway version 0.6

Hello again! so many posts in one day!
Anyway, here's some beta builds everyone! All except the APK for android are zipped up. (Hopefully that doesn't wreck the OSX build...)
Version for Android 2.3 or higher: https://drive.google.com/file/d/0B2tqYgzg1_lWLXhtU0dHdFRDb1E/view?usp=sharing
NOTE: If you downloaded the game before 11:00 PM AEST on 4/5/2016, there were two bugs that made the game unplayable (font wasn't rendering + a bug with the item button). I have fixed these and uploaded a new build past that time.

Also... NOW INCLUDING STANDALONE BUILDS!
Version for Windows XP or higher: https://drive.google.com/file/d/0B2tqYgzg1_lWNzZxOVZxRzI4VFU/view?usp=sharing
Version for OSX: https://drive.google.com/file/d/0B2tqYgzg1_lWbTEwTGhhOGl3VjA/view?usp=sharing
Version for Linux: https://drive.google.com/file/d/0B2tqYgzg1_lWai12ZGluMlNLV1k/view?usp=sharing

NOTE: On Windows and Linux standalones, unless you're using an Xbox controller (May not apply for Macs) the start button's actually your right trigger... I'll be coding in a workaround for that soon. Without a controller, use Esc key to start.

Mini-changelog for this revision:
VISUALS:
- GUI has been changed: now it's a lot cleaner and more optimized.
- Removed speedo and power meter: They didn't really have a use and cluttered up the screen, so they're gone now.
- Removed animated splash (All versions): Due to a Linux crash bug related to movie textures, the animated splash after the unity logo's gone. Hopefully, it'll get fixed. Mobile's technically not affected, but I changed it there as well to keep the game versions the same.

CORE:
- AIs now have rubber banding: This should help make the game a bit more challenging!
- Item balance adjustments: Now it is no longer possible to get more than 2 of an item at a time if you're in the higher 3 positions. This should stop the bomb spam that occasionally happened if you're in first and got 5 of them...
- Application.LoadLevel calls updated to SceneManager-based ones. About time I removed some legacy code!
- (NEW) Fixed font rendering issue on android: clearly, someone doesn't like custom character sets... fixed by switching to Unicode format.
- (NEW) Fixed sort-order issue that disabled the item button on android: My mistake for this one...

ISSUES:
- Controls on mobile with the gyroscope mode off need a makeover: This will come soon hopefully. Also time to ditch the auto acceleration... (makes it hard to stop otherwise)
- There's no way of turning off low-res mode yet: As a result, the game fires up at 640x360, regardless of the target platform. I'll be adding a switch soon for both mobile and PC when I get the chance.
- Reflection's a bit slow in places...
- Sometimes, loading a stage in the standalone builds results in an infinite loading cursor. Just restart the game to fix for now, I'm still searching for the real cause of the issue. As far as I know, it doesn't affect mobile. (UPDATE: It seems to only affect Linux, I'd have to have someone check OSX for the bug)

For all who try these out, enjoy, and I look forward to your feedback! For those using OSX... let me know how it runs for you! (And what your experience with controllers was... XD)

EDIT: Corrected the datestamp on the android build. (It isn't April anymore, oops.)

 

Hi! any chance for a webgl version? (would be easy for quick testing)

 

Hmm... maybe. I'll see how it runs first.

EDIT: That, and testing for the standalone builds and mobile's the purpose of having one, as WebGL sort of defeats the purpose with testing a lot of hardware...

EDIT2: weird... for some reason, the game doesn't want to load a single stage in webGL... looks like for now, no webGL, until i can find the location it's crashing in.

 

QUICK UPDATE: For those who have grabbed the android build... may have noticed everything in English has been reduced to boxes! I'm getting a fix up very soon!

EDIT: Found another bug as well... (Item box doesn't respond to tapping on Android) I'll re-upload soon.

EDIT2: Found the bug... one of my background layers was on top of the button, oops!
Check up top for changes.

 

^^ Bug-fix bump, for those who noticed the android build was broken, I fixed it.

 

Oh so frustrating!!

A few things,

I think the render distance needs to be longer,i can't manage to see in front of me very well on the low resolution phones have plus the fact speed I'm going.

And you also need to add a sensitivity option, it is soooo hard to control on both of the settings. Buttons is too sensitive, whereas gyroscope is too insensitive.

I'll give it a go on pc later.

Also, i was running around 20-30fps on max settings on my galaxy s6, so the game is optimized quite well!

 

I'll be considering a render distance option then. The reason it's so low in areas is due to my pendo pad lagging on anything beyond about 100. (it depends on the game, and the forest base alone takes up 50k per frame, due to trees...)

The sensitivity option will come with the controls revamp, as I was considering a virtual analog stick option. (better precision on the right touchscreen)

That, and I got an email from UT saying that they had a lead on my IL2CPP bug, so I might be able to squeeze a bit more speed out of my tablet! Now to make a copy to test 5.4... XD

EDIT: I also noticed the slow gyroscope glitch... It must have been due to some code I left in, I'll check it today when I finish IL2CPP testing, along with adding sensitivity slider to options. (The options menu needs a severe cleanup anyway, may as well do it then... XD)

 

Confirming that Unity patch 5.3.4p5 fixed the IL2CPP scene loading crash I kept getting, I'll be uploading a new build tonight.

Fixes/Improvements in next mobile build:
- (UNCONFIRMED) Fix gyro and touch arrow sensitivity: I found the reason for the stupidly slow turning with the gyroscope; for some reason, the raw X-axis accelerometer value with no adjustments was being used! The touch arrows being too sensitive was due to the high gravity on the X axis input inside the Input manager. (That's fixed now as well)

As for the gyroscope issue... I remember having a different multiplier there, but I must have removed it and forgotten to put it back in...
- IL2CPP crash bug reported (and confirmed) fixed in latest Unity patch release: I can finally start offering two builds again! I want to evaluate how fast (or slow) each build is before considering which scripting backend to stick with. (And builds are really tiny now with IL2CPP; they were monstrous before, even with code stripping on) One thing I've noticed is that some odd spikes I got with item spawning are gone in the IL2CPP build. (But then again, the general framerate on the pendo isn't great either)

As a side-note I only found out about this from being emailed about it by the QA team. Good Job Unity QA!
- Explosion effect readjusted: it didn't really look that good, and took up too many particles, so I re-did it. Now it's bigger with more subtle 'floaty' smoke after the initial flare-up.

 

^^ bump. Doing this to refresh the page!

 

Full list of changes so far:
- Fix gyro and touch arrow sensitivity: I found the reason for the stupidly slow turning with the gyroscope; for some reason, the raw X-axis accelerometer value with no adjustments was being used! The touch arrows being too sensitive was due to the high gravity on the X axis input inside the Input manager. (That's fixed now as well) As a side-note I ended up changing how the input arrows worked to stop the sensitivity issues with the arrows.
- IL2CPP crash bug reported (and confirmed) fixed in latest Unity patch release: I can finally start offering two builds again! I want to evaluate how fast (or slow) each build is before considering which scripting backend to stick with. (And builds are really tiny now with IL2CPP; they were monstrous before, even with code stripping on) One thing I've noticed is that some odd spikes I got with item spawning are gone in the IL2CPP build. (But then again, the general framerate on the pendo isn't great either)

As a side-note I only found out about this from being emailed about it by the QA team. Good Job Unity QA!
- Explosion effect readjusted: it didn't really look that good, and took up too many particles, so I re-did it. Now it's bigger with more subtle 'floaty' smoke after the initial flare-up.
- Removed Specular shading from vertex shader: This change alone brought the framerate up to over 30 in the desert and the forest, and 30 (sometimes dipping a bit lower) in futuristic on my test device.
- Reflections optimized: Now they have distance-based frame-rates, never exceeding 8 captures per second when up close, and far away, it can be as low as two seconds per frame! Additionally, I added in a check to avoid multiple reflection renders in one frame. And all of those optimizations managed to bring my pendo pad from single digits to near-playable in intense scenes!
As a result, expect an almost negligible frame-rate hit in most cases from realtime reflections, unless the device in question is weak in the vertex processing department...
- A bug causing the track start line not to bake it's reflection map was fixed: this caused the start line to almost always render nothing, only using the default map. it's a very subtle effect though, and not that noticeable unless you drive round it.
- Adjusted AI rubber-banding to be more difficult: Pretty self-explanatory...
- Changed explosion colour for torpedoes: often wondered what exactly hit your little rat? Now you know with the upcoming test build; a massive green explosion followed by soft flames is emitted from the torpedo upon hitting it's target. (Bombs still have the original explosion)
- Changed torpedo trail colour: atm, it's blue, (originally orange) but I'm thinking of changing it to green...
- reduced max number of multi-items to 4: Now it isn't possible to get more than 3 items in most cases (sometimes 4, but that's super rare!) from the boxes when in lower positions. Also fixed an issue with determining how many to give out. (Not using Mathf.Round() in the right place...)
- Render distance increased in the forest (again): This change was only possible after removing the specular highlight calculations. Enjoy the longer distances when the next build comes!

And that's it for now, laters...

 

A little update to say that I may be starting operations again on this project soon.
Shortly after I posted the last update, several last-week things at uni, followed by a massive three-month holiday meant that I largely forgot about this.

However, a few weeks back, I got something I didn't expect; my first android phone. Therefore, I now have a Samsung Galaxy J1 Ace added to my debug toolset. That, and a couple of times... I opened the project again to work on it.

so... mini-changelog:
- at the moment, I'm still attempting to fix the accelerometer sensitivity, as turning it up makes the arrows WAAAY TOO SENSITIVE! Chances are, using two variables should fix it. I also aim to have the steering sensitivity slider in soon.
- General tweaks to get the game running smoother and less buggy on smartphones; a lot of the time, the Pendo Pad was the only test device... now I have two. Thus, I've been tuning things to cater to both smartphone and tablet users.

Coming Soon:
- Lava Env Base: I actually started work on one of the background parts a while ago, but due to uni work, I had to stop to make room for that. I will resume work soon, once I get the core of Miraien Tournament rebuilt fully.
- POSSIBLE WINDOWS STORE SUPPORT. This means Windows Phone people.
- That Cheese power-up. I will also start work integrating this wherever possible.
- New shader framework: I've been experimenting in my spare time for a while now, attempting to find a cheap way to get good-looking character shadows without too much rendering work, and now, it's about time I wrote a new framework for mobile.
- Do up the final artwork: A lot of the artwork is beta stuff, once I really get into this, expect some awesome new designs.
- remix some sounds: I got some new sound clips in my library, so I'll be mixing some new stuff for the game. Hopefully should have a theme tune for it as well, since it lacks music right now...

Also, expect an in-between set of test builds soon, they're probably the most stable they've ever been yet.

 

Cool Fuzzy! Good to hear the update. Glad you got the phone to test! Has Unity 5.4 helped at all?

 

Well... :/ Due to my Dell Mini 9 only having Shader Model 2.0 tops for it's graphics level, I unfortunately can't move onto Unity 5.4 (they cut support for SM2.0 hardware apparently, and the laptop GPU is an old as the hills GMA 950 chipset)

Therefore, I'm stuck on 5.3.5. Not that it matters that much; it's one of the most stable unity releases I've used so far.
And yes, I have found that for control scheme reasons, smartphones are actually more suitable as gaming devices for this game. (no huge screen to stretch your thumbs on, lol)

EDIT: As of about November 2016, I now have an AMD Fusion powered netbook, and can use Unity 5.4. It gave the game an insane speed boost. :O Same goes for NeoDash's old core code. (A big mess, ahem)

 

So, ops on this project have finally started up again.
This is mostly because I now have a uni assessment that requires producing a creative work and going through the project management steps to complete it.

Since it was possible to pick an existing project to work on and complete, I decided this one needed some love.
Minor changelog:
- Added more advanced motion blur: The old colour accumulation method was real hard to actually use and not run into walls. Now I'm using the same multi-sample method (with some tweaks) that the current build of NeoDash/Alternator Power uses. (Speaking of which, I should update that thread with a changelog )
- Rudimentary dynamic lightmapper is in! When completed, this will lightmap all of the track pieces into lots of mini-textures, with a texture per track piece. This will mean that the track pieces will cast static shadows!
- All lighting is now per-pixel, with 4 diffuse lights per object
- The track generator now has the ability to use a static seed for track generation: This is added in so future LAN multiplayer will work. (Basically, generate on host, send seed to clients )

Coming Soon:
- Lava env: A searing track surface awaits
- Beach env: This one will have a key difference from the other environments; the entire track is flat. Follow the arrows!
- More characters: It isn't just rats now, I now have plans on adding 4 other animals in, each with unique vehicles.
- Split-screen and Local LAN multiplayer

Currently planned platforms:
- Win32/Win64
- Windows 10 UWP (This includes ARM)
- Linux
- Android

 

Finally found some time to type this, so here we go...

Change Log:
Improvements & New Features:
- The Split-screen is a GO! Now instead of going straight to env select, it asks if 1 or 2 players will be playing. Screen splits horizontally and works well.
It was actually originally in the game's code as part of a demo I made for high school 3 years ago, but once it started going a different direction, the old hard-coded split-screen was removed.
- Dynamic lightmapper is basically done: There is some UV bleed issues in parts, but this is mostly due to the low resolution of the lightmaps themselves. I was able to integrate UV dilation to combat this, but it isn't that well tested.
- Lava environment is in a working state: The first segment is probably one of the most complex in the game, and there is a fair bit more dynamic lighting than there was.
- Main Menu was redesigned... again. This time, it was to clean up the options menu, and add the two-player option.

Bugfixes:
- Fixed a huge oversight in waypoint ordering: This only showed up when the Lava environment's extra points were somehow ordered the wrong way after starting a game session after WAKING THE LAPTOP FROM SLEEP MODE
I tracked it down to the fact that I was just using FindGameObjectsWithTag with the default order. This also caused all the turn segment points to be inverted, of which was the cause for both the ranking flicking between positions, and AIs getting stuck on rocks in the Forest.
Now, I name every waypoint a number as soon as it gets spawned together with a segment, then I sort them after the track is generated. Managed to not only order them correctly, but fixed two other issues in the process.
- Fixed all the second player's inputs: Practically all of them had a few quirks when I reinstated local splitscreen...
- Fixed yet another oversight in aligning the skyboxes: This only showed up when split-screen was implemented, and was a very easy fix.

Known Issues:
- Android builds are potentially now broken and need reworking: This is due to the tremendous amount of PC-based work I've done on the game for my assessment, so Mobile hasn't been that high of a priority.
- No sound on the second player's screen in local multiplayer: Because Unity's sound system is seriously retarded in thinking ONE AudioListener is enough for all cases, the second screen lacks sound at the moment.
- DirectInput controllers are ordered before Xbox/Xinput controllers: This minor annoyance isn't exactly fixable, but at least the two work together well...
- The Dynamic Lightmapper is S-L-O-W: As a result, a couple of stages have it disabled. Stages with it on may not load instantly on low-end PCs.

Coming Soon:
- Extra track elements: This is a small feature I have been thinking of doing for a loooooong time, but haven't had a chance to implement till now.
- Four more pilots: It won't just be Rats anymore... A Guinea Pig, Hedgehog, Mountain Pika and Lemming are joining the fray!
- The Cheese Powerup
- A redesign for the boost panels: The actual asset for the boost panels is now used in Miraien Tournament and matches that particular game better than this one, so I will be redesigning this element soon.
- LAN Multiplayer: The foundations for sending map codes are down... the actual meat is soon!

Some final notes:
- Screenshots and a YouTube upload are coming soon.
- I've changed my publishing name again: Now, it is "Hedgehog Arts"
- When Android builds are fixed, new builds will be uploaded as well! due to time constraints, I am cutting android support for now, but it will return after my PC version is submitted as my uni assessment

 

Sounds awesome Fuzzy! Looking forward to the video and build!

 

Change Log:

CORE:
- Finalized Lava stage: Now the lava stage, excluding extra track elements is in
- Fixed the ranks jumping all over the place: This was caused by the comparator, I ended up importing the one from Miraien Tournament and tweaked it to suit Project Hovercats
- Fixed an oversight that prevented the second player in split-screen from throwing bombs forwards: This I found by accident when trawling through the code to add the food item. (It's finally being implemented as I type this)
- Bike model has been swapped for a brand-new one. Rendering coming soon, watch this space.
- Fixed an issue where clicking with the mouse would lose button focus for keyboard and game controller navigation. Unity, I said NO MOUSE!

VISUALS:
- Fixed a queuing issue with the Reflections that made some of the bikes black at the start of a race. Another oversight unseen till a few days ago...
- Lighting System changed: Now Unity's built-in shadows are used in the levels, with options to adjust the quality or turn them off. Such quality settings also control the number of pixel lights. Thus, I can now say the old "use vertex-lit with fancy stuff" method is now completely axed from the game.
The downside is that now Shader Model 3.0 is required to run the game, as a result of the shaders getting more complex from the change.
- Removed old drop-shadows from the game: This is due to the new lighting system, and saves a bit of CPU as the raycasts to position them aren't there anymore!
- Re-adjusted reflection map blending: Now shadows and reflections blend better with each other.
- Countdown UI fixed for split-screen: Now it's properly centered in the middle like it should be.
- Fixed bloom being overbright on second screen in the beach environment: This was an accident caused by some of the stages not sharing prefabs anymore, and others accidentally saving settings from other envs
- Fixed really dark lighting in Lava environment: This isn't quite fixed if the gamer is using Low or Very Low graphics settings, as the fix involved adding a second light in.

Known issues:
- Split-screen ends when any player finishes: This isn't really too much of a bother, but at the same time, letting the other player finish...
- For now, no MSAA on Ultra setting: This is due to the motion blur effect stuffing up badly if MSAA is used (Blame Microsoft's retarded coordinate system on DirectX for that, the normal "flip the texture" fix doesn't want to work) I am more likely going to use FXAA or a better post-process AA instead.
- On 5K iMacs, the bloom effect is super splotchy: This is actually because somehow, the game runs at full framerate on ultra with everything turned on... On native OSX. (Have a good day OSX gamers ) The downside is that the mip-map bias based blurring doesn't quite work as intended. I am working on a fix for this.

 

I may as well put up some preliminary system requirements:

Minimum system requirements for Windows
(VeryLow, all options turned off, 30fps)
The game will startup like this by default
- CPU: Any 1GHz CPU with SSE2 instructions
- GPU: DirectX 9, SM3.0 capable graphics card
- RAM: 1GB on Windows XP, 2GB on Windows Vista and higher.
- Disk Space: 128MB
- Display: 640x480 (NOTE: This game will also work on a PAL aspect ratio and line count)

Recommended system requirements for Windows
(Ultra graphics setting, Reflections, Motion Blur, Bloom, 60fps)
- CPU: Intel Core i3 Sandy Bridge or AMD Equivalent
- GPU: Nvidia GeForce GTX 680, AMD Radeon 7750, Intel HD 4000
- RAM: 4GB
- Disk Space: 128MB
- Display: 1280x720 HD

Minimum System Requirements for Linux:
- CPU: Any 1GHz CPU with SSE2 instructions
- GPU: Any OpenGL 3.2 compliant graphics card, Mesa 12.3
- RAM: 2GB on 32-bit, 4GB on 64-bit (PAE kernel should work too)
- Disk Space: Not tested yet, but probably the same as Windows
- Display: 640x480 (NOTE: This game will also work on a PAL aspect ratio and line count)

Recommended System Requirements for Linux:
- CPU: Intel Core i3 Ivy Bridge or AMD equivalent
- GPU: Intel HD graphics 4400 or AMD equivalent NOTE: This can also depend on the graphics driver installed, be careful.
- RAM: 2GB on 32-bit, 4GB on 64-bit
- Disk Space: Not tested
- Display: 1280x720 HD

System Requirements for OSX:
- CPU: 1GHz Intel CPU
- GPU: OpenGL 3.2 or OSX Metal compliant graphics card
- OS Version: 10.8 or higher, as per Unity system requirements

If any of you guys have old machines lying around, I am about to upload a surprise PC test