Biome Defense: An RTS fought between the animals of earth's biomes

Awesome, I'm really looking forward to seeing you do this, because I've not been able to find anyone who's done a fully fledged lockstep simulation in Unity before.

 

Updates:
* Reduced the path-find-time to ~20% of prior by switching to Jump Point Search as the path-finder algorithm.
* Reduced the path-find-time even further (to ~20% of prior) by upgrading/extending the Jump Point Search system to Jump Point Search+. (which basically adds a cache of jump-point nodes reachable (by a straight or diagonal line) from each node)
* Added a Console>Log>Sections tab, showing the totals of time taken in various segments of code. (it's essentially a custom-made profiling system, except you have to enter all the instrumentation code yourself! (which is why I only use it for important tests over time (which can't be done with the Unity profiler, as it displays its data per-frame)))
- - - - - - - - - -
* Got the JPS+ cache node>update-has-obstacle system working! Updating the JPS+ cache data after a map change (e.g. building placement) is now fast/trivial.
* Split the path-finder into two versions (cached, and dynamic). Cached ignores units (so runs really fast with JPS+ caching), while dynamic considers/avoids them. Dynamic is only called if a unit sees that it's about to collide with a unit.
* Unit-evasion paths are now limited to have path-nodes that are within 10 meters (5 nodes) of the main/ignoring-units path. (Matches the desired behavior more often, as well as fixes lag when attempting to path-find to a node that's blocked.)
* Fixed that placing multiple objects at the same time (e.g. walls) would cause an error, if in a match.
* Fixed that changing the selected map on the Matches page would cause the Players list to disappear.

 

New screenshots
==========

Visualization of the Jump Point Search+ cache data. (black: obstacle/impassable, white: open/passable, red: open/passable and also a primary jump point--green: straight jump point in given direction, blue: diagonal jump point in given direction)

 

Updates:
* Added plant: Fern_3
* Fixed that deleting a region with children plants would leave the plants with an invalid owner-region. (and therefore cause an error on saving)
* Fixed that the Minimap preview image would, in certain cases, be re-generated every frame. (again)
* Added object property: canOverlapPlants (lets you mark an object/plant as being able to overlap other plants; used for thickets/brush in forests to fill in gaps)
* Added play/pause button to the Live page.

 

New screenshots
==========

Bear near the entrance of a path that passes through a forest with ridiculously large ferns. (I'll bring them down in size some once there are other thickets/brush/undergrowth plant types available to mix in with them)

On the far right, you can see one of the ferns intersecting with a tree. That's the first of a group of thickets/brush/undergrowth that will be added to help fill in the gaps between trees. This is the solution I decided on, for having the forests regain their strategic significance (impassibility, while still being choppable), while not requiring major changes to the large and lofty (and semi-realistic) trees.

(The trees are important for increasing biome diversity (e.g. difference in size between different biomes' plant life), as well as overall realism (e.g. sense of scale between environment and creatures).)

 

Updates:
* Added new plants: PineBush_29, Bush_31, BerryBush_36
* Object preview images are now generated with more consistent margins. (zoom distance is based on distance of vertexes (rather than bound-corners) to edge-of-view)
* Improved quality of object preview images by having them be rendered at 2X resolution, then downscaled.
* Object preview images are now generated with a light and a platform, increasing clarity.
* Added a "Refresh preview image" button to the Objects>General panel.
* Fixed that the icons for selected objects did not darken when the mouse hovered over them.

 

New screenshots
==========

The three new bush types, as part of a small forest.


The better quality preview images for objects.

 

Updates:
* Added new structure: Tower
* Added new other: Arrow (projectile)
* Added projectile system. (used by Tower structure for shooting arrows)
* Added object properties: canFireProjectile (component), isProjectile (component)
* Added new VModel>Material property: isUnlit
* Fixed that attempting to build a structure, after defeating the enemy, would make it impossible to select anything. (build attempt is now cancelled on game finish, which re-enables object selection)
* Fixed that the "preview animation" setting in the Objects>General panel would not loop the animation.
* Fixed that the Maps>Regions panel could overflow the UI height. (scrollbars are now shown for that case)
* Fixed that the quad-tree system was not creating subnodes properly. (the subnode bounds were incorrect)
* Fixed that the QuadTree>Update method would sometimes fail to remove an item from its prior area, when its area changed.

 

New screenshots
==========

New Tower structure shooting an Arrow projectile at an enemy Zebra unit.

 

This is a very neat project! Do you have a facebook, youtube or any website with easier means to follow progress?

 

Nope, sorry. I considered it, but decided to wait until the project is further along before I start setting up a web presence around it.

By the way, I was up all night playing this Indie game: http://rimworldgame.com

Good thing I don't have a day job, as I wouldn't have been able to sleep from 10 to 5 today. (I'm a night-owl/shifting-schedule person, so it's not too bad, though)

 

Well that was a rather long break in updates!

Two main reasons:
* Various family events that took considerable time to settle.
* A fairly large 'cascade' of changes that were in the works. In other words, the game's been in a semi-broken state until a few days ago; I try to not dig myself into these 'major update' holes (i.e. I try to follow the principles of 'agile development'), but sometimes it ends up happening.

Keep moving forward!

Updates:
* Added a deeply functional visual scripting system. (Pretty major. Works well, and will at some point be the engine by which AIs are developed, using a nice in-game UI.)
* The map of a live match can be opened in the Maps page. (to view script info)
* New region Component system exists.
* New region components exist: Apply Pattern, Apply Soils, Generate Plants, Set Biome at Start
* New maps exist: Island_Auto (set up to use new soil and plant generation systems)
* The default map's soils are set, for each l2-cell, based on its biome-at-start's soil-distribution. (by use of the Apply Soils component)
* A player's (default) biome can be set in the Maps>Players panel.
* TerrainCell data gets saved to file. (meaning e.g. soils and biome-at-start data is saved)
* Terrain shader can use up to 11 textures at once, in each chunk! (used to be 4)
* Each soil has an is-deep property, which causes it to be rendered with a deeper bumpmap texture.
* Many more plants can exist in a map without breaking the transfer-data-to-ui pipeline. (more inferrable/shared-with-type properties are cut out during serialization-for-ui)
* Plants have per-biome number-per-square-kilometer values set. (in their VDF data files)
* Soils have per-biome coverage values set. (in their VDF data files)
* Added awesome LOD system. (for now it's only used for the manually-added/assets-from-the-start plants)
* Improved the UI speed enough (from VDF loading optimization, context-menu lazy-loading, etc.) that the UI consistently loads before the UI timeout. (yay!...)
* Fixed that Unity would crash on game launch. (by fixing lambda arg-ref issue, and typeof(Type)-to-typeof(MonoType) issue)
* Fixed that the Maps>Viewer>Tools panel would be non-visible for a split-second on switching to its page/subpage.
* Fixed that the VDF exception-catchers would cause some of the stack-trace to be lost. (that between the original-exception's and external-exception's stack-traces)
* Updated the asset pack containing the ground-plants currently available (e.g. Fern, Bush), and purchased a better plant shader for them. (so, they look and are animated better now)
* Middle-mouse scrolling now has its own cursor set. (as in browser)
* Added to-log-file logging system. (for, e.g. messages that would freeze Unity if all logged the normal way)
* The camera's viewport positioning does not get messed up after using middle-mouse-based panning.
* Trying to delete a non-[structure-or-unit] object does not cause an error.
* A match does not start running (i.e. have its data-frame progress) before it finishes loading/initializing.
* Very long (>15000 length) messages truncate just the call-args-vdf section, rather than the message as a whole. (so the important stack-and-such info is visible in the Unity console)
* The run-count of a call is shown in the Maps>Scripts>Call panel if it's part of the live match.
* A dynamic/in-live-match change to a label's passive-value is not synced with JS side. (solution, for now, to there being too many CS<>JS calls on map launch)
* MeshData-based raycasting works better, by having it ignore false-hits as indicated by z == 0. (meaning, e.g. objects aren't placed under the terrain)
* New class 'Change_SetItem_List' exists. (and made-so Change_Add_List only performs Inserts and Adds)
* The Console>Log setting names/positions make more sense.
* Tab bars on Settings, Console, and Matches page finally don't have that annoying gap at left and right.
* Regions can be reordered. (there are "Move Left" and "Move Right" buttons)
* A region's label is updated after the region is renamed.
* A region's opacity-map image is saved to file after rename.
* Ocean is a bit darker and less-saturated. (trying to approximate realistic look)
* Objects whose models are to be loaded from the built-in assets, now have "Main.vdf" files in their "CacheL3" folders.
* Block 'position' prop is not saved to file. (it's now just inferred from list index)
* Plants are no longer generated over water.

 

New screenshots
==========

New visual scripting system.


New region component system.


Match being played on the map procedurally generated using the component system shown above.


Zoomed in view of the smoother transitioning now possible on terrains. (the max-textures-per-chunk limit has been raised from 4 to 11, meaning you can transition soils into each other pretty much as slowly/gradually as you like)


A map procedurally-generated at match launch time. Important feature shown here is that the map is generated based on the "owner" biome for each region. In the screenshot above, the left side has snow and pine trees (matching the "Boreal Forest/Tundra/Polar" biome of player 1), while the right side has dark grass and deciduous trees (the closest match currently for the "Old World Rainforest" biome of player 2).

 

Updates:
* Live page has a new, merged "action panel" that replaces the old ones, instead categorizing all actions by content (having rows for: selection, actions, structures, units, technologies).
* New unit actions exist: Draft (see below), Undraft (see below), Stop (stops any movement, attack, etc. task currently being performed)
* New unit component exists: CanBeDrafted (essentially means units now have two 'modes'; economic/normal mode, where they work faster but are more vulnerable, and then military/drafted mode, where they fight better but don't work as fast)
* Unit types have the new CanBeDrafted component attached, with values set.
* Technology system is functional!
* New technology exists: Town Watch (increases the view-distance of all non-[wall/gate] structures by +10 meters, so resources and enemies can be seen earlier)
* Components can be enabled/disabled. (there's a checkbox for each one now)
* New VObject prop exists: isWall
* Maps>Regions panel's move-right button icon is the same size as the move-left button icon.
* Some non-useful/cluttering startup logs are no longer shown on the Console>Logs panel.
* JS-side Node system can infer the type of a list item, from the type of the list itself--as the C# version has already been doing.
* New Change_Add_Dictionary prop exists: overwrite (allows change to overwrite an existing key-value pair with the new data)
* Change_Add_Dictionary serializes its 'key' prop by reference, if it's a Node.
* Change_Increase_Int and Change_Increase_Float classes are merged.

 

New screenshots
==========

Shows the new, merged "action panel" at the bottom (containing the new actions and tech). This is my attempt at making the UI quicker to use, as there are no tabs or subpages to open at any time. (for these main functions, anyway)

It also opens up new uses for the main-view buttons, e.g. alt-clicking on any structure/unit type to jump to the next instance of it, hovering to see instances of it flash on the minimap, browsing your biome's whole structure/unit/tech collection on the main in-game view (and hovering to see what the requirements are), etc. This wouldn't be possible/useful if they were separated out into their own tabs/subpanels (as is traditional in RTS games).

Also shows the gray coloring underneath the selected units to show they are "drafted". (essentially means each unit has two sets of stats--one in economic mode, and another in military mode, with a delay time to have your units switch between them)

 

Hi Venryx,

To support custom units, will you be writing a runtime fbx importer that supports importing animations? And if so, would you be selling it on the asset store? Its something I'd be quite interested in buying.

 

Actually, support for custom units is already present. Models are loaded on game launch from the ".vmodel" files in the Units folder--a custom, json-based format, with an exporter made for Blender.

As for selling it, I'll look into it, but will probably just release it for free, as it doesn't seem like there's enough demand for that sort of custom-format system. (despite it working fine with, e.g. animations, and using simple code that's easy to modify, most people apparently wouldn't pay anything for it: http://forum.unity3d.com/threads/bl...th-animation-support-usable-at-runtime.300998)

I can send it to you if you want, although it's not exactly "modulized" yet since I've only needed it in this one project so far (i.e. there might be extra code that's specific to my project).

I suspect the main issue people have with it is that it doesn't use an industry-standard format. Personally that's not an issue for me, since the format's really easy to understand and manually-edit/potentially-reverse-engineer, and the importer/exporter is easy to mantain, but I can see how without knowledge of this it would feel scary to seemingly "jump onboard" an unknown format.

 

Updates:
* New technologies exist: Grazer Age, Hunter Age, Avian Age, Machine Age
* A unit or tech is now set as starting in one of five ages: rodent age, grazer age, hunter age, avian age, machine age
* Structures [Small Shelter, Large Shelter, Nest, Burrow] are replaced with [Rodent Lodge, Grazer Lodge, Hunter Lodge, Avian Lodge]. (with buildable-units appropriately updated)
* Outpost is renamed Habitat Center.
* Main categories of crops, economic buildings, and military buildings, have labels shown for their sections on the Live>Action panel.
* A unit or tech is categorized by structure-that-[builds/researches]-it, on the Live>Action panel.
* New VObject prop exists: age (the age at which the object is able to be built/produced)
* New Player prop exists: age (the age the player is currently at)
* New technology prop exists: sortingName (used to force a tech into a desired position in the UI, e.g. keep advance-to-new-age techs next to each other)
* A technology's cost is successfully removed when research is started.
* Newly imported models don't have the odd material fuzziness to them.

 

New screenshots
==========

Shows the four new advance-to-next-age 'techs' in the Actions panel, as well as the new categorization system.

 

Updates:
* Biomes page is updated to show game content in rows, one for each age. (tech still isn't shown yet, though)
* Main font style is changed to 'small caps'.
* Technology conditions/requirements system is functional. (e.g. Grazer Age is a prerequisite tech for Hunter Age)

 

New screenshots
==========

New Biomes (i.e. tech tree) layout, with each item categorized into the age it becomes available. (there's... not much available atm; also, tech still isn't shown here yet)

Also shows the new font style.

 

Updates:
* Grazer Lodge model replaced with a better one.
* Human reference model is available in project "@Toolbox" folder.

 

New screenshots
==========

The new Grazer Lodge model. (hey, it's better than the previous one!)

As a side note... it's a little interesting trying to make buildings in this game, since... normally animals don't inhabit buildings. It seems to be more acceptable if, at least, the buildings are open-air structures like that above--I've tried a few closed ones, and it just looks really odd.

I think it could look better in the future if more 'outdoorsy' decorations were added to the structures (e.g. small trees, vines, moss), to make them look more 'natural'. For now, that's out of the scope of my work though, as time is limited, and coding the gameplay/mechanics is more important right now.

 

Updates:
* New structure exists: Machine Workshop
* VModel files no longer require UVs for objects with materials.

 

New screenshots
==========

New Machine Workshop structure. (btw, the roof's not supposed to be that shiny--it's washing out the wood texture; I haven't messed around with the Unity 5 shader settings yet)

 

It's not FBX, but if you'd like to take a look at the exporter package for the VModel format I'm using, I finally took the time to upload it to GitHub: https://github.com/Venryx/VModel

Alongside the above package, I also heavily use a Blender tool package that I put together here, to help speed up various operations/processes: https://github.com/Venryx/VTools

Not sure how much you make use of Blender, but thought I'd mention it, as it's quite useful for me. (one of the more helpful bits is that it shows how to have your own variables and functions added to the Python Console automatically, which makes the console a lot more useful for quick and common actions)

 

Thanks Venryx, it looks like the VModel format would be able to do everything I'd need. I probably won't need it for a while yet, but I'll be keeping an eye on this, because I'd like to be able to add modding support to my next game.

I do use Blender for all my modeling and animation, although I haven't used any scripting in blender (I don't know python). With your tools, would you be able to retarget an animation from one armature to another? For example, copying a quadruped running animation from one animal to another?

 

That is the idea behind the "Retarget action" operator, yes; I successfully used it to retarget some actions/animations for the creatures, since, strangely, the author used separate FBX files for each of the animations, with a few having different armature rest-poses/setups! What a headache it was. This solved the problem, though I haven't used it in a while, so don't remember the details of how it works/whether it had any limitations.

Side note, but: I'm a huge fan of good scripting systems in 3D modelers. If it's integrated well, it opens up a lot of options for getting past what would otherwise be major annoyances with the software. Once you make a script to solve a problem like this, you can potentially save countless hours down the road, since 3D modeling often calls for lots of tedious adjustments post-creation.

The real artists can probably get by by just recreating stuff that wasn't made right, but for someone without that speed/talent, who instead has a background in programming, they can help themselves along by amassing a scripting toolset that they customize for their interaction style. (e.g. I'm a big fan of using operators + shortcut functions added to the Python Console for more interactive modifications)

It makes 3D modeling more fun, giving the feeling of control and familiarity to the programmer-at-heart.

 

Updates:
* New unit exists: Battering Ram
* New VObject props exist (with types updated): defenseTypes, attackTypes (defense and attack stats are now stored in child-objects of these maps, providing better encapsulation and allowing custom defense/attack types to be created)
* New CanBeDrafted prop exists: alwaysDrafted (used if a unit has no economic use, e.g. a Battering Ram)
* New cheat code exists: age(age) (instantly advances you to the specified age)
* Units can be produced at their intended structures again. (had bug where units could only be produced at a Habitat Center)
* Unit production buttons can show up in more than one category/group. (as is true in the data files)
* A unit destroyed earlier in the current frame update no longer has its Update method called.

 

New screenshots
==========

New Battering Ram unit moving forward to attack an enemy Mill.

 

Updates:
* CanBeDrafted>alwaysDrafted property works as intended. (i.e. unit starts out drafted, and can't be undrafted)
* New AttackType prop exists: radius (causes area-of-effect damage) [added to Battering Ram]
* Console>RunCS tool works again, and shows syntax errors now. (updated the Mono.CSharp dll)

 

New screenshots
==========

New area-of-effect damage occurring as Battering Ram attacks a row of Palisade Walls.

 

Updates:
* New structure exists: Blacksmith
* New object models are added to the in-editor scene, after import. (removes a short step for each time an object is added)
* Fixed that VObject children that were by-reference, were nonetheless attached (a second time) to the main-tree through their ancestor VObject. (fixes that error would sometimes occur on object destruction)

 

New screenshots
==========

New Blacksmith structure.

No techs for it yet, though; that will come later, when I've worked out what theme to use for the naming of the armor-and-such technologies. (Is it odd to name the techs with "armor" when the units don't appear to wear any armor? Should I have the units start wearing actual armor models--is that worth the development/modeling time?)

 

Updates:
* New structure exists: Fortress
* Added suo files back to the ignore list. (even if they have some useful data, not worth the ~1mb added each commit)
* Cube test object is removed.

 

New screenshots
==========

New Fortress structure.

 

Updates:
* New structure exists: Market

 

New screenshots
==========

New Market structure. (trading isn't implemented yet, though)

 

Updates:
* New structure exists: Stone Wall
* A wall object no longer uses its diagonal submodel for straight walls.
* A wall object no longer uses its corner submodel for: a wall next to a true-corner wall (i.e. a wall on the intersection cell of two straight-line walls)

 

New screenshots
==========

Set of new Stone Wall structures, enclosing an enemy town. (ok... blacksmith and market)

 

Updates:
* New structure exists: Stone Gate
* Gates count as walls, in the submodel-choosing section of code. (meaning the walls right next to a gate use the normal submodel, rather than the tower/corner one)

 

New screenshots
==========

New Stone Gate structure, being attacked by a Bear.

 

Updates:
* New VComponent 'HasEnergy' exists, with these props: energy (refills over time; to be used for sprinting and special abilities; represented by white bar at left of info overlay), energyCapacity, rush_energyCost, rush_speedMultiplier
* Units can sprint/rush by double-right-clicking a target or target-location. (consumes energy)
* New owner+health+energy circle overlay is used for displaying structure/unit core-stats. (instead of old ring+health-bar system)
* Settings of type 'showHealthBarForX' replaced by settings of type 'showInfoCircleForX'.
* New settings exist: doubleClickMaxTime, standardViewDistance, infoCircle_scale, infoCircle_minRadius, infoCircle_baseRadius, infoCircle_maxRadius, infoCircle_minOpacity, infoCircle_maxOpacity
* Below-unit ring is now always white, and only shown for selected units.
* A v-object-instance>component>prop-value is no longer serialized if it matches the v-object-type>component>prop-value.

 

New screenshots
==========

Shows a unit using the new 'sprint' feature, which uses up the new 'energy' property. (1 energy is regenerated each second, but how much energy capacity each unit has, how quickly energy is used while sprinting, and how fast the sprinting is, depends on the creature)

I'm hoping this will lead to more diversity between units, as well as opening up new strategies and risks. (do I use my units' energy to sprint to the enemy base for a surprise attack, or will that leave me too vulnerable against his fully-energized defense?)

Eventually, energy may also be used for special abilities for structures and units. (e.g. a ranged attack for an otherwise melee unit--though causing a slight pause, and using up half the unit's energy capacity)
----------
The above image also shows the new 'info circle' overlay for displaying core-unit-stats. (energy on the left, health on the right (in the color of the owner))

 

Updates:
* Basic profiler system added to/as a new Console>Profiler>[Call Paths] panel. (shows run-time of the different call-paths)
* Console>Log>Sections panel moved to/as Console>Profiler>Sections.
* VObject>HasEnergy>energy property no longer has updates sent to ui. (ui doesn't use it; restores fps in-match to its pre-info-circle-overlays level)
* Log_Calls.txt added to the git ignore-list. (it can get really huge sometimes, and is not very useful outside of the current launch/session)

 

New screenshots
==========

New, basic profiler panel. (will expand its depth/informativeness as needed)

 

Updates:
* Dynamic path-finder no longer allows pathing 'through the corner' of an impassable, making it consistent with the cached path-finder, and improving units' abilities to find paths that successfully avoid each other.
* Changing the VObject>overrideBounds prop through the UI successfully updates the bounds visualization.
* Mill's bounds no longer includes the blades!

 

Updates:
* A unit much-less-frequently gets stuck if it walks into another unit.
* Profiler>Sections system includes the run-count for each entry.
* New Console>Flags panel exists, for quick enabling/disabling of different code-paths. (for testing)
* New setting exists: showTerrainPositionsOverlay (displays info about the terrain-point being hovered over, e.g. which terrain-cell contains it)
* If object is produced from building, and no open position is found for placement, object is placed at an occupied position. (rather than freezing the game)
* VDebug.Log messages are queued during each frame, and then actually-logged (to the console) at the start of the next frame. (fixes that logging would mess up profiling/code-run-time-measurements; also seems to reduce the overall time spent logging, perhaps because there's some overhead to non-consecutive logs)
* A double-click is no longer triggered if the two constituent single-clicks are at different positions.
* Cloning a map with a script works again.

 

Updates:
* Path-finder path-find-time reduced to ~80% of prior, by replacing the min-heap open-list with an unsorted priority queue, and adding a fast-stack collection.
* Dynamic-path-finder's path-find-time further reduced to ~20% of prior, by having it check for structure collisions using the path-finder-cache, rather than looping through nearby structures and checking each manually.
* Path-finder no longer considers a diagonal movement to have the same cost as a straight movement. (simplified description for a hard-to-track bug which yielded slower path-finding and non-optimal results/paths)
* Objects no longer sometimes leave behind their info-circles, after being destroyed.
* Change_Increase_Number class no longer sometimes sends the increase amount as a string! (meaning the UI side successfully applies the value change, rather than concatenating the increase-amount-string)
* Right-mouse-drag rotation on the Live page is removed. (right mouse dragging will be used for other things later)

 

Looks like its coming along nicely, keep up the good work!