Games WebGL - Casual Vehicular Action (Completed)

Edit: November 1st, 2022: Casual Racing published on itch.io:
https://forum.unity.com/threads/published-on-itch-io-casual-racing-desktop-webgl.1355867/

Edit: December 31st, 2021: Tower Offense released.
Edit: November 12th, 2021: Casual Racing released.

Spoiler: Previous Weekly Updates

Edit: November 6th, 2021: Weekly-ish update.
Edit: October 29th, 2021: Weekly update.
Edit: October 22nd, 2021: Weekly update.
Edit: October 15th, 2021: Weekly update.
Edit: October 9th, 2021: Weekly-ish update.
Edit: October 1st, 2021: Weekly update.
Edit: September 24th, 2021: Weekly update.
Edit: September 17th, 2021: Weekly update.
Edit: September 10th, 2021: Weekly update.
Edit: September 3rd, 2021: Weekly update.
Edit: August 27th, 2021: Weekly update.
Edit: August 20th, 2021: Weekly update.
Edit: August 13th, 2021: Weekly update.
Edit: August 6th, 2021: Weekly update.
Edit: July 31st, 2021: Weekly-ish update.
Edit: July 23rd, 2021: Weekly update.
Edit: July 16th, 2021: Weekly update.
Edit: July 9th, 2021: Weekly update.
Edit: July 2nd, 2021: Weekly update.
Edit: June 25th, 2021: Weekly update.
Edit: June 18th, 2021: Weekly update.
Edit: June 11th, 2021: Weekly update.
Edit: June 4th, 2021: Weekly update.
Edit: May 28th, 2021: Weekly update.
Edit: May 21st, 2021: Weekly update.
Edit: May 14th, 2021: Weekly update.
Edit: May 7th, 2021: Weekly update (+video).
Edit: April 30th, 2021: Weekly update.
Edit: April 23rd, 2021: Weekly update.
Edit: April 14th, 2021: Weekly update.
Edit: April 9th, 2021: Weekly update.
Edit: April 1st, 2021: Weekly update.
Edit: March 26th, 2021: Weekly update (no video).
Edit: March 20th, 2021: Weekly update (no video, and a minute late on post despite that!).
Edit: March 12th, 2021: Weekly update (no video).
Edit: March 5th, 2021: Weekly update (no video).
Edit: February 26th, 2021: Weekly update (no video).
Edit: February 19th, 2021: Weekly update (+video).
Edit: February 12th, 2021: Weekly update (no video).
Edit: February 5th, 2021: Weekly update (+video).
Edit: January 29th, 2021: Weekly update (+video).
Edit: January 22nd, 2021: Weekly update (no video).
Edit: January 15th, 2021: Weekly update (+video).
Edit: January 8th, 2021: Weekly update (no video).
Edit: January 1st, 2021: Weekly gameplay video update.
Edit: December 25th, 2020: Weekly gameplay video update.
Edit: December 18th, 2020: Weekly gameplay video update.
Edit: December 11th, 2020: Weekly gameplay video update.
Edit: December 4th, 2020: Weekly gameplay video update.
Edit: November 27, 2020: Weekly gameplay video update.
Edit: November 20, 2020: Weekly gameplay video update.
Edit: November 13, 2020: Weekly gameplay video update.
Edit: November 6, 2020: Weekly gameplay video update.
Edit: October 30, 2020. Gameplay video posted. Jump here.

Original Post Follows:
This is my current project. By the end of the year I'm hoping it to be a solid foundation for my first title with Unity Engine. I'd appreciate any feedback related to performance in particular. Did it load? Was the framerate playable/smooth in your browser? Did it stutter at all, and if so, what seemed to be the cause? Does the vehicle engine's audio play?



I still have much to add and improve - quite a few underlying systems and custom editors have just recently reached a point where I'm happy enough with workflow and performance to consider them reasonably/mostly ready to create a game with.. but however much I test builds on my own, there's no substitute for actual feedback. I've only had this laptop and my phone to test with on a regular basis.



The first world (with the car at night) is where my primary interest in feedback is, given it's quite large and populated with content compared to the others. I've included an older test world (the "rail shooter" genre-ish one) plus 3 small "Mobile WebGL-compatible" worlds as well.



Please note it's mostly programmer art - I've spent limited time on design and making things look nice.. the worlds are all throwaways / temporary. The primary focus at this stage of development is functionality, stability and an acceptable level of performance. I've exaggerated the effect of some LOD systems by making their transition distance a bit closer than I would normally.



Graphics and other options are available in the menus. If you find it's not working well, please try disabling Post Processing, Shadows or reducing MSAA. Thanks for your interest and for whatever feedback anyone can offer - in particular about whether it's working and performance in general.

https://tentatively.online/open/test

 

Hi, here are my results for iPad Air 2 (both Safari and Firefox(few frames faster))
Dynamic Texture Blending ~10 fps when tapping, 20 fps without tapping
Vehicle Test ~12 fps when accelerate, ~20 free drive, ~30 not moving. Sound works well
2d Scene ~24 fps

on iphone 6 didn't started at all, but maybe it shouldn't, device is too old.

 

Thanks for the feedback - yes, the performance of my Mobile WebGL worlds is disappointing. I was hesitant to include them at all, but given a lot of people are only using phones/tablets these days I didn't originally want to just "forget about mobile browsers." I won't be releasing anything targeting it (maybe in 5-10 years when devices are faster, if then) and hopefully by then Unity will also officially support it. Mostly because I don't want to work on super-simple concepts. I also have input issues on my phone (an S5) with the texture blending test in default browser, sometimes it doesn't even detect the tap - but my phone is a dinosaur

 

These are the worlds mentioned above that can be selected when using Mobile WebGL without getting a warning:




For comparison with the iPad Air 2 feedback, Galaxy S5 gets the following fps until it heats up, then frame rates are about 10 less. Samsung Browser slightly outperforms Chrome.

blend: 32-38
2d-ish: 45-50
vehicle: 29-40

Updated live build to use 2020.2.0b7 (the feedback provided was on 0b5). I still have input issues on Mobile WebGL.. I could upgrade to the new input system at some point and see if that fixes it, and/or dig around for what I might be doing wrong, but as I won't be targeting mobile browsers anyway it's not a priority.

 

In regard to what you posted.

"The feedback I'm currently seeking is how the world shown below is performing on desktop browsers for Windows, Mac and Linux (does it load, is it working, does engine audio play, is the framerate high enough to be considered playable)."

OS: Windows
Browser(s): Chrome, Firefox, Edge
Worlds: 1, 2, 5

No issues at all. 60fps, audio loads and plays fine. No stuttering or anything (Good choice to include a way to turn the car back over because I had quite a lot of fun off-roading trying to flip it).

The only other thing I would mention is that sometimes it feels like you lose momentum too quickly when turning after you build up some speed. I was trying to do big jumps but found that going straight worked better than trying to turn into a jump. Maybe that's just me though.

 

@Aviryx thanks, that's all great news - I'm glad you enjoyed it! And yes, my vehicle control definitely needs work.. it's not just you. I want to have fast-paced action, ramps/jumps, obstacles, time distortion, things to pick up, driving through breakable stuff like windows, etc. so controls will have to be tight and I'll need to work around anything aggravating from a gameplay perspective (which I'll probably also seek a round of feedback for once things are further along). I think it's looking good right now on the technical side.. but actual design and gameplay will take a lot of time as well, and other technical hurdles may present themselves along the way.

Actually on the 2nd world, you can use up (W) and down (S) to speed up / slow down time - this is a remnant from previous gameplay tests. The same world also has dynamic shattering / fragment pooling.. each time you complete a mini-game there (i.e. getting all stars) a panel displays, which breaks apart based on exactly where it's shot. Well if that were a window / secret entrance to a shortcut.. and the projectile was a car..... anyway, slowly but surely !

 

Hey, just tested on Windows in Chrome (GTX 1060 6GB)
I don't know how WebGL is handling 4k displays, but i assume it is trying to render 4k
World1 ~40 fps
World2 ~40-50 fps

But 1060 is definitely not for 4k gaming. I assume your webgl tests should run fine on other PCs

 

Thanks for taking a look - my previous laptop (2012, Intel i7-3520M with a NVIDIA GeForce 640M LE) struggles in the browser in full screen at 1920x1080 for even 30fps most of the time, but with graphics options turned down it's much better. The "Low-End Platforms" worlds run at 60fps in the window and 24-40fps in full screen with the options at defaults (i.e. Post Processing enabled, 2X MSAA, 100% quality etc.).

However, that same laptop runs all worlds at 60fps+ (99% of the time) in a standalone Windows build. The difference between running as an application vs. in a web browser is definitely significant (and I assume likely to remain so). A Windows build can be downloaded from the Main Menu - it's an automated process, current platforms I test with are built/packaged together, so any update to the WebGL version also has the Windows and Android versions with it.

Also worth mentioning, these worlds have a lot of transparency and batches, they're not an attempt at best performance possible or "as good as it gets" - I'm just trying to gauge how they run, which so far looks like "good enough." A mix of stuff including transparency and physics and particles etc. is more realistic for me, as my focus now is to actually have fun with development, vs. spending my time solving technical challenges.

Anyway - my current system (AMD Ryzen 7 4800H, NVIDIA GeForce GTX 1660 Ti) runs everything >= 60fps with all options highest / max. My "must hit" benchmark is that remaining to be the case and also hopefully still having a smooth experience on my older laptop in a standalone build.. but if not, that's fine too, it's long overdue for retirement

 

https://tentatively.online/open/test

 

Since Feedback Friday last week I've made some progress. I took the advice of @Antypodish and @Billy4184 about the drifty camera - there's now a Controls Option that lets you adjust how drifty. I've made the default to be 50% of what it was previously. I integrated most of the gameplay from the daytime "rail shooterish" world along with adding indicators for nearby challenges (as shown in the previous post). My current focus is adding gameplay mechanics - I'll sink time into visual style / design / color palette when everything I want to code is roughed in.

There are interior lobbies to the towers now with a total of over 550 breakable windows. Destroying one also handles related LODs (which took some effort), so no matter how far away you are, the window is still gone. I disabled physics on the shards until I do a "Fragment Physics" slider in options for % of fragments to use it with, but they're still roughly thrown based on impact. You can drive into/through lobby windows or shoot them out. There's no sound except for the vehicle right now but I'll add shatttering glass effects and some other stuff soon, maybe random items inside buildings etc.. not to mention random prop placement and other typical stuff, and though I'm not keen on populating the world much as it's a throwaway, I still do need the functionality as part of my workflow/tools/etc. Not to mention this is already effectively a stress test for WebGL - there's a lot in this (over 1/4 million objects last time I checked the profiler). Actual game worlds will probably have less / be more tailored to a specific flow of gameplay.

I added an "Advanced Config" button in Graphics Options. Right now the new page just has Structure LOD Bias and Draw Distance, but will have more options soon and be somewhat reorganized. You can increase the distance at which structure interiors are visible with the first slider - but I wouldn't advise maxing it out unless you're running the Windows build because not allowing structures to use a lower level of detail further out will drastically increase batch counts. However, the game does have a different feel if you reduce the draw distance and then increase interiors to the edge of that, with buildings and trees coming out of the fog as you're driving along etc.. it's possible I won't include a Draw Distance option at all because it could break whatever visual style I go with, but for now it's fine.

Also since my previous post I've roughed in the equivalent of a "rail grinding"/slingshot gameplay mechanic - there's a couple of examples early in the world, and it's not quite done yet (still need to have the car banking around corners, optimize things a bit).

In order to slingshot, you have to 1) be going in the direction of the "entry" and 2) be going faster than a minimum speed. The faster you're moving the more of an effect the slingshot has. There's an arrow on the ground that's green if you're approaching from the right direction (up to an angle difference limit), or red if not. The "11.4" there is the current velocity, as you accelerate towards it the color changes from red to yellow to green then it says "OK!". I'll convert this to KPH/MPH eventually. The arrow also needs replacing or to be changed to several in a row, it's not visually enough at high speed.. still mulling over design of it that complements boost pads and checkpoint challenges (some of the next stuff I'll be roughing in). You'll be driving over boosts then hitting a rail to get around a corner without losing speed - most rails will line you up perfectly to continue, with the intention of maintaining nausea-inducing speeds for most of the course.



If you're going fast enough and approaching from the right direction, the lock opens and hitting it will attach you to the rail and accelerate your motion (like slingshot you off the end of it.. which isn't a big deal if you hit the rail at a slower speed, but if you're already going fast when you hit it, the boost is huge).



Initially, only the beginning of the rail is glowing/more opaque, but as you get flung along it, the portion of the rail nearest to you (magnified by your speed) lights up, while the rest of the rail is mostly transparent. It looks a lot better in motion but here's what it's like exiting the rail from a sharp corner:



There's also a bridge you use as a ramp further down that road, with a rail you can catch in the air if you have enough speed from the previous rail and your aim is close enough.

Finally, the current build is now using Unity Engine 2021.1.0a2. Hopefully progress continues to be reasonably smooth, I've got a long way to go yet. 1 week down, 51 to go. I'm kidding, ..probably

 

https://tentatively.online/open/test

 

A week later..
Lots of recent additions/changes/fixes, some of which are listed on the Main Menu in-game for anyone who played before. Below are the current options menus - there will also be a "Foliage LOD Bias" slider added next update and I want to reorganize the two graphics ones.. but it's mostly together.

And the latest gameplay video:

 

It's Friday again! Here's another video - I've got new gameplay added (skip to 2:10 if you've seen previous videos or played before), refined a number of systems, added compass + indicators, can have multiple scenarios per world now, got a checkpoint/lap structure in place and a ~3.5km route roughed in. It's been a decent week I guess, but most of what's visibly new was done in the last few days.. I spent way more time than I care to admit since last update bug hunting/stomping

..note the red barriers near the beginning in the 'checkpoint dash' scenario are early tests, you can shoot them (3 shots to destroy) and the less health they have the less they slow you down if you hit them.. i.e. for obstacle courses etc. There's no visual indication of how much health is left yet, but I'll probably make the barriers blink bright when hit (instead of alpha curve like now) then be a bit darker or more transparent after the blink based on remaining health.. so it'll be easy to tell how much it'll slow you down if you hit it. I'll be making the impact on velocity and their health multiplier based on volume. So something larger you'll know will take more damage to destroy just by looking at it.. there will be different colors and materials of barriers (some more damage-resistant than others) as well and they'll be sparkly like gems, at least until you smash them

Obstacle courses with destructible content, multiple paths to take plus exploration/completionist elements are definitely where things are heading.. but there's more to add/refine with gameplay mechanics and I also want to spend a bit more time optimizing before mostly shifting focus to designing [hopefully] fun environments.

Play Now (Desktop WebGL): https://tentatively.online/open/test

 

Added new environment, streamlined a number of things related to worlds and scenarios. The previous "Main Menu" is now accessible at any time from the ? button near the top left. To get to the previous world and gameplay click Next World from this one's menu or pick it from the Select World menu

 

Another week, another video . A number of improvements, bugfixes, rewiring of how scenarios work under the hood, added/improved camera transition systems, created an optimized system for object placement along routes + extended my editor with related tools. Each route can now easily have 1000s of objects, and routes can be any length without much impact on performance. Only the nearest objects are spawned in from pools, up to the distance ahead that's allowed (which may eventually be another performance option). I've also added route previews to scenario selection. These are meshes generated from the actual routes and - eventually - selecting one will transition it to a minimap/progress area (which doesn't exist yet) instead of how it just transitions out right now.

I haven't spent much time populating the new environment aside from benchmarking/testing purposes.. it's a tough call given these worlds are intended to be throwaway/temporary, but at the same time, whatever.. maybe I'll get around to it before doing another world, at least along the routes. There's a bit more cleanup and gameplay-related stuff I want to deal with before switching back to design either way.

Note - you can press R at any time while playing to abort and display the scenario menu. Also, you can now hop with spacebar, although there's really no mechanic/usefulness just yet aside from getting over a guardrail instead of going around it. Also, don't forget to brake - the current rail layout can hurl the vehicle at unmanageable speeds if you build it up that far (i.e. by hitting every rail and not slowing yourself down as necessary).

 

I've been busy this week - gaming, Netflix, Amazon Prime Video ..but I did manage to get a few things accomplished.

There is now a route progress minimap (to the right of the score), which fills in based on progress, with the label and current region transitioning color between red->yellow->green along the route.

I've refined the basic jump from before into a jump->double-jump system (spacebar, spacebar) along with stat to the left of the compass indicating how many jumps are remaining before at least 2 wheels must touch the ground for reset. I'll eventually add a powerup that increases the max, so in some gameplay or worlds you might be able to triple-jump or even have no limit, which will make for some interesting layouts where ramps and rooftops are concerned. I've also added particle effect for the initial jump (ring of smoke burst expanding outward at the ground) and on any subsequent airborne jumps a similar one but with less particles and moving mostly downward as opposed to outward.

I've also added a stat to the right of the compass for #/# stars collected along the route, thrown a long string of stars into the "Service Road" route and added the stat to the Game Over menu (which applies to any completion state, i.e. success, complete, fail, aborted).

Trees now have collision, so you can't just drive through them like they aren't there anymore. I may do more soon re how the vehicle interacts with them, for example at low speed it will still stop you instantly, but at higher speed jiggle it and throw leaves particles, and at very high speed, fracture the trunk into a bunch of pieces based on where you hit and probably explode a puff of leaves or something. I want to keep that reasonably simple / mostly avoid it for now because I haven't decided whether I'll be doing trees like this, or low-poly style with no textures, or actual meshes + billboards in the distance - that's design-related so it's still a long way off. I'll probably switch to design and creating worlds that will actually be in the final game about 3/4 of the way through the year (maybe 5-7 months from now, but that's subject to change as there's no actual release date or fixed completion schedule).

Also, worth noting again.. the game will be free. I'm creating this by myself in my spare time while teaching myself Unity, refining/optimizing what I've done as my abilities improve and time/motivation permits (I've rewritten a few things along the way after learning new techniques or better ways to do things - but that's just how it goes and is a part of the learning process). Anyway, another week down!

 

More progress with destructible environment systems. Added airstrikes, which throw up a cloud of debris with each particle textured like the point on the terrain it originates from. I actually wasn't sure what was going to be possible for WebGL (where performance is concerned) or how far I could take the idea until all the pieces were together. There were a lot of underlying systems that had to be added and improved. There are still a few improvements to be made, but I'm considering it good enough now as-is to move on.

Blasts like these can also hit the player, also destroy guardrails (and way more stuff soon), breaking them off their posts to bounce around freely with physics. Later I'll be adding explosive ammo, so this kind of thing will be more integrated with gameplay than just the dodge mechanic I've roughed in for now.

2021.1.0a9 + URP 10.2.2

 

A few new things added - first/third person camera toggle with F, first person is now the default. I didn't enable first person on the old test world (city at night), the vehicle only has 1 headlight right now and it looks dumb with a single bright patch on the ground in front of you all the time

Further improvements to destructible environment systems, groundcover now also removed in real time from blasts. Also, you can now exit any rail you're attached to immediately by pressing jump (spacebar), or press jump when upside down to flip over (previously was only by click). Significant performance and stability improvements. Also roughed in damage indicator, corners of screen transition red for a moment when a blast is close to the vehicle (currently post processing must be enabled to see that, though there will also be indication of the direction that damage was taken from which won't require it).

Also discovered and fixed a few bugs along the way, still two known issues to resolve at some point between other stuff. The main one is new and related to the icons displayed during hovering of interests/powerups - sometimes they don't display now, but you can still click/collect the item in question. The other is related to compass indicators and first person roll - when the world's upside down the directions are thrown off.. or it's just me being disoriented when upside down. Either way, it got my attention so I'll take a closer look, I also noticed an indicator wasn't vertical from the compass so I'm definitely doing something wrong somewhere.

 

Since last week's update (aside from random improvements/changes) I fixed all of the issues mentioned in my previous post, plus did a significant rewrite of part of my groundcover system. The video starts at default Medium setting, the thumbnail image is while driving around after I set it to highest. The new system is still rough (for example I'll soon have "patches" of the same kinds of groundcover together, like clusters to break up how uniform it is). Also the trees don't have collision anymore, but it'll be different when they do again - you'll be able to hit them and they'll be removed like they are from blasts and you'll be slowed down instead of just being stopped instantly like before. Anyway, I'm pretty happy with how things are going. Happy holidays everyone, good luck with your projects!

 

Weapon selection is now roughed in. Primary control is mouse wheel, secondary is pressing number (i.e. 1 for default weapon, 2 for rocket launcher). Also will switch if you click a weapon's icon. The Rocket Launcher weapon is also new. For now it has no cooldown period or ammo limit, so have fun! Just don't fire at something too close

I've added support to my groundcover system for weighting sprite selection by texture/noise, so there can be patches of specific kinds of grass within a large field of grass for example. Note that the default option for foliage on WebGL builds is the upper end of "Medium", turn this up to max if you want to see what I'm talking about more easily (so there's denser foliage). Tree collision is back, but now as mentioned last week, driving into it will slow you down instead of the previous behaviour. This fits gameplay much better as you're not getting stopped instantly when going really fast, or having a tree in the way of a checkpoint ruining an otherwise great run. I've also added a subtle-ish "rustling" sound when a tree is hit by a projectile or removed. Default projectile behaviour with one is to be removed on impact. You can also destroy trees by hitting them directly with a rocket (airstrikes or nearby rocket impacts also destroy them, along with any other groundcover in the blast radius).

Most in-world text is now part of the same draw call, averaging about 60 batches less during gameplay vs. before. There is a limitation to the technique in general with transparency however - as triangles in the same mesh can't properly be depth sorted and there can be quite a few glyphs visible at the same time that must be sorted. I don't want to switch to opaque with alpha clip for text despite the advantages, as I'd lose the "transition softness" that fading affords. However, it may later be a user preference. The only difference procedurally is the material being used (aside from adding a bool for text to flag it for inclusion only while using the opaque shader). Anyway, still able to merge most in-world text on menus, and already designed it so I can have separate merges at once if I need that for gameplay menus overlapping.

Lots of random fixes, changes and improvements. A few new bugs ..camera transition out of "flythrough" type mode sometimes rolls improperly, haven't got around to updating how I transition that yet. Another bug has to do with star stats. Anyway, neither are significant right now and will be cleared up by next week's update anyway. That's all to mention for now, happy new year!

 

Since last week I mostly just fixed known issues (including those mentioned in the previous post) and cleaned up random stuff that bothered me. I also roughed in another weapon (rifle). Firing mode is "selectable" just by how long you hold the mouse button, i.e. single shot, burst or auto. Has audio and primitive "impact decals", like each bullet that hits a guardrail or the ground or whatever will leave a dot there for a moment that fades out. I might refine it somewhat between other stuff this coming week. I also did "impact particles" for the rifle projectiles but disabled them because I don't like how they work yet / want to give it more thought. I changed the "switch to mobile version" button in my WebGL template to "expand to fill window", which doesn't reload the page like before it just changes the layout immediately.

Aside from the above and whatever I'm forgetting, I integrated a couple of suggestions from last week's Feedback Friday - there's audio now while running out of time and the text for time remaining grows and pulses a bit larger and redder each second while you're down to 5 or less. Also added notes on the scenario selection menu which includes "checkpoints give time."



Not bothering with a video this week because I'd rather do other stuff tonight. There's not much difference since last week anyway

 

Since last week, I've created a "destructible enemy" system which is the foundation for all enemies in the game. I'm still considering it rough but it's mostly there/ready. Significant step forward ..my list of what's necessary before moving on to designing worlds and content is now quite short (relatively speaking - given the scope of this project, that'll still be a while yet).

To briefly outline features related to new systems (ignoring minor changes/etc. to other stuff),
- Enemy surfaces have hit illumination (i.e. wherever you hit glows red or whatever color briefly).
- There are critical hits (based on which part of an enemy is actually hit), critical hit kills (2X points if enemy dies from a critical hit - helicopter currently has this for the windshield, points displayed are red instead of white, combo increases by 0.1X).
- You can shoot enemy weapons to disarm them (i.e. shoot the helicopter's gun and it breaks off and falls to the ground along with displaying "disarmed" message).
- Each part can have its own health and be destroyed individually. Any given parts can be flagged as "fatal if destroyed".
- Each part has a "sensitivity" property. This means if sensitivity is set to 3.0, a shot that would normally cause 5 damage to the enemy will cause 15 instead if you hit that part.
- Hitting any part with a sensitivity higher than 1 is a critical hit if using a weapon that allows for precision (i.e. while a single rocket will blow up a helicopter, you won't be awarded 2X points or combo increase which you would by shooting it in the windshield. Risk vs. reward.
- Very lightweight mesh fragmentation for whichever parts (i.e. helicopter body), plus physics for whichever others (windshield, weapon, rotors).
- Enemies can belong to any number of factions. An enemy that gets hit by a projectile from the player alerts other enemies that belong to at least 1 matching faction and are within a given radius of the player. This game might not make use of a faction system, but seemed reasonable to rough in while I was doing other stuff related to alerting.
- An enemy is not aware of the player when really far away unless it's been hit by a projectile from a weapon being used by the player, it won't be alerted or engage otherwise.
- Nearby enemies start attacking when alerted by a hit faction member, or when hit by a player projectile, or when they're close enough (defined per enemy.. for example something like a sniper tower would consider attacking from a much greater distance).

The helicopter enemy itself [for now] just has a few lines of code for hovering and spinning the rotors, everything else is done in the Inspector. Later I might have it spiral out of control and explode when it hits the ground instead of immediately. I'll probably also make the windshield shatter when destroyed instead of tumbling around like plexi. As for generic stuff that applies to it, I'll also be adding particle effects like sparks flickering out of where a weapon was destroyed and so on.

Checkpoints will soon be replaced with destructible gates or other barriers that you can only destroy if all enemies before each have been cleared. There'll be a lock icon over them and you'll be unable to proceed until then (if you don't run out of time). Also there's no weapon accuracy stat yet or precision radius (they're always on point), but that will also be implemented soon depending on weapon type. Projectile systems are also on the "refine" list - adding the usual stuff like different decals/particles based on the type of surface hit.

Anyway, enough talk - another week down! Enjoy the video and/or as always, feel free to play any time. Updates to the live build are sometimes every day.

 

Highlights of progress since last week..

- Integrated another feedback suggestion about needing some form of indication when bumping into things like a hydro pole). If it's a fast enough collision, I now show the damage glow (screen corners/edge) plus a subtle shake of the camera in the direction of motion (stronger shake the faster you were going), plus a sound effect. I'm not currently applying damage for collision.. not sure if I want that, still undecided.

- Rewrote progressbar/healthbar stuff so all segments would be part of the same mesh/draw. Also can set progress bars to go from center outward (like enemy health under the crosshair). I'll still be adding circular/arc-style layouts at some point. Related note, the helicopter has health regeneration, so if you hit one then don't for a while it will end up back at full health.

- Improved blast visuals, added flashes with sparks and smoke (derived from a shuriken-based prefab in the free War FX asset here: https://assetstore.unity.com/packages/vfx/particles/war-fx-5669).

- Added 'bouncing' to my imitation physics for mesh fragmentation effects. I don't think I'll add any bounce to 'splat blasting' as dirt looks better to me sticking/sliding like now, but easing the sliding motion is on the agenda for whenever.

- Improved destructible enemy systems, each objects can now be set up to both fragment OR tumble based on conditions (vs. always being one type or the other like before). For example, the windshield on the helicopter will fragment if destroyed by projectile, or if the helicopter comes apart from a blast, but if the helicopter is shot down somewhere else by a projectile (i.e. rifle bullet), the windshield will tumble out as debris and not break apart. A more variable mesh fragmentation effect along with a few other related improvements are planned.

- Improved 'splat blasting' effect, now variable radius and debris density/scale/count based on blast radius and distance of blast from the surface. Previously both airstrikes and rockets always had the same effect (same radius, same fragment quantity and same scale range). Also now have related content return to pool at same time as shader completes transition out.. previously they had a fixed lifespan so would be in the scene a bit longer than actually necessary for the effect to complete.

- Added the ability to also collect things you normally have to click or hit with a projectile by releasing the mouse or touch during hover, since for weapons like a rifle you're holding down the button. Previously if you were firing and moved the mouse over something to collect, you had to pay attention that a projectile would hit it. Now you can just release the mouse to collect that, then click/hold the button down again to go back to firing.

- Significant change to rails. Motion is now applied using physics forces exclusively instead of my previous approach, making them more like "attractors" or magnetic instead of something you snap exactly to. However, this also means that now if something blocks your way while on a rail, collision with it will slow you down, so remember that spacebar will release you from a rail any time (i.e. you lost momentum or got blocked etc.).

- Roughed in a Grapple system for rails. During mouse hover of the entry point (while crosshair displays the grapple icon, which is only when you're getting close to it), click or release a drag to attach to the given rail earlier than reaching it. Among other mechanics this is intended for later, also allows for extra speed with good timing as you gain the benefits of rail attachment before you're actually on it.

No video tonight, can't be bothered - but anyone interested to see where things are at whenever can just click Play Now in my sig

..and that's 1 less week to go!

 

- Added dynamic time of day, changed the default environment to night. Added day/night powerups for testing purposes. Collect a sun to switch to daytime, moon for nighttime.
- Added streetlamps (150?). They turn off during the day, turn on at night. A streetlamp that is hit by the vehicle, shot or near enough to a blast will shut off, and break off the ground if significant hit.
- Added a toggle on the Scenario Selection menu to disable enemies, so routes can be driven with or without. Note the timing balance assumes there are enemies (the "unchecked" mode is for mostly for testing purposes).
- Changed the compass indicators (of enemies etc.) to move inward/outward based on their distance. To expand the compass, click and hold left mouse button on it or hold the Left Shift key down. It's basically the rough foundation of a gameplay menu.. time almost stops meanwhile (10% normal speed, or even slower if already in bullet time).
- Added armoring capability for anything that can be targeted (player, enemies, barriers), an armor powerup to refill with generic armor (the shield icon).

 

Another week bites the dust
- improved hybrid lighting system (normal lighting plus a form of dynamic lightmapping, currently used for the realtime streetlamps and red glow during rocket impacts).
- created a minimal light flare system, dynamic flare batching (all visible flares are part of the same mesh, right now that's just for whichever streetlamps are on and visible.. can't really see them in the video aside from glimpses as I didn't play the highway route this time).
- checkpoints are now surface-aligning meshes, also have roughed in transitions and a particle system that's active while a given checkpoint is next.
- hitting a checkpoint now triggers a short pulse of bloom and chromatic aberration. gameplay modes with checkpoints will not have them as close as "service route".. it's actually annoying the way it is in the video flashing so often, it's intended for after successfully making it to the next checkpoint (which could take a while).
- decided not to tie in destruction with checkpoints, that would just complicate stuff that's unrelated and I can have whatever in the way anyway.
- various other fixes and improvements.

 

It looks really decent job.

My one big concern at this point, is the lightening of the scene.
Some areas of the map are hard to see anything.
Not sure if that meant to be day/night mode?
The headlights doesn't seems to help much.
Only the fact that you can see checkpoints.

 

Thanks

Yeah - actually that road has no lights or anything, it's really only playable as-is during the day unless you're familiar with it, but it has a curved surface which was good for testing dynamic mesh alignment (my new checkpoints).. several get reused/placed/aligned procedurally from a pool as you progress.

You can toggle between starting at day or night (the sun/moon button on the scenario selection menu) and during gameplay you can collect a moon or sun to switch while playing. They're mostly just my "dynamic time of day test buttons" right now - but since actual time of day is probably going to be controlled by the scenario, the sun and moon "powerups" will maybe only be in bonus worlds (undecided). Right now items are everywhere and everything is haphazard, I haven't even moved the stars on the highway route (the 9 near the beginning) since I first got them working with new route layout systems. Lots of temporary stuff, my messy workshop . Even stars are just "things to find all of" and won't necessarily be stars at all, though they've kind of grown on me so who knows, a few here and there maybe, like secret tapes in THPS or feathers in AC.

You're right - I'd very much like to brighten a large area with headlights, I just can't seem to get spot lights to work properly or clamp their effective intensity. I posted a thread about that, haven't focused on it for a while but I'll need to solve it eventually or work around it however. To sum it up.. for example if I want a tree (or wall, whatever) lit up 50m away from a light, any tree that's 5m away becomes almost pure white. I'm probably doing something wrong or don't understand.
https://forum.unity.com/threads/spot-light-intensity-issue.969021/

Yeah, that's pretty much all you can see at night on that road.. I could throw a bunch of lamps in and whatever (and might anyway), it's the same reason as why texturing of that road surface is so bland - I could spend time splat painting grooves and whatever else, but when I toss the world it's for nothing. It's currently 99% procedurally generated, there's very little I actually placed or edited by hand since the city test

 

To be clear - worlds are not generated procedurally during gameplay, I meant by my tools and workflow. However, I am currently working on an internal Campaign Editor tool, which is in-game, so I'll be able to easily add/remove/step through branching chains of scenarios and edit content placement etc.. For example of branching, if you took a long time to reach the end of an underground tunnel complex, the next scenario might be an alternate escape route or whatever, whereas completing the tunnels fast / meeting whatever objectives might lead to a bonus "highway dash" kind of scenario instead, with both of those then leading back to the next in the main branch afterwards.

After my Campaign Editor is together, it'll be pretty exciting from a design perspective. I'll have many sleepless but fun days/nights adding/refining content for the last 6 months of the project - so if I'm sticking to completion by end of this year, that means in May I call things good to go from a tools, workflow and capabilities perspective, wherever they're at. Once that happens, I'll stick with features already tested and prepared, so the more I can do before then the better. That said, I could decide next week that it's time - it's already an exercise in self-control not to be having more fun with this

 

A productive week! The groundwork has been laid for in-game Campaign Editing (internal tool, which may become part of the game later). It's not in the live build yet, I haven't updated that since last week. Lots of things have changed that need to change more before I put another build up, plus this still isn't much but a good start anyway.



Aside from general data management (navigation, add, remove, rename), I've also done cross-platform save/load (HTTPS+PHP+MySQL) and save/load for "local tinkering" without a server.

I've migrated scenario data from being within world prefabs to just being data. This means I can make a change within my editor and play the revision instantly. It also means that now I can change scenario and object layouts for routes without touching the world prefabs, which will save me a lot of time later. There is still other stuff to migrate from worlds into the new system - with the structural goal of a world itself having nothing to do with what goes on within it.

I've also improved and expanded my UI system and its capabilities. I'll soon be replacing the menu I currently show at world load with a data-driven structure. Other existing menus will also get updated or rewritten to use the new system as well (eventually).



To somewhat explain the screenshots - the root node of my gameplay data hierarchy is a "series", which may contain any number of "campaigns". For example, many games have a main story, then 2-3 more campaigns are later released as DLC, each having their own unique story, worlds, characters, art style and whatever else. All of these releases would be part of the "official" campaign series. Each campaign may contain any number of scenarios spanning any number of worlds.

A "scenario" is generally gameplay, such as a route laid out with content and objectives. There are 4 ways a gameplay scenario can end. It can be aborted, you can fail, you can complete it, or you can complete it along with all secondary objectives. Aside from aborting, any other ending can lead to progression. Usually, time running out or death would just lead to the same scenario - i.e. try again. But it doesn't have to.. failing something can lead to another place you never would have seen otherwise. The same goes for completing all objectives - depending on how well you're playing you might end up in a completely different world, story arc and/or difficulty.



I also plan to have several types of scenarios (maybe a better term is "events", but whatever). The only type currently is "checkpoint", but there could be a "cinematic" type first that guides the camera along the route or through the scene however and ends up at the starting line.. or a mini-game, or even just a choose-your-own-adventure style dialog tree of some kind determining which scenario is next based on response.

And finally, it's worth noting that scenario objects (enemies, powerups, etc.) can also be structures, fences, rocks, ramps, whatever. It will take careful consideration to also get rail editing integrated in a user-friendly way, but I wouldn't consider the editor ready enough for releasing along with the game unless that's a part of it. Anyway.. time will tell!

 

So! Yeah - progress. The foundations for in-game editing are definitely solidifying. Check out the video and/or play whenever at the link in my signature. All you can really do right now is browse the route / scroll through the objects. You can rename them or delete them from a scenario and they're gone from it when you play - it's realtime editing, but for these WIP builds it will only be until you close the app.. don't worry to break anything hitting "save" button. If you delete a bunch of stuff and can't play anymore just hit "load" (unless you saved over it.. then just refresh the page). Click on an object in the list to jump to where it is along the route. The sliders under "scenario properties" are all functional but still rough.. including the sliders themselves. It was actually a bit of a push at the end to get those in today, because it's also the start of generic property lists, which will be used all over for whatever. Not much to see - but much has changed under the hood. Also lots of random glitches cleared up, probably a few new ones lurking about.

The build shown in the video is on the site - created with Unity Engine 2021.2.0a5, URP 12

 

Since last week (in the live build anyway), Themes from my previous UI framework are now functional in the new one, got their colors imported and they're switchable like before. The Options menus are also moved to the new UI system ..although still very rough, haven't refined/finished my slider component either beyond basic functionality. Panel backgrounds, buttons and list items are now sliced/have rounded corners, but as with most design-related decisions I'll think more later on how I want it to look,.. also minor changes to Shader Graph for text so it would be more legible when a dark color (previously had outline.. which it still does in gameplay but not UI), and seperated the UI icons from text glyphs - they're now in a different sprite sheet and no longer being mipmapped.

The text input component is better / mostly complete aside from adjusting colors per theme a bit. Works in fullscreen WebGL, though limited to characters used in the game - A-Z, 0-9 and punctuation only, with 3 glyphs missing since the original font doesn't have them (~, `, |) and I don't particularly care to spend time mocking up placeholders I just skipped them entirely, typing them does nothing. Supports all [or most, in case I forgot any] mouse and keyboard selection shortcuts / combos of shift, ctrl, arrows, home, end, clicking more than once at the same offset in a word to select the entire word, again to select all, cut/copy/paste shortcuts (ctrl-X/C/V) between different inputs etc.. note the little "console" button at the top right of the app still uses a javascript prompt though, and itself is still part of a previous UI (I actually have 3 systems running in parallel at the moment - the urge to clean that up is partly responsible for my shift of focus).

Options can now be adjusted freely while driving around / looking at the scene, as that's now a panel down the left of the screen instead of in the middle, so it's no longer obstructing the view. Again, rough compared to previous UI, but done up to a functional state. Other minor cleanup and fixes.

Locally, I also have the previous system/help menu replaced, with navigation between Help|Build Info|Attributions via buttons above the panel, similar as options tabs. I won't be upping another build for probably a week though, maybe two - big changes going on beneath the surface that will take a while. Also worth mentioning that right now you can only use the mouse wheel to scroll lists, no scrollbar on the side or dragging to scroll like before. Feature parity (at least features that are needed for this title) between previous UI system and this is still very low priority vs. everything else going on, but basic stuff like that will eventually be back.

What I've done recently (already, in the live build) has things like buttons and list items and panels and progress bars and text and other stuff all getting reused by all menus through pooling. To illustrate - ignoring overlapping transitions or multiple being open at once - if I have 50 unique menu layouts with 1-10 buttons on each, that really only needs 1 panel prefab instance and 10 button instances in memory, total, ever.. with their content configured through data when pulled from pool. That benefit alone makes everything I've replaced feel like one less burden on the mind of my software. I'm happy with what I'm doing now - but it's taken several iterations since I first learned what a GameObject was to arrive at this approach XD

And lastly for now, where the UI is concerned I'm also in the process of scrapping all Renderers, and the entire UI will be reduced to [typically] just 3-4 batches, except when panels overlap or any other time depth sorting between visible ones needs to be done ..like for exclusive mode (alert/prompt/confirm) or if I want menus on walls or whatever. Locally I've got a good portion of this together already. It will also improve performance and reduce memory consumption in other areas related to UI and text, including that I'll be able to do away with quite a bit of code that currently runs every frame but won't need to anymore.

So yeah.. boring work maybe, but nevertheless important to me for peace of mind and feeling good about moving forward.

 

Pretty much did what I mentioned last week - significant overhaul to UI systems including new standard dialogs (alert/prompt/confirm), far less batches for UI (probably 1/10 of what it was, or better), also got Objectives roughed in (stats during gameplay and on Game Over screen for a few I did for now with each scenario). New pause menu / exclusive mode. Options will eventually land there as well - for now you can't adjust them while it's paused, have to do that in between scenarios or in editor mode. No video this week, been a long day, but the build is live and here's a few screenshots I might post a video in the near future, but sticking to weekly post.

 

Another week down - pretty happy with progress. Most time was spent refining less mature systems and getting basic users/online/related scaffolding in place. I won't touch on details of online aspects much for now, aside from saying there won't be any real-time multiplayer.

Users may now [optionally] create a basic cross-platform account. No personal info is required. Joining and signing in again later is functional. Password recovery is not (and obviously won't be for effectively anonymous accounts). Display Names and Avatars are moderated (but can't be submitted yet anyway) - these will be used for display on challenges and leaderboards and must clear the moderation queue first. Users will have no means to communicate or identify each other and all open content will be tame (i.e. suitable for open access on a website, imho). See Help->Disclosures for more info, that's where the gist of random stuff that occurs to me goes for now, but please bear in mind that anything here or there is subject to change between now and release.

Invitations to custom campaigns will not be allowed through leaderboard or friend challenges, unless the user previously unlocked the custom campaign with an access link and key provided by the creator (which will never be supported in-game.. the creator must use their own discretion/verification about who sees their content). As content in custom campaigns will not be openly accessible, this will prevent people from sending random invitations to content that might not be suitable for the age or disposition of the other user - at least from within my games. More details on custom campaigns will be provided in the future.

Player list at the bottom left, hopefully unobtrusive. At the moment this is for Player 1 only. I'll probably add an option to disable the list entirely (for anyone that finds it distracting or TMI). More details of offline and online gameplay modes will be mentioned in the future. If you click where it says "offline"..


If you click "Join"...


Then by filling in everything and submitting the form, ..if the username wasn't already taken (the only current condition for success), you'll see it has replaced "offline".


Clicking your username will ask whether you'd like to sign out. Later in development it will open an Account section with several tabs or other form of navigation. If you don't sign out, you should automatically be signed in again if you refresh the page (or until signing in somewhere else, which invalidates the token - or until the browser session is cleared).


If you click "Sign In" from the account prompt..


I haven't decided to what extent the game will feature themes yet - something that's occured to me recently is that they're likely to conflict with custom campaigns. If you want part of your campaign to have a specific feel, an opposing theme would entirely ruin the presentation (i.e. a moonlit run along a lakeshore might be less immersive/enjoyable with a bright interface). So I'm now thinking it will only apply to specific game states (editing, overlay/exclusive mode menus etc.).. and allow creators to override the player's preference to some extent per campaign and/or scenario. This would also allow for customizing contrast, how themes complement the environment behind them, etc. Anyway, I'll give it more thought, but I'd say that's where it's at.

 

A few things achieved.. revived previous test world, updated a few things about it. Not fully updated to new systems yet.. also, that gameplay style (with no defined route, open world-ish vs. specific progression) is now a scenario type. internally, rails and minigames can be flagged for inclusion in whichever scenarios (a minigame currently just shows 'challenge' with time limit and #/# collected, and it still uses ones of the previous appraoches to that kind of thing, which is just mixing with the compass area until I get around to updating that stuff as well.. they activate when you get close enough).

Fixed a number of outstanding glitches, flythrough mode camera doesn't freak at floating origin anymore, some other random stuff cleaned up.

Updated grappling and rail attachment approach. The physics way previously in the live build isn't generic enough for airborne stuff, you'd just be rubber-banding vertically as well without overriding it anyway, and definitely will have lots of rails that are in the air (like a couple in the city environment).

Multiple control targets are now implemented, there's a gamepad icon that appears on hover of anything you can switch to. Passengers! Taxi-genre/style scenario test will be soonish, along with "Deer Clear" test scenario, honk horn to scare deer off the road.. no animals in this yet, ..almost made it in for this week but bug hunting took precedence.

Each scenario will have any number of options of control target for player to select from at start, and each option can start with any number of passengers. Specification is via string arrays (addressable id), so should be easy to add stuff to editing where you pick what kind the player will be controlling.. eventually, if editing even makes it in for initial release.

In-game, jumping between controllables means you could click a turret and immediately be using its weapon systems and available cameras, then click a car and drive a bit, exit the car as a biped and walk around (press E.. currently is free asset "Rina Elven Assassin"). The biped controller is procedural, I used free Inverse Kinematics asset to get limbs working appropriately. It's still rough, landing from jumping doesn't re-align the feet immediately etc., I'll get around to it eventually.

Some new controls..
- E, exits vehicle if you have a driver (currently only in the city world).
- C, crouch toggle
- caps lock, run/walk toggle
- Q, taunt (walking) or horn (vehicle)
..i think that's it.

exit as passenger by clicking a passenger icon..


walk around.. enter buildings..


get in a vehicle


I'll be uploading the above build soon - it's still building. Time marches on!

 

It's been another great week, more time with Netflix etc. than anything productive, though I did manage to clean a few things up, fix a few glitches, rough in a "taxi" style minigame type (and "taxi service" scenario type, which I might extend for the purpose of tying things together for progression), passenger pickup/dropoff locations and indicators including display of distance to dropoff while driving. Added a number of objective types (# passengers delivered, # of minigame completions by rank, max number of fails, probably more I'm forgetting), ability to set arbitrary time limit for a scenario (previously the only time limits were for a route where you get more time from a checkpoint, and per minigame).

To clarify somewhat, a "minigame" is really just shorthand for "things to complete that are in a group". So for example the groups of stars to pick up in "minigame hunt" scenario type is just base functionality - can be a group of enemies, an opponent's base of some kind with whatever to destroy, or a "traditional minigame" with a unique interface that pops up, or dialog of some kind triggered by it, whatever.. so the taxi thing is just a new minigame type. I took a very abstract approach to stuff like this early on.

Each of these can belong to one or more scenarios - same as rails and powerups in their current form (not counting "checkpoint"-style routes, which are optimized for linear progression and each are defined for 1 scenario only). Also, any scenario can be populated with a mix of different minigame types, so like pick up a pizza delivery guy whose car broke down, shoot a bunch of pizza-thieving helicopters on the way to drop him off, grabbing some secret cluster of stars/coins/gems by driving through the window of a building and catching a hidden rail to a rooftop (which only displays when you're near the entry point, since the radius at which a rail transitions in/out of activity is defined per rail).

Not sure what else to mention.. I've got a movie paused right now, just getting this together to keep the weekly post thing going. Just put up latest build a few moments ago. And a few pics of the taxi thing to wrap it up:


So in the above, once you get close enough to trigger pickup (or click one of the people waiting ..to trigger it without getting closer), as expected everyone runs to the car, then time starts counting down and a new indicator appear in the world and on the compass.. though if you're really far away, it's only visible on the compass until it's visible in the scene by getting close enough.



The blue indicator is dropoff point if you have a current taxi thing in progress, green indicator is just another nearby minigame. The grey "+932" is how many points you get if you delivery with 10 seconds or more remaining (it'll start counting down to 0 once your time drops under 10.0 remaining). That's all for now

 

I've given several days of thought to what I'm doing and revisited some decisions about what's "necessary" to do before moving on to the next phase of this. Looking at my original post, "By the end of the year I'm hoping it to be a solid foundation for my first title with Unity Engine." It's now 4 months later than that and I'm still playing with ideas that could have waited. Yikes. So.. despite a few wild tangents I've been lost on, I'm back to that being my primary goal and that's where my attention is going to be for the remainder of the year. After this game, I'll immediately be moving on to my next game or [possibly] publishing a few assets for a change of pace. Although.. if I'm really into this by the time it's done, maybe I'll take it further? Depends if I'm bored of it by then or not.

After this month/as of May, work on this will be 99% game-specific. I'm allocating the last month of the year for fixing whatever comes up along the way and whatever final touches prior to considering it 1.0.0. Anything not road-worthy by December 1st won't make the cut. December 31st is tentatively my "launch date" but I'll only be releasing this on my website (initially, if not forever) for WebGL and whichever desktop platforms I have dedicated testers for. I only have Windows 10 myself, so at a minimum it will be for WebGL+Win64. From May 1st through December 31st the game will only be open to testers (either in full or portions thereof depending on what's being tested), though I'll still post occasional screenshots or video throughout development. Anyone that would like to participate in the QA process, please feel free to contact me.

For April, my agenda is to finalize the startup sequence, where my user selects a game - except when opened from a link for a particular game, which will bypass that. This will then load and display a splash screen unique to the selected game as the initial world downloads. Each game will have its own menus, with layout and design mostly specific to it. Only the system icons in the top bar will be consistent between games (though not Options or Help navigation/submenus as they exist now, which is utilitarian at best and would require spending more time continuing my new UI systems). Most of the HUD related to compass etc. will be fine as-is with a bit more polish.

I also want to finish everything related to users submitting a custom Avatar and Display Name and do a generic solution for leaderboards along with some basic cheat protection. I have prior experience with all that, FFMPEG is set up (which I'll use for converting and resampling uploaded avatars from whatever valid format into a thumbnail) and there aren't any other technical barriers.. so it should be reasonably straightforward. As mentioned previously, these have to be moderated to allow for display on open leaderboards, so a user-friendly way [for me] to navigate the queue and approve submissions is also something I'll need to do either this month or in December.

In addition, I want to clean up my crosshair with an auto-aim/assist for whatever's within it (as opposed to just being whatever's under the dot), along with some visual improvements. I think that's it for generic stuff for now - and for me, that milestone is a pretty big deal. After that, whatever time left in April will mostly be with the Profiler and optimization, workflow improvements, and thinking through scope/self-limiting what I have in mind based on what I can realistically do with the time I'm willing to invest for the rest of the year. Next year I might expand weapon systems with accuracy stats and powerups and a mod system or whatever, depending on whether I want that for something or not, but I think for a casual genre game it's over-complicating anyway.

Some other arbitrary decisions - the Options menu for a specific title will only have a few sliders and checkboxes. I don't want to dumb it down too much, but honestly it's mostly overkill and full of stuff that would never be changed from the defaults anyway. Help will just be the conventional "image of keyboard keys with lines pointing at text of what they do". There won't be any control customization, though the exact layout isn't something I've settled on and towards completion I'll seek a round of feedback before I do. If feedback appears to indicate there's no general consensus, I might put the time in for selection from layout A, B, etc. as a compromise.

Tutorials will be simple "how to play" instructions with some images and text. My extended plans related to that (interactive tutorials with gameplay) can wait on a future title. And finally for now, Theme will be something particular to the game or auto-switch between one of several depending on what's best for contrast with the environment and readability. There won't be any user-driven option to change it - this would be too much of a time sink otherwise where variability and aesthetic conflicts + solutions are concerned.

Aside from having a variety of worlds and enemies etc., I want to keep this as simple as possible for what it is, which is now essentially "completing a scenario to reach the next, while doing your best to collect stuff and achieve objectives.. with 100% completion of said objectives unlocking/branching to secret scenarios that can't be reached otherwise." It'll mostly be composed of free/CC0 assets and whatever I put together myself, aside from a few exceptions with assets I've already bought (plus a couple of others from what I have saved in Favorites on the store). There won't be any 3rd-party advertising, but down the road I will add cross-promotion of my other titles on the main menu or wherever seems appropriate.

That's enough blather for this week . Next week's update will probably be related to the game selection process and whatever else mentioned above that's progressing well or done.

 

Game Selection is now implemented and is a functional part of my startup sequence. When a game is selected, the default series data for it is loaded (either from embedded data or via network) while downloading the splash screen. When the initial series data is ready and the splash screen for the game is displayed, download of the game's initial world begins. This is either the world defined for where the "Main Menu" of the game will be displayed, or - if it starts with a specific scenario - the world defined for that scenario. Previously I would embed the first world, which isn't appropriate for a system with multiple games.



Over the course of the next week I'm aiming to wrap up everything that would get in the way of having hundreds of worlds spanning dozens of games, each with unique content, all available within the same application. Yes.. that many worlds and games will probably take years to create, but I'm not going anywhere (at least by choice). It's a future-proofing kick I could avoid for now, but it'll bother me if I don't since I'm pretty close to having it already and this is the last month I'll be spending with a primary focus on systems. It's sort of a now-or-never kind of thing.

There are still 3 remaining barriers to this ideal. However, they're reasonably quick changes (except possibly #3, which will require a few related changes to pull off nicely).
1. I have most game-specific prefabs grouped within a single larger prefab (done early in the project with exactly this in mind). I need to set that Addressable and add it to the startup sequence.
2. Similar to the above, I have a GameObject in the scene which contains a few larger meshes used in other prefabs to prevent related stutter if first initialized during gameplay instead. These are also game specific, so I'll either be changing that to be downloaded concurrently alongside the world and the above, or just merging that into the above and move it to the scene from there after download.
3. Finally, BGM is currently included in the application. I'll be changing that system to Addressables as well.



I'm still on the fence about keeping the existing test worlds and scenarios around beyond May 1st - so anyone who'd like to see these prior to then has about 3 weeks to do so. There's a good chance I'm stripping these (vs. just restricting access) to avoid wasting any further time on maintenance. They were always intended to be temporary and the timing is right to leave them behind.

 

A few things achieved so far since last week. Solved all 3 barriers mentioned in my previous post. Also solved a 4th that came to mind along the way (game-specific audio - which is now also part of what's downloaded after a game is selected instead of being part of the application itself). Whichever BGM are needed by a particular game for a particular world are now downloaded/loaded from browser cache via Addressables while a world is loading.

Drag-and-drop Avatar uploads are now implemented for both WebGL and Win64. Drop an image onto the game when prompted to do so (from Membership menu when signed in). Click anywhere or hit ESC to cancel. Below the abstraction layer is the [free] FileDrop solution for WebGL and the free solution by @Bunny83 for Windows.






Uploaded Avatars are resized and cropped to a 256x256 PNG on the server and a secondary 64x64 thumbnail is also generated for display in high scores tables. The uploaded file itself is not stored. If a member uploads a semi-transparent format such as PNG, their avatar will have transparency as well. I've also added a "Delete Avatar" button that immediately removes a member's avatar and thumbnail from the server.

Display Names are also now implemented and can be submitted for approval by entering a new one. Whether approved or not, changing the Display Name appears to be immediate for the member themselves. "Public Display Name" shows what everyone else will see until it clears moderation, which will either be a unique "new___" string provided by the server initially or will be the most recently approved Display Name.

I still have a few things in the works related to the Membership menu and haven't done an interface for moderation yet (for myself), but aside from a bit of time with moderation-related stuff I'm pretty much done. There's a "STATS" button which does nothing right now, but will at some point prior to release. Basically completionist-related. More info on that when implemented.

I also have most of the groundwork done for a user to share a stats "card" via embed code, which will basically just be a URL returning a banner image containing their public/approved display name and avatar along with things like rank or "#/# scenarios aced" or whatever (actual content tbd later). I haven't decided whether I'll release this feature initially or not, but I do eventually plan to.

 

I've been reasonably productive since last post, pretty much everything mentioned for this month is done ..aside from High Scores, which is the last new systems-related thing I'll be adding for now.

I've updated weapon targeting - there's now an aim assist/auto-aim that prioritizes specific targets like enemies or collectable-by-projectile objects like stars. Changed the crosshair from being a single sprite to being a mesh with eased expanding/contracting of "pieces" (procedural mesh + Shader Graph). For enemies in particular, the outer edges of the crosshair expand while aim assist is active (which right now is always). The crosshair dot now hovers the point of aim-assisted impact when applicable (instead of always being in the center). This applies to all current weapon types. A few of the ways players can interact with the world via context-sensitive hover:


I'm not quite happy with changes yet / still need to clean a few things up, but it works well enough for now. There are 2 other types of interaction not shown above which will likely make their appearance later - teleporting to another location in the world, and teleporting to another world. Click or shoot or collide to trigger.

There is now menu BGM per game, which persists/plays between scenarios and during scene transitions. Later I'll add a button somewhere that lets the player cycle between several unlocked menu BGM and having it turned off. For now like the other BGM I'm using random [free] stuff from freesound.org. It can just be turned off by turning BGM volume down in Audio Options or by clicking the Mute button.

Each member now has shareable/embeddable stats cards. These will have whatever on it relevant to the game (rank/completion/etc.) but for now has live update of their most recently-approved display name and avatar and the icon of which game the card applies to. Clicking "stats" button for now in Membership menu will open a new browser tab displaying the card along with info for downloading or embedding, i.e.:


And this is the live card itself, added via Image button:


Another significant change since last week is using the [free] Howler library to drive audio in WebGL builds. Now managing all sounds+BGM through that via .jslib. There were audio-related issues with my project after upgrading from 2021.2.0a12 to 0a13 that I couldn't immediately sort out, so I figured I'd try integrating that. I haven't tested beyond my laptop browsers (Windows 10, Chrome/Edge/Firefox), but I can switch back to Addressables by removing a define from project settings if what I'm doing isn't as compatible as the built-in solution or for whatever other reason. I'm now using engine version 2021.2.0a14, so it's possible the issues I had with 0a13 have been resolved already, but either way I'm happy with what I've done - seems to be working well so far.

Also resolved a number of glitches and made a few random improvements. So.. onwards! My schedule for this game currently looks like:

Now - Apr. 30:
- Final systems-related cleanup, adding High Scores, spending time with the Profiler.
May 1 - May 31:
- Game-specific menus/layout/flow - everything the game will have aside from content like more enemies, powerups, items, weapons, worlds, routes and so on.
Jun. 1 - Nov. 30:
- 6 months in a creative state of mind with a focus on content.
Dec. 1 - Dec. 30:
- Lots of testing, random game-related improvements and cleanup, final touches, profiler.
Dec. 31:
- Release [on my website] of my first and only title of 2021!

 

Amazing week! Firstly.. High Scores:



Online ghost racing (add ghost of any high score! click members in game over list to add, then click each in the list at the bottom left to remove:


Offline ghost racing! After first attempt, you have ghost of best attempt so far this session with movement and score incrementing:



Scenario Launch (before starting one):


That's enough to mention for now. Until next week

 

It's been a while since the last video, so here goes:

Highlights of changes/additions since last week's post..
- Now showing the current position while competing next to each player along with the current score under their name in the list. This is ongoing throughout the race so your position can increase or decrease while you play. The final results are determined by when you end the run.
- High Score items now have an indicator to their right while the corresponding player is added. "P2" means Player 2 for example. Clicking the name in the list toggles whether they're added or not (clicking them in the bottom left also removes them, which was previously the only way). Removing a player while playing now also removes the ghost racer of the removed player (bugfix).
- Added a spinner to the right of player list items while ghost replay data is downloading (which happens during "3, 2, 1, GO", usually fast enough that by the time GO hits they're starting when you are). If it takes longer they will just catch up and their placement/score display will update as usual. If the player has no record for a given scenario, they still appear in the list but there will be no placement and the score will just say "Player #" instead.
- Passenger capacity slots on the HUD now only display when the current scenario type allows for passengers (vs. checkpoint thing).
- Menu BGM now continues to play during the scenario launch menu (as was intended/bugfix), although I may later add an "about to begin" BGM while that's open.
- Scenario launch now has a "back" button and will return to the previous menu (either a list of scenarios, or the results screen/game over), instead of the Campaign being abandoned and returning to main menu/campaign selection.
- Integrated the minimap/route preview with the new UI system, now displayed beneath BGM. I haven't yet added the total distance label like previous sytem had (i.e #.# KM).
- Cleaned up Main Menu and Scenario Selection somewhat, menu transition timing improved, various UI-related stuff.
- Added earning of points for objective completion. Added an "objective complete" kind of message along with display of how many points it was worth.
- Added a toggle above the Objectives list that displays while playing and can be clicked to show/hide the list whenever. The setting persists for the session. Items in the list of objectives during gameplay now only display the additional information text while hovered, although I will probably display that info while the "3, 2, 1, GO" thing is busy and just close them up at hitting GO. The text of the toggle itself shows how many are complete so far, whether the list is open or not, i.e. 1/5 OBJECTIVES.
- BGM objectives now respect what has been previously collected during the current session, since the BGM 'powerups' don't appear in the world after you've found them but may still need to be "found" during that run in order to get a "PERFECT!" rating. The # collected now increments when it becomes reasonably close enough to be considered clickable, so you still need to reach the general vicinity of where each was.
- Changed the crosshair to have smaller context icons (hand, gamepad, grapple, etc.), and not to show the grapple icon while holding down the firing button (will continue to target enemies etc. with crosshair instead, unless you release firing button/LMB).

For the next week, my priorities are..
- There is currently no "race results" kind of thing shown after a run with more than 1 player (though I currently do leave that info visible after a scenario ends until the list changes or the completion/ending dialog is closed). I'll be displaying something for the actual result of the competition, probably just before the results/High Scores that exist now, with a button to continue.
- After completing the final scenario in a Campaign, currently it just goes back to the first scenario. I'll be adding a "Campaign Complete" window along with how well each scenario was handled, i.e. scenario name and underneath each will have a line of mini-gems that are filled in green for completed or gold for perfect. Offline players will see if for that session, otherwise the completion displayed is cross-platform from their membership.
- All scenarios are currently unlocked by default / available to start from within a Campaign. The actual flow will be that in order to unlock a new scenario, you must successfully complete the one that leads to it. As mentioned, there will also be scenarios you can only reach by completing somewhere with a "PERFECT!" rating (all objectives completed). Currently, the "Continue" button on results is already disabled if you fail, you can only Try Again or abandon the campaign.. but you can still just start from whichever one you want, so it's meaningless.
- Whatever else can be done with whatever time I put into this after the above.

Aside from the above, I'll still need to do the new Help and Options, but I'm leaving that for week 3 this month. Then the remainder of the month will mostly be related to optimization and workflow updates/improvements in prep for next phase. Then as of June - new worlds, enemies, powerups, etc.. content!

 

- Cross-platform savegames! Savegame data includes unlocked scenarios and personal best scores, objective completion, BGM collection and any accepted unlock codes.
- Seperate savegame while "offline"/not signed in. This allows progression independantly of any online progression, and multiple users to sign in/out and work on their own completion.
- Scenarios are now unlocked in typical Campaign style of completing the one leading up to it. Which scenarios are unlocked is auto-saved.
- BGM collection now persists / is auto-saved. Starting a scenario with previously-collected BGM means it can be clicked on immediately to switch, vs. having to find it first.
- Unlock Codes now persist / are auto-saved. These can now also be deactivated/removed with a minus prefix. For example a "test_something" code could be deactivated with "-test_something".
- Added an Unlock Code "uas" which can be used to unlock all scenarios in the "open tests" game. This may be deactivated with "-uas".
- There is now a save indicator in the bottom right which displays while the game is attempting to save. Retries are automatic, staggered and there is no interaction. The indicator transitions out when saving has been succesful, unless save was queued again while it was busy (in which case it will save the new data first).

- Completing only 1 new objective in a new attempt at a scenario will not "ruin" any objective completion from previous runs.. they accumulate. This means you can go back to hunt down the last remaining objectives you haven't yet completed.
- Lots of stuff related to display of which objectives are still needed (on scenario selection lists, scenario launch menu, scenario completion menu, in campaign completion details, expanded or hovered objectives list items during gameplay).
- Added Campaign Completion progress from a "stats" button on Scenario Selection menu. Also displays at abandoning a campaign or after "congratulations!"/campaign completion.
- Campaigns can now require other completion to unlock. The same "uas" code will unlock any locked campaigns in the "open tests" game.

- Now possible to sign in/join/sign out while the Scenario Launch menu is open. Previously trying to open the account prompt while this menu was open would do nothing.
- Added a phase before High Scores where new things that have been unlocked are displayed (if any). This includes unlocking of new Campaigns or Scenarios, new BGM collected, or first time achieving any given objective.
This also displays when getting a higher score than your previous personal best for that run along with how much higher the new score is.

- Added particle systems for some menus (campaign statistics, competition completion, campaign completion, new stuff unlocked). Found some confetti and fireworks kinds of stuff in a free asset on the store
https://assetstore.unity.com/packages/vfx/particles/sherbb-s-particle-collection-170798
- Added competition completion window - a "Race Results" when there's 2 or more players, along with fireworks particles and a few smaller particle bursts at the player's placement position to see more quickly where they ended up. Layout is different based on how many players (2-8), with larger avatars etc. when there's less players.
- The Help and Options menus can now be accessed while paused. The dark overlay disappears while they're open so the world can be seen while adjusting options.

 

I decided after last week's changes (with Help and Options being accessible while paused) that I didn't need to take a new approach to that stuff anymore. I think it's fine as-is. Can now also toggle paused/playing while that stays open (with the top right corner pause/resume button). A few other changes of note..
- Added a "revert" button on options/preferences (at the right side of the navigation bar) that immediately resets the options back to defaults for the current platform.

- Changed the "reset" button for a campaign to also clear any BGM that was found in it from the player's collection. Note that some BGM may be found in more than 1 scenario - these will reappear wherever they're usually found until recollected.
- Added a new Other option called "+personal ghost" (called that for now - will probably change the label later) and moved a couple of others between categories. This is enabled by default and means you always compete against the ghost of your own best attempt in any scenario for which one currently exists (in addition to any other players). "offline"/guest players' ghost replays do not persist beyond closing the application. For members, ghosts are the highest recorded run per scenario - getting a new record replaces previous ghost data for the given scenario.

- Changed the text "G:" in the local players' list item to be the ghost icon followed by the current score of it relative to elapsed time playing (i.e. if you're 30 seconds into the scenario, the score displayed is what the ghost has at 30 seconds in). If you win against your ghost it's part of the "stuff unlocked" screen as like new personal best or whatever. This text in the local player item is now either red (while it's beating you), white (you have the same score), green (you're beating it) or gold (your score so far is already better than its final score). If there's no ghost, the text is white and just says "player 1". For other players, if they've never attempted a given scenario, their text is grey and semi-transparent, and will say for example "P2 ABSENT". This will happen if you challenge someone from high scores of a scenario, then go play a scenario they've never played. You can compete against the same people throughout the game provided they've played the same scenarios - otherwise they're absent but still visible in your players list for the session. It'll be easier or harder to win based on who you're trying to outrank.. if you do win against an online ghost (when signed in), you will then be ranked higher than them for the scenario and be further up the list - but of course this is the case whether you actually see your win against them or just get a higher score.
- Further changes to my WebGL template, also changed structuring related to initialization, now less waiting going from application init to selecting a game thanks to some concurrent loading via ajax while the application itself is still loading.
- When a campaign is completed, the menu for the next campaign is now automatically opened after closing the congratulations/stats displayed at completion. Previously, completing a campaign would just show you the list of scenarios for the same campaign again and you'd have to navigate back to campaigns list then click the new one. Now you can just click "continue" or click the first scenario to keep going.
- Fired projectiles are no longer wasted on further hits to something that's been destroyed or to its debris. Airborne projectiles will immediately continue on to hit the next enemy behind a destroyed one, for example if there's 2 enemies in a row and it takes 5 shots each, exactly 10 projectiles will be enough, no matter how short the burst (not counting any health regen the enemy might have). This does not apply to my "Tosser" class of weapons, which just throw an object into the scene with physics. This change made everything a bit easier, as less projectiles will typically need to be fired now in order to clear the screen.. particularly evident in a run through either of the current tests (Highway 1 or Service Road) while holding down LMB with the rifle.
- Powerups can now be collected by dragging over them while firing. They also could previously, but would need to be hit by a projectile before collection was triggered, so often there would be a delay or it wouldn't always be picked up when expected to be.
- Added a subtle texture scrolling to background of the game selection area in addition to the other effects, with a matching scroll for the background of the web page.
- Changed how data for objects of a route layout are stored. They were previously part of series data, which was the wrong place to have them for a number of reasons. Now, each scenario can more easily be updated independently and doesn't require also loading/needing data for the series or altering and resaving that like before. This is part of what I needed to do for next week's stuff.
- Fixed a number of issues I'd either put off for a while or created recently along with changes. There still are a couple I'm aware of but they're probably gonna wait for December since they're not urgent or game breaking at all. A couple of the most significant fixes this week were 1) a previous score (from personal ghost, when it existed) would appear in the info that shows placement after a scenario instead of the current run's score, and 2) buttons on both scenario launch and completion being glitchy to click sometimes - it turned out I had 2 copies of the buttons spawning over each other, so z-fighting with colliders was making hover states blink or not respond properly to mouse events etc.

There are a couple of other things I'd like to add that can also wait for now.. for example, for members, "delete my account" and "delete my data" buttons. Also a BGM Collection browser - to scroll through what you've unlocked and play each BGM and see what's still missing / the % collected etc. Probably having the title obscured with ? instead of letters and the second line giving info about where to find it. I'm also thinking a checkbox with each clip, so any in particular that someone doesn't want to hear again can be disabled and won't ever be played during gameplay.
i.e.
[ ] ?????? ????? ?? ?????? <-- the hidden title of a BGM not yet found,
Highway 1 of Test World Tourist <-- ..along with where it can be found.

So.. as of now, down to the last 10 days before starting on the first world! Until then, everything I'll be focused on is boring - almost entirely workflow- and tool-related to get whatever into shape and reduce how much time I'll need to spend on laborious tasks or far-more-clicks-than-necessary irritations with editing, along with some attention to whatever really bothers me the most about whatever random stuff bothers me wherever (in code)

I do still need to invest some effort into a solution for water (and possibly some reflections, to whatever extent is lightweight enough for WebGL when combined with scenes like mine - for my laptop at least). Probably touching the water with your vehicle will just put you back on the road, as I don't intend to have any underwater gameplay for this title or have any immediate plans to put time into related stuff, so it's very low priority.. aside from a surface that hopefully comes off as water (a blue plane with some sparkles would be fine, but I'll probably go a bit further or find/buy an appropriate solution if nothing I have right now would be a good fit).

As for the first world, despite getting ahead of myself a bit.. I'm thinking tutorial-like to get things rolling, as in driving a very easy route dodging some traffic cones or whatever. I'm not sure about environment yet, but most likely there'll be water, since it'll corner me into coming up with something for that more urgently. In very early tests I did (like how the menu world was when I first created this thread) I did already have functional for water, but I didn't like it. Anyway, always plenty to do! And forever to do it

 

Since last week most progress has been with editing-related stuff (the in-game editor shown in video a while back for route object instancing/placement and scenario management, plus Unity Editor ones). I could list off additions and improvements but since that's not going to be exposed to users and it's boring to read (and write), I'll mostly avoid the details.

However, to summarize (so there's actually something in this post).. I can now use my in-game editor for populating routes (vs. just browsing/renaming/removing the objects I'd added earlier via component-based tools). I'm now able to select whatever type/subtype from my properties panel (like 'Helicopter 1'), scroll along the route and click to add new ones wherever, easily duplicate, set offset from the surface, drag-scroll position/scale/rotation values, pick from vertical orientation types for the instance's rotation to be relative to (i.e. absolute, around up from surface, around right by path normal, etc.), click somewhere to select the nearest object, ..basically the minimum of user-friendlyness needed to place whatever enjoyably / without getting frustrated by the process. A couple of other features for that over the weekend and it's even more good to go.

Also, I now have the ability to save and load scenarios or series structure both in-game and in the Unity Editor inspector, so I can edit whatever, click save, exit play mode, then click load in edit mode to update what's included with the build. I can also step back to a previously-saved version of a route if I need to - I haven't had to revert changes that way yet, but at least it's possible if I need to given saving doesn't overwrite previous one, just has a higher id (and loading whatever loads the most recent layout saved).

Non-WebGL builds won't require the internet. It's only required right now because I expire WIP builds older than the most recent and don't continue hosting their content for long. By contrast, a standalone release will include what it needs vs. WebGL loading from a web server. If someone wants to use a year-old desktop build and not update they'll be welcome to.

The only significant bugfix this week that might be noticeable is with my slider UI elements. While their handles were being dragged, if the mouse wasn't moving, sometimes it would jitter back and forth between two values where the step was low, i.e. a slider like MSAA with just a few 'ticks' to snap to was fine, but if the number of ticks was less than pixels, float precision with world space UI while camera is moving could cause a dance between allowed values. That's now resolved.

So.. before next week's post I'll have switched to content creation and actually be having fun with this! First campaign will be "Tutorial" with a scenario for each major feature (movement, checkpoints, rails, powerups, weapon systems, etc.). By the time that's done, whatever rough edges or issues that arise with workflow should be solved and I should be in good shape for the rest of the project.

I still don't know what I want to do for trees.. it would be fun with like low poly trees bursting apart all over the screen getting hit by stuff, but haven't decided. I already do have code in place for removal which can easily be extended for destructibility though, so it's an option. I also think it might be fun to be able to crash through guardrails etc., but that can be specific as opposed to generic, right now they only get destroyed by blasts. but maybe some kinds you could drive through give boost and/or points.

I also want to add a layer of variability to how things come apart, with adjacent pieces sticking together at random and maybe based on strength of blast given radius, so for example lots of smaller pieces close to impact point but larger ones further away. I already have of the stuff that would require in place, like the direction of fragment motion and how fast they move from the source of a blast is already being used and I already know how I can do this idea. But these are systems I can extend and improve along the way and aren't an immediate concern.

As for how much content I plan to create for this.. best guess currently would be about 50+ scenarios spanning 5-10 environments. That's all for now

 

Since last week, I've created a new world for the tutorials in, a tropical-ish themed one.. water, sandbars, different groundcover plus actual 3D palm trees this time. I did the water in Shader Graph and may be extending it with ripple sources in the near future (for when things hit it) once I'm done the scenarios and related stuff for the Tutorial campaign. Lots of other random stuff achieved as well - but as mentioned previously there is no public/open access to anything outside the test worlds (contact me if interested in being a tester) until release (Dec. 31, 2021). Here's a shot of my water as it stands right now along with a screen capture of the Scene view during play mode showing part of the Tuturials world:


Here's an in-game shot without using 3D foliage I took a couple of days ago.. note the water in the above picture is my current version though.



I'll probably make an option that lets the user pick between simple foliage (like the 2nd shot - 2D billboards only like every world so far) vs. full-on 3D with LODs etc.. on my laptop in WebGL the difference is being at about 110fps instead of 140fps. That's all for this week

 

Most progress since last week is related to 3D foliage systems and water (adding reflections, fresnel with scene depth node, wave animation etc.).. aka sidetracked. I added an option for reflection so user can scroll between None on up to Full.. each having progressively more of a hit to performance, of course. These next two screenshots are at the setting for full quality.



You can switch between 2D and 3D trees in the "Graphics 2" options. I baked several variants for each type I use but this is set up now to generate unique trees at runtime, so for higher-end platforms the variety can be much greater with less to load (generating them at runtime in WebGL causes a bit of stutter, plus some variants have larger branches near the ground or whatever so I'm fine with just hand-picking a few of each type per world). Either way, each instance in the scene also has random rotation and scale within a given range and hue variation.. I think it turned out alright, but for my "beaches" I'll eventually make the terrain a bit darker where it meets the water - or add a water line to my shader so everywhere below-ish water is darker/tinted however.



Also added more lights to both test worlds / changed things up a bit with lighting systems. My supplementary one now affects distant LODs and I'm using it pretty much everywhere now aside from where full-featured Unity Engine lights are more suitable.



The 'current test world' now has 575 streetlamps, spinkled everywhere aside from just along the roads (plus a Directional Light for the sun and a Spot Light for the headlight). Updated the world for the "3D Foliage" option.
The 'city test env' world now has 312 streetlamps (the additional 200 or so added to the 'wilderness' areas of it). Updated the world for the "3D Foliage" option.



Previously in the city (until this update) the lighting was all built-in Unity lights, and featured 100+ Point Light streetlamps that actually had great performance. For consistency I've changed that world to use my own system. Also updated the streetlamps to be destructible like they are on the current world, so you can drive through them now instead of being stopped cold. There are still actual lights used in the city though - the ones on the tunnel wall, headlight and flashlights.

I also got one of my older systems that had been incomplete for a while functional (relating to the city building's having dynamic behaviour that affects multiple LOD).. and as a result there's now actually more than 10,000 windows with random change between lit and unlit during the night, though light from them is just emission+bloom. I haven't enabled Time of Day for public build right now, it's never had a daytime so I'll need to set a few curves for the day/night cycle and give it a nicer skybox and can't be bothered with my oldest remaining test world ..well, probably will bother me eventually, I'll finish updating it whenever so there's also a daytime.

That's all for this week.. hopefully for the next I'll be more focused on scenarios / actually getting the game done

 

Since last week I've done a tutorials system - I may extend this later for dialog if I need any. There can be any number of sequences of instructions and they can be with any scenario type. For example the first one in the tutorial is to press W to move forward - once you do it there's a 'ding' kind of sound effect with the objective complete thing and the next instruction appears. Completing any particular one can complete the scenario (so for a tutorial that would be by completing the final instruction). Each are sprites from a sheet (or sheets) included with the world, 512px wide banners showing keyboard keys and/or screenshot or whatever else the design of the particular instruction is. Each can optionally have a time limit and either complete or fail the scenario if related conditions aren't met.



So.. now I just need to do a bunch of them covering each aspect of the game and controls. I've got a few done so far, I'll probably spend this coming week just getting the rest done and refining/polishing this section of the game somewhat and the tutorial world (or worlds).

Added a "Flythroughs" Campaign to the Test Worlds game and a "Water Etc." scenario that loads the new world - so anyone can just look at the above environment / mess with graphics options to see how it runs, but there's nothing to do via Test Worlds as there is no associated scenarios other than the flythrough. I also did add the water line mentioned in my previous post. I did it via subgraph, just drop it into whichever shaders I want affected (currently just for the mesh terrain, rocks and what the rocks or similar objects use for distant LOD). This effectively applies a mirrored gradient centered on the given world-space y that darkens whatever the material is already and boosts smoothness (so the areas near water are 'shiny'/look wet).




The water line is tile-specific, so I can have different surfaces of water like a lake on a hilltop with another lake in the valley next to it or whatever.

That's all for this week!

 

I ended up spending the majority of my time since last week with the profiler, cleaning up whatever, hunting down every bug [of mine] that I could find (down to just 2-3 minor issues now, which should be quick enough to sort out.. especially since I tend to start with the most difficult or time consuming of things to do and just wrapped up the last major one today) and doing whatever possible to make content creation less time consuming. A few of the more significant updates were reorganization (somewhat) of asset-related systems so maintenance and finding things in the editor won't be a nightmare. Each world also now has a single 'rez texture' that's basically a procedural sprite sheet containing low-res stand-ins for high-res textures. Previously I had more of a 'shared sheets' approach for this, but that isn't particularly scaleable and I would have to load several sheets to make sure everything needed is available.. so less overhead now in some ways (a bit more in others) but the real benefit is minimal thought being needed to maintain and expand the number of environments, vs. whatever time would have been wasted otherwise (a lot).

I no longer pre-bake 3D foliage variants, they're now regenerated at runtime by their seed, so from storing 1 integer I get the same tree regenerated (via Broccoli Tree Creator systems). Note if you haven't been following along, "3D Foliage" is an option in the "Graphics 2" menu so if you want to so it, you'll have to enable it first unless your preference was stored while it was enabled before. Various other performance and other catch-up/improvements, for example replacing excessive null comparisons in loops with bools and adding invalidation for some things that could otherwise be triggered more than once a frame. Further narrows the framerate difference between flythrough mode and gameplay. Framerate now at defaults settings in flythrough is maxed out most of the time for my laptop's refresh rate (144fps) in the 'forest' and 'tropical'-ish environments and mostly 120+ in the city.

Added a 'fast travel' style buttons at the top left of the screen while the main menu is open. These are just shortcuts to the world indicated by their icon (whichever ones are in the current game). I don't know if I'll lock these based on progression or not. By the time of release there might also be secret ones not listed that can only be found by discovering a teleport. Also removed the "Flythroughs" campaign from "Test Worlds" as the new buttons effectively replace the purpose of it.


Fixed an LOD system issue [of mine] where it was merging mesh collider meshes into my distant LOD (some z-fighting with grey triangles tipped me off). Removed a performance-draining check in my structures that was running amok (was making sure no active rigidbodies were inside before allowing switch to distant LOD - now I'll set the flag on enter/exit of a structure instead so I've removed it entirely). Replaced a ton of renderer .IsVisible checks with logic based on tile structure. Added and mostly got day/night cycle up to a functional level in the city test environment, though exact things like sun rotation curves and shadow strength etc. aren't refined. Fixed an issue with structure lights there (i.e. windows on buildings that turn on/off). I haven't really set timing up for that kind of thing aside from seeing it's working (i.e. they turn off a bit earlier than streetlamps, and should be staggered more, and should come on faster when going from day->night when scrolling time ahead with the clock and so on / various improvements). Realized my shadows on 2D trees aren't always rotated correctly relative to the light anymore, obviously broke it somehow Fixed a structure lighting system issue which was causing stutter, optimized that and underlying structure systems - got the highest framerate that I've had yet on the city test today (and highest ever while coasting in flythrough there).

I've been mulling over having speedboat scenarios.. blowing stuff up along a shoreline while driving a boat just sounds.. fun. It also means ignoring scope, again, thanks to the additional systems I'd need to do for the water. Anyway yeah, that's one of my current indicisions. Water still needs a bit of polish.. in particular the 'shoreline blending' part, though I think it's a bit better now vs. last week. I'll definitely be adding ripples and surface effects before this title is done if I do the speedboat stuff.

So - nothing fun yet That's all for this week

Edit: To avoid any confusion over why some of my other images and videos display framerates higher than 144 - the above was about WebGL builds, Chrome browser, Windows 10, on a Ryzen 4800H (ASUS A15 laptop). WebGL builds' framerates seem to be capped at the monitor's refresh rate (in my case is 144hz Adaptive Sync). Most videos and screenshots I post (excluding browser or editor shots) are with maxed out graphics options in a Windows build captured via Fraps and encoded with FFMPEG.. and related to that, it's worth mentioning that the framerates in my videos are while capturing a 60fps video at the same time. I don't think I've mentioned how impressed I've been with Unity Engine.. but yeah, "well done" would be understating

 

A few updates and additions since last week, including..

Added swaying to groundcover system (bushes/grass etc.). This applies to all but the smallest type that fills in when 2D foliage option is set High. I could add it for that as well, but it looks fine to me with the lowest-to-ground stuff not moving while the taller things do, in addition to avoiding performance hits for things most people focused on gameplay won't notice anyway.

Added more capabilities to the Tutorials system. For any given instruction, the player can be teleported to a given position and heading when it opens. Also now able to auto-attach the player's current vehicle (if any) to any specified rail in the scene. This means a mix of instructions are possible where some can be completed anywhere (i.e. press space to jump), but others might requires you to start again at the top of a ramp or something, so it would teleport you back to the top each time you fail (just by that instruction opening again) and/or automatically attach you to the start of a given rail again.

Each Tutorial instruction can now also have a target object specified either in the world or in the UI for an arrow to point at, and/or optionally display a "!" on the compass with whatever color (currently purple). When the target is considered behind the camera it shows text of the same color saying "locate on compass" beneath the instruction. The origin of the arrow on the instruction is a property, so I can have one saying "by clicking this" and the arrow goes from just to the right of the word "this" to the object in question. Here's an in-game example of the arrow, although the shading of it and the actual instruction image will be different later (maybe also which world tutorials are in.., as the one shown isn't particularly well-suited since I made it too much like a highway run):



I've done a rough layout of a new world, Arctic Env 1 (current/wip name). I posted this shot on a new page of my site a few days ago (which I'm not really maintaining yet), so to quote, "Here's a shot of the test vehicle on a cliff while checking the scale of it against the terrain. Nothing but a rough coat of texturing so far (slightly different later.. this is just for the general idea).":



After thinking over what I want to do with the above world, I've decided it would be tedious using my current tools for doing tunnels and too restrictive artistically, so.. I've also decided to invest the next week (or so) on yet another system so my terrain can have nicer tunnels, overhangs and make it easier in general to add/create caves or other underground structures. I have already tested enough code to rule out any showstoppers, it's definitely doable in a reasonable amount of time thanks to having CSG for heavy lifting, vs. cutting holes by hand for each one, making the intersections palatable and other manual labor. There is an edge case complication I haven't thought through entirely, where multiple tiles of my terrain are affected by the same tunnel opening, but I'm sure it can be overcome by a temporary merging or just by making sure I don't do that. I'll also have to write custom solutions for matching/smoothing normals where cave geometry and terrain share vertices or edges, some relevant uv tools so I can texture map the interiors of tunnels more easily in the way I want, and integrating all this with my existing LOD systems. It's pretty straightforward and more time-consuming than daunting, but it is definitely going to be a chore. Related to my LOD systems, the most difficult part of the integration will be that I'll have to split underground cave systems or tunnels automatically based on specs of the tileset they're a part of and keep everything non-destructive (i.e. easily be able to regenerate or remove a tunnel / be able to auto-restore terrain to how it was before the tunnel was added etc.). I think this will lead to some of the most significant improvements in gameplay since my first post.. tunnels or even above-ground embankments where you can drive onto the wall/side to navigate around sharp turns and so on.

As it stands without doing the above, I'm mostly limited to rectangular tunnels (where doing one quick with my existing tools is concerned), which is mostly fine for cities but definitely not for more organic environments or variety. They can already follow whatever curve, but tunnels like the one in my city aren't enough for what I have in mind. Currently, this is about as good as it gets for my tunnels:


I've decided to have several scenarios for each environment be focused purely on driving ability (just like the checkpoint scenarios, but without enemies and with a fixed time bonus at each checkpoint vs. dynamic based on other factors). This is probably the type I'll be starting with after tutorials are done-ish, as it means I can make easily make progress from that perspective at the same time as I'm getting the environments together. Populating worlds will be the most time consuming thing I'll be doing (each having unique or semi-unique guardrails and fences, streetlamps, buildings, rock formations, etc.).

I've settled on the following environments, based on my self-imposed time limit for this project and what else still needs to be done:
- "rural" (like current test world, lakes, rivers, bridges, rolling hills, grassy plains)
- "city" (like previous test world but mostly streets and sidewalks, more of an "endless city" feel with smaller park-like areas than now)
- "suburban" (sidewalks, driveways, houses, picket fences, gardens)
- "arctic" (lots of tunnels, caves, ramps/jumps)
- "tropical" (roads along the sides of foliage-covered hills overlooking water, through regions of jungle, etc.)
- "desert" (highway runs and tunnels)

For most (maybe all) environments I'll do 2-3 variations. So in total there'll be at least 12. If I have 5 scenarios per map, that's 60 scenarios total. Scenarios will be a mix of normal routes to drive, obstacle course concepts like tree-dodging runs where you try to get through a forest fast enough, plus the current checkpoint type with enemies (something akin to a "tower offence" genre if there is such a thing ..vs. tower defense).. trying to reach the finish without being destroyed or running out of time while shooting turrets and whatever other enemies. The possibility of adding anything beyond those types depends on how much time I've got left to play with once whatever I've considered essential is done.

Also decided - other vehicle types like the speedboat idea in my previous post (or aircraft.. which I have tested previously with one based on the Standard Assets jet) are not going on my todo list until [at least] all environments are roughed in with playable scenarios, if at all for this. It would obviously be "nice to have", and several distinct vehicle types would definitely fit the game well, but having a finished game together by the time I want it to be would be nicer.

I'll be adding a Field of View slider to my graphics options (which still need to be sorted into better categories given recent laziness about that). Maybe allowing between 50 and 80.. not sure what the exact clamp will be until I've tested a bit more.

Also cleaned up a number of issues, new and old..

Spoiler

- Fixed waterline being too high for a moment when first loading the world / appearing as a flat plane until normals texture was loaded.
- Fixed a new issue where direct collision of the vehicle with 2D trees was not removing them (caused by changes related to optimization).
- Fixed an occasional issue with the world downloader progress bar being much larger than intended.
- Fixed the position offset of the "time remaining" text under the combo at the top that's used in some scenario types. I broke it a week or two back when updating older stuff to work properly in Portrait orientation. Despite this particular title requiring a mouse and keyboard (i.e. no actual "orientation" as it exists for tablets/phones), I do allow browser or window resize. I test for usability at aspects between 2:1 and 1:2.
- Fixed issue where streetlamp poles were affected too much by my lighting system at LOD 0. Fixed material of hydro poles not receiving light. There are a couple of other materials I still need to update (for example the lighting from streetlamps on the houses' geometry appears to switch off as you get closer) but it's not a concern at the moment.
- Fixed textures on the hydro poles and rocks after recent changes to my rezzing system broke them (symptoms of the issue were materials being black or having zeroed texture scale), it was broken for a while before I noticed.
- Fixed teleporting while attached to a rail would fly the vehicle back to the rail after teleport (vehicle now detaches from the rail first - discovered while testing tutorial systems).
- Fixed a performance regression in city test env that was in the live build for a couple of days, where half-way through it would stutter a bit and for a second or two the framerate would be half what it normally is. Was caused by invalidation of structure LOD updates which weren't processed while out of sight after optimization-related changes, so when a bunch would come into view they'd regenerate all at once instead of the hit being distributed over multiple frames.
- Changed Read/Write flag to false for a large swath of textures that didn't need it. I should automate that switch as part of the build process since it's mostly just for editor scripts.. also not a priority, but if you don't need read/write then you don't want that enabled (overhead), so memory consumption should also be less now than it was a week ago.

That's more than enough rambling for this week, good luck to everyone with their projects

 

In order to achieve the results shown, I extended my framework with a new system that makes use of pb_CSG (for intersection) and geometry3Sharp (for some parts of my retopology).



I also briefly tested intersection with meshes modified by Mesh Deformer as I'll be using that to bulge areas of a tunnel and curve them by spline. I still have a few things to do related to this system over the next week. I'll be adding displacement options so I can easily make interiors have rough shaped walls/outcroppings etc., a checkbox for whether to smooth normals at the intersections, a checkbox whether caps are destructible (plus properties related to that).. along with some other random stuff necessary where integration with optimization systems are concerned (so widespread use of this will have less impact).



The default material (as shown) for a new "tunnel" is basically my terrain shader using vertex color for blending instead of splat texture. By tunnel vertex position relative to the tile, I assign the corresponding splat pixel color to the vertex color.. and that - plus copying properties from the material of the tile surface to the tunnel material - gets me a roughed-in assignment of textures and other properties that results in mostly matching the terrain at intersections. From there I can customize it however with vertex painting or doing a custom splat for the interior, change which textures being blended etc. That's all for now