GIGAYA

Doesn't this method have a drawback of stuttering and freezing because loading and unloading assets runtime isn't that fast??? Are the further away chunks rendered using lower quality representation like an an impostor and joined together in a single mesh to reduce the draw calls?? Also I want to say that the shadows in the video aren't that great they look blocky and low resolution and the grass does not cast shadows.. is it possible to make the grass to cast shadows using screen space shadows(just like how contact shadows work)?
Is there any big performance boost because of SRP batcher??



Sorry for the wall of questions.... Thanks for the transparency u provide about the project!!

 

- Level stuttering; depends on how you load it! Most games mask this up through a variety of methods.
- Yes, we are already using SRP Batcher. And there is a boost by using it.
- Shadows we can improve. Will let the team know. Do you have a timestamp? Is it on the robot?
- Grass can cast shadows but user-disabled due to performance.

 

@Andy-Touch
I'm curious, what's your internal approach to deadlines, timeframes, and production expectation?

Like, if a guy on your team goes and says, "hey, I want to spend 2 weeks making a editor tool", how do you guys handle this?

If you want to build a system off of an existing unity system, what kind of expectation is there in terms of how long it should take?

Dogfooding is a great step forward, but I think that if you really want to understand the user end - having some sense of time pressure and the like can go a long way toward actually understanding where your users are coming from in a lot of cases.

For a lot of things, especially things that I find frustrating, it's often that the process is just needlessly time consuming. Many of these frustrations would evaporate if I was willing to spend a few weeks on custom tooling or extension. Your time/resource and staffing expectations are can dramatically change your impression of a feature set.

If you want to kick out a feature in a few days, your expectations are dramatically different than if you expect the same feature to take two months.

How are you guys approaching this kind of thing?

 

Im neither Producer or Project Lead but can speak briefly to our framework.

So currently we are working in roughly 3 to 4 month phases. At the deadline of each phase we review the status, what has worked, what hasn't worked, what tech we need, what resources we need, what systems we need to improve/overhaul etc.

Phase 1 - Was a playable prototype with some ideas of the vision and future of the game. Alot of this was scoping out what tools and tech we are using and establishing some collaborative workflows (majority of the team had never worked together or even met each other in-person before!)

Phase 2 - Was fleshing out that prototype with more functionality, more interactivity, more systems etc. We did a lot of internal playtesting around this point to get internal feedback, perspectives, suggestions, etc.

Phase 3 - This was refining, polishing and optimising those systems into a vertical slice that would be representative of a level of the game. The result of third deadline is what was shown at GDC.

Phase 4 - This was a little longer; processing a ton of feedback from GDC and focusing on us reworking some core systems and foundations and optimizing a variety of areas.

Phase 5 (Current) - More optimizations, polish, missing systems/features and preparing the project for first release.

Bare in mind the team started with about 7 people and has increased in size over these phases. We have also had some people leave the project and then we need to hire need folks for those positions. And as said earlier; most of the team have never worked together before; so lots of collaborative learnings! We also started with a complete blank-slate in terms of code-base and asset content.


Amongst these phases we are in continuous feedback sessions with many core teams at Unity; what feature is working well, what feature is working not well, giving plenty of very direct feedback and also getting alot of direct feedback back! This actually takes up a large amount of our time. If we were an external studio we would likely have worked to shorter deadlines due to not having this other important task to do!

In terms of building custom tools; we are building tools only with public APIs (absolutely zero source changes or package modifications) with 2021 LTS. Everything we are doing can be done exactly the same as the community with the Unity you can download right now today through Hub etc.

We are also only building tools that we need for the game. One thing we aren't aiming to do on Gigaya is answer the age-old questions of 'how do you make a door in a videogame?' or make super general purpose systems that work with every scenario. IE: The character controller is not a general purpose one but one built for Gigaya; but it uses fairly typical solutions and code for it's functionality. Having worked on a variety of general purpose tools in the past; its a bottomless pit of expansion; most of which isn't needed if you know the scope you are building to.

However, we aim to build these tools in a dissectible way that can highlight workflows, demonstrate and educate one way of how to build systems for common scenarios of this genre. IE: So whilst the CC is not general purpose for every scenario; it has the core fundamentals of things a Ratchet-And-Clank-style platformer CC needs like ground check, slope check, gravity, standing on a moving platform, knockback, melee, aim mode, etc. Of course; if the community wants to rip out features/systems they are more than welcome to; we fully expect that! And upon release I think there are some worthy candidate features we could perhaps extract and generalise a bit more; but will have to evaluate the areas community gravitates more to when we see feedback and usage.

In terms of timelines for tools/systems; it really depends on the importance and need. I think every system in Gigaya has undergone a 'make V1 super quick, and then iterate/improve through usage and requirements. Rewrite when you hit a big requirement or performance wall' process. For example; the CC has undergone many iterations and I have probably rewritten entirely 4 times.

Also, we aim for all code and systems to be readable externally; threrefore aim for a tidy project and code-base; that also eats a ton of time. We can't hide methods of 'DoThing(); or //If this code is removed then the game breaks'.

I hope that answers some of your questions?

 

sorry for my noob question but, +3 months is not that too long time for prototypes? or am i misunderstanding something?

 

What is your definition of a prototype though? Single developers make prototypes or even more than that for game jams like Ludum Dare that last for only 48 hours.

 

Check out what people can do in a few days in game jams.

3 months with a team is a good duration although probably not AAA levels. Sometimes less time keeps things on track and the prototype will not get lost in feature bloat.

 

i edited the question i think i wrote it wrong

 

Hi there! Just a 2 cents. TL DR: Look great, if only it could be something done by less people. Maybe..

From the Gigaya blog;

''The community has been asking Unity to make our own games as a way to validate product workflows, and the Gigaya development team is doing just that. The team consists of 15 creators spanning an array of talents, including programmers, artists, designers, and producers.
Situated alongside Unity core engineering groups, the Gigaya team is not bound to any specific product or feature. This unique structure gives us perspective into the challenges that indie and mid-sized studios face while trying to ship successful games.''

Gigaya does look made by a larger team...which is great and we will be able to see/breakdown the work (of all);
I'm just wondering how much this game will be 'feasible' for a Solo Dev or 2-3 team people;
not 15+ creators..worldwide team.

Unity (you) needs to understand that the Large Brunt of devs are not Teams, but under 5 people; many are just solo.
So this where I am like; wow...can any solo dev or 2 people make Gigaya? I'm not so sure...

Unity you should have (just my POV) done also a 'Smaller Team/MicroTeam...'..like Real Smalle (1 peerson small).

Micro-Game or small(er) game; this is not a micro-game; and many solo-devs Wish to Make Gigaya or close to...As Solo. or let's say small team or 3-4 people..and some want to Not game a Micro-game but Bigger game - like that Gigaya; but with less resources/people..etc.

You may say : 'Impossible it took us 15+ people over a year or 2....and lots of resources'
But that'S where you have to Leverage...like the Asset Store...outsourcing or finding ways to make a Bigger game (like this one) a possibility..instead of forcing solo or 2-3 team devs to say : 'Ok this game is unfeasable for us (it took them 5 times more people (and resources cause people not working free even if working online from all over the world))'.

Maybe a Gigaya Lite'/Micro-Gigaya (like your FPS Micro game)....would have been a good thing and showed that one or 2-3 people of your choosing would make a the Lite version. This would have showed that solo devs can make this.

Anyway, it looks incredible and every tool/knowledge poured in it..will help for any solo..wishing so..to try...theirself...
but, of course, it ..still took 15 more people..

Thanks for reading.
Just a 2 cents.

PS: Someone/anyone will still gain (something?) from this...finally we get a solid game made by Unity; hoping we can 'make use' of anything in it...(because, it's possible, that for your game, it may not lend well or like can't use (much) anything (hope not)..they said that Gigaya is still quite a 'specific' project and 'taylor-made' for/customized -for Gigaya; thus, less modular? less 'overal general' thing... hoping it applies to your game (and I know you can't make a game 'for everybody'...it'S normal, a game is very custom thing, that might be only applicable to it, no other game; it's like other companies making 'Specific game engine' (custom/in-house) for just their specific -1 game; and, of course, Unity tried to reverse that and be a general 'tool box/slate' for any kind of game; and then, you need to customize yourself, to your specific game because there is no single same game/same needs/requirements, for each game... (is a unique affair)).

 

Are they though? I don't believe Unity has ever provided statistics for this. At best we can only look at the forums and even then that's only a small subset of actual users. For example in 2014 there was a blog post stating the forums had less than 500,000 registrations but at the time Unity was bragging about 5 million developers.

What we're seeing on these forums is a vocal minority for all intents. Which makes me wonder if the reason we didn't have a project like this is for a long time is because it wasn't truly desired by the majority of developers.

https://blog.unity.com/community/we-got-karma

That said even if it is true are you truly solo if you rely on third party assets from the store? Gigaya has the team it has because they're building everything themselves from scratch, but most developers are not making games with the purpose of seeing how difficult it is to make games.

If a developer doesn't want to build their own character controller they might buy one from the store but then they didn't develop it and may even rely on the asset author to troubleshoot it so are these people as truly solo as they appear or claim to be?

I'm not just thinking of code either. Are they buying artwork? Music? Sound effects? All of that has to be created and it's either you have it custom created like the Gigaya team appears to be doing or you pay someone to do all that work for you.

 

Hi Ryiah, thank you for that.

Yes...perhaps I'm totally 'off'...about the numbers; and, actually, there are tons of teams...and that solo or small 2-3 teams are (actually) not That many. Yes, there are...but in all, you are probably right that the 'middle/mid-indie/mid-sized' teams...are the more populous. And, thus, I would understand why Unity 'stuck to the middle'...hoping to satisfy...most people (from mid indies to big indies...and in some way..small(er) ones too; just doing it 'in the middle'/mid-team sized)...and, of course, if they are the most populous, they are the 'bread and butter' (financial return), so it only make (business) decision (business--wise) to cater to them. I had heard that mobile game devs with 'mid-sized' teams were the most numerous..and that solos, all togethere, are kind of the unicorns (understandably...with difficulty of making a game -as solo -> crazy/only crazy and ultra-convinced/resilient do it/is bound to fail).

I have thousands of assets in my game (through outsourcing asset store..and other places..it means the game's components were made by thousand 'over planet earht'..leveraging as much as possible)

Yes, you are correct/an agreeing with you, I am not 'True True True' solo...far from it...I rely on others...true solo does not exist..because even the chair or keyboard you use...was made by someone else (even the OS/computer we type in...)...we just 'make do' with waht there is and create something (from others before us).

I just meant by 'solo dev'...like 'maestro' conducting the orchestra (kind of like a Director..directing/helming the film -his/her vision..is in that film).

I think Gigaya will show us the limits of what we can do/or not....solor or smaller team...but it's great nonetheless..because there might be a tool or 2 we can make use of...it's not pointless.
Just a 2 cents.

 

This is straying awfully close to philosophical debate territory, but the short answer is that no, Unity will not somehow magic a 15 person job into a 1 person job.

It's entirely possible that, given enough time, the tech and tools will get to the point where such a project can be done by a much smaller team or even one person. But expecting Unity to go from where general game dev tech is now to that in the near future is simply not realistic.

Edit: Ryiah's point about using the Asset Store or other off-the-shelf tools to plug gaps is a good one. It's a reasonably effective non-technical solution to the same underlying problem: how can we help small teams achieve bigger things?

 

What interests me is could the team now start churning out new levels with the toolset they have created or was this a bespoke level like their demos?

Maybe the real test for a Unity game is if we can jump into the Editor and make new levels quickly?

 

It really depends on your definition of a prototype. Ive heard of some prototypes taking 24 hours and some taking a year (typically in AAA).

But also have to remember that the 3 months wasn't JUST 'build a prototype'; as I said before there were many extra tasks to do as part of creating the project internally at Unity:
- Gathering feedback whilst using the tools and meeting directly with R&D to give that feedback
- Dissecting best practices from internal teams and figuring out how to incorporate them.
- Evaluating what internally knowledge and tools we have that we can utilize.
- Establishing collaborative workflows between new team members (As said; most of us have never worked together before)
- The team has a variety of experience with Unity; some 10+ years and some not at all (And have come from other game engines) so there was an element of education happening across all-roles.
- We started from zero-code baseline.
- Zero crunch.

Id estimate that if we were a team already with establish collaboration, workflows, tooling etc then id say that perhaps 1 month would have been that kind of timeline for same results.

 

3 months for prototyping this game if you are not using external assets is not long at all.
Also prototype code should not be throw away.

 

In the team; we have discussed which tools/frameworks we have built that we would reuse again on a potential future project regardless of what genre it is (DISCLAIMER: Before people get carried away; we are working 100% on Gigaya; but its fun to have speculative discussions every now and then about the long-term future). And there are certainly several 'candidates' that we would reuse and speed up productivity (so we are not starting from zero-code).

- Flexible Object Pooling (We use this for everything duplicative in Gigaya)
- SFX Tools (Leverages the Object Pooling)
- Scene Loading
- Save System
- Quest System
- Collectables (Would require some configuration for whatever the new 'Collectables' would be)
- Scriptable Object Variables and Anchors (System to handle cross scene referencing of values)
- Some UGUI tools (Although depends if we want to use UI Toolkit; we evaluated that a few times but could not use it due to missing functionality)
- Material Surface Tagging (Allows artists to label a Material as a type (IE: Wood, Rock, Ceramic) and then query against that for stuff like SFX, VFX, etc)
- Input Setup with context switching (Although this does usually become game specific...)
- Settings System (Device, Audio, Graphics, etc)
- Pause System

In the long-term id like to see some of these tools become more fully fledged into some kind of 'package'; especially things like Settings System which are fairly boring/cumbersome to do but basically every game needs one in some form. (Can't wait for someone to reply with "wElL, AcTuAlLy...") However id only deem them a 'production standard' after use in several productions.

Curious to know what others think

 

I think I've mentioned cross-scene referencing and object persistence (i.e. save/load) a few times.

What do you mean by "production standard" here?

But yes, I fully agree that some off-the-shelf systems to solve common problems would be great, and the list you've got there seems pretty decent to me. In particular, if Unity has a team dedicated to creating such things the optimist in me assumes / hopes that they'd be able to put more time and resources in than a small team can while also developing the rest of a game, and thus they'd be able to make better tools which are more productive to use even if we need to extend / modify etc. on the receiving end.

But... how are they going to get the maintenance commitment after that to keep them viable moving forward?

 

My definition: They work as expected in a few store-shipped projects. Also meet various console cert guidelines.

The age old question!

Im of the opinion that if you have a blocking reliance on something then you will prioritise maintaining it.

For example; if my bike has a puncture then ill do my best to fix it ASAP so I can continue to use it to commute to the office.

So lets say the Settings System i've built breaks in latest URP (for whatever reason); then I have a reliance on fixing it as I need it to work with Gigaya, and whatever else we would be working on etc.

 

Which is very different to the definition that Unity as an organisation seems to live by in this regard.

I haven't re-read to check up, but... do you? I thought that Gigaya was working just with LTS stuff. Or may that not be the case for other hypothetical future projects we're having a just-for-fun speculative discussion about?

That said, even if maintenance of such packages sticks to the LTS I'd be groovy with that. Even if I have to wrangle them to a later version myself I suspect that'd be far quicker than making my own from scratch, and there's the possibility of crowd-sourced support for such things, too. E.g. go back to putting stuff on GitHub and let people contribute, which could in turn save you effort later (but might also be a handful to manage, so... who really knows?).

 

I am only speaking to that of my approach working as a developer on Gigaya and in this team.
Decisions on organisation, structure and approaches in the larger company is well above my role and pay-grade.

Yes, we are on 2021 LTS.
I was giving a potential scenario if or when we move to the next LTS (2022).

My experience in the past of 'just crowdsource it and it will be better!' results in a lot of admin work in actually handling the community contributions, and reviewing those contributions to deem if they are valuable for the core tool and not something hacked in for a specific use case or someone's own project only. or something unperformant or something untidy, etc.

DISCLAIMER: Im not disregarding crowdsourcing/open sourcing as a strategy; just cautious that its not the turn-key solution some people think to a default better product; without the structure and resources in place to handle it effectively.

 

For sure, and I'd absolutely understand if Unity decided those resources are better put to use by, say, getting someone internal to do that maintenance. ;-)

 

This sounds like pretty standard experience for most devs.

The team grew from 7 to larger? Has everyone been more or less full time?

Do you think your overall time investment would be similar to what a studio would expect? As you mention, your focus is mixed toward both game building but also providing source to the community, so you've been somewhat split.

My focus is really on you guys understanding pain points so you can help improve many points that need improvement. But, again, your sense of what constitutes a pain point can very easily depend on the amount of time/money you throw at the problem.

So for instance:

• I tend to find the cinemachine collision logic for 3rd party camera to be very bad. This is frustrating to me because it requires hand rolling my own replacement collision.
• That replacement depends on me understanding at least some the architecture of cinemachine.
• So in order to replace that narrow bit of functionality, it requires quite a bit of time investment in understanding the surrounding systems.
• The result is that replacing the 3rd person camera collision logic ends up taking a week rather than a day.

Now, if I had originally scheduled three months for camera extension work - this cost wouldn't matter much because I've baked the cost into that sub-project. A week of ramp up is less than 10% of 12 weeks, whereas, its 500% of 1 day.

So a huge amount of what you take away from this project depends on your expectations and scheduling.

I hope that you guys didn't just 'throw money at problems' until they went away. Because a lot of what makes a problem a problem is that it requires more time to solve than it should, not that it's impossible to solve.

 

If a level designer opened GIGAYA how long would it take them to make new levels?

 

When the Game Foundation project left the ground I was advocating for this fiercely, talked to many people at Unity and particularly to the team which had the GF project at the time.
I tried to steer them in this direction, making off-the-shelf common solutions for basic problems.
They ultimately shut it down and handed it over to the mobile team and made a greedy move and basically shut out any non-mobile, non-microtransaction-related service/solution.
The GF project could have been the thing we're looking for here, it didn't happen. (And I was and I am a very loud sad panda about this)

 

In general, I would really like to see existing tools improved, extended and simplified rather than more new stuff added.

Unity doesn't need more new packages nearly as much as it needs its existing ones refined.

For what it's worth, I'd personally really prefer that time be invested in improving stuff like Cinemachine, Timeline, Terrain, etc, rather than adding a new quest system or settings system.

Not trying to be a negative nancy, Gigaya is a great step in the right direction, but I hope it focuses on mostly on improving existing systems.

 

Yes quest system is not a feature we should especially wait for.
But Settings system is actually something I'm looking forward to.

 

While not related to your question.. I was just thinking it's high time Unity staff actually had some fun with Unity for once. And building a game with stuff that's really just for that game without the stress and baggage is a really healthy thing.

Maybe it would be nice to finish Gigaya sooner rather than later though, ship it. So you can get a fresh game going, and some fresh fun to talk about. Don't let it drag on.

 

Well, just like the movement, the inventory and all, they are highly custom and differ from game to game.
But, there is an underlying data-storage solution which can be provided by Unity, so we can easily build custom UIs on the top of those, as our games need. I'm not saying having these is crucial, but having these is highly convenient and can be a standardization effect (like some prominent asset store assets could be built on top of these Unity features).
It could help a lot of people, mainly those who don't code that much or those, who have no resources. Like small teams and solo devs, who have a ton of work regardless of the quest system or inventory.
Just like Unreal doesn't need an ability system and it has one regardless and it is not a mistake.

Same thing, mainly data-storage problem, although I advocated for (and I still think Unity should do it) that Unity build one and also a launcher which can do what most games do (like measure power and make settings (semi)automatic and all that).

These are QoL solutions, but can be important and make or break projects, they can allow smaller teams having bigger projects because ease on the work load without hindering creativity.

 

I was more concerned about things that can be changed or cannot be changed during runtime or startup. It is not always obvious and supported (up to date with unity features) settings system could be very useful.

 

Do you now have the tools/toolchain to build new levels for GIGAYA quickly?

Or you have spent 3 months making a single level prototype how long to make 1 new level (best guess)?

 

Cinemachine, Timeline, etc are not developed or maintained by the team making Gigaya. Those are created by R&D.

Where Internal Production Team aims to fit is use these general purpose features to create game-related 'layers' ontop of them. IE: Quest, Save, etc. The stuff that every game ever has in some form. And then give feedback in doing this to the R&D teams if something is a pain point or something is missing or something works well.

 

As usual with open questions like this: 'it depends'!

I can't say an exact time frame as we haven't currently made a 2nd level.
My guesstimate is quicker due to having a foundation of tools in place (Checkpoint System, Save System, Character than can do XYZ, 'machines' for moving platforms, levers, buttons, etc); but also depends on what a new level requires in addition to the existing technology.

For a scenario: Lets say there is a new level themed around ice/winter (Similar to a level of Mario).
Off the top of my head we would have to evaluate and factor in:
- New Art Assets and probably shaders to represent ice/snow etc.
- New VFX for environment snow, etc
- New abilities/animations/vfx for the character? Contextual to the ice environment?
- New Puzzles? What opportunities does an 'ice' level bring?
- New Enemy types? Or do we just reskin the previous ones?

Its not as simple as just slapping together some pre-existing prefabs to a new scene and picking a new tint.

In my experience; new level content timelines are mostly determined by the art creation and implementation pipeline. Code changes are usually a much smaller amount of time (But again this depends if now the character or enemies or puzzles have entirely different ability/logic sets)

 

We still plan on shipping in 2022. The whole team is working crazy hard towards this (but of course, no crunch!)

 

Im super happy you are all working on this, I am sure already internally you folks are seeing why we have harped on about making a game internally like this, the things you have already learnt from it workflow wise, usability wise etc I am sure already make the time investment worth it

Hopefully the process will produce enough findings to warrant a second game afterwards, perhaps next time focusing on altogether new aspects such as some suggested in this thread (and that way not to derail the development of Gigaya)

 

Good response but let's say your on your first chapter/biome of your game and nothing big changes your just making variations on what's there with slightly higher difficulty how long now?

My point is I suspect that good to great game development is making the tools/pipeline to then make your game easier faster and better, how good is your current toolchain and would it be good enough to make a couple, 10, 20, 100 levels in a few months?

I imagine this is why some of the greatest indie game developers have gone big on Level editors or Procedural Generated content.

 

Seeing as the Experimental AI Navigation Package has been updated and now the Minimum supported version is increased to Unity 2022.2. How are you handling that, do you stay on the older version even when that is still experimental?

 

From my limited experience I would imagine the Unity editor to be good enough to make additional levels with existing assets for a game like this. It's hard for me to think of tools that would aid you greatly with that process without also sacrificing artistic ability. You could even just duplicate the level you have and start moving stuff around. The most important thing for me would be that any puzzle related prefabs etc. have all the configurability you need built in so that you're able to drag start/end locations around, wire up buttons and triggers to doors etc. etc.

Human: Fall flat on Steam (https://store.steampowered.com/app/477160/Human_Fall_Flat/) allows you to make your own levels. Their "level editor" is just a Unity project. There is a lot of tooling in there for publishing the level you make to Steam Workshop, capturing a screenshot of it, auto-placing the player character and other essential components etc., but for the most part you're just dragging prefabs around. Extremely unfriendly for someone unfamiliar to Unity, but for a Unity developer I imagine it gives you a lot of needed freedom while being "easy enough" to use and not restricting your artistic ability by limiting you to a predetermined grid or whatnot. They also have a lot of puzzle related prefabs for wiring up puzzles etc.

As for the ability to make a lot of levels really fast I feel that's a conscious choice you make early in development by making your game grid based or procedural as you mention. In doing so you sacrifice a ton of artistic freedom for the ability to have fast or even automatic level generation. The type of procedural level generation popularized by Spelunky (afaik) where rather than creating your levels entirely from an algorithm, you create them by just slapping premade chunks together, can be applied to anything imo. You could probably chunk up the level in Gigaya, each chunk having some variation in monster spawns, puzzle type etc. and create some code to randomly piece it together and call that infinite procedural levels. Or do something like Portal where you have both freeform handmade levels as well as grid based simplistic levels that could easily be procedurally generated, if it wasn't for the fact that procedurally generating fun puzzles is extremely hard. But at least they can be manually created really quickly, again if it wasn't for the fact that manually creating fun puzzles is extremely hard.

The puzzle game Jonathan Blow is currently working on (and streaming on Twitch) has something like 600 levels the last time I checked. He can create puzzles really quickly with a custom level editor where the 100% gameplay complete end result is basically just a lot of cubes, and since the entire game is entirely grid based it would suit itself well to automatic art generation, but they're still hand making and hand placing every single artistic element from what I can tell.

Either way I guess we'll see when it ships. I have to imagine a lot of projects and adaptations will come from this.

 

i see, makes sense

 

With platform elements then it's all about jump distances and drop heights and that's just static platforms once things are moving/bouncing/swinging it gets more complex. A set of in Unity Editor utilities like a constraint checker or level test system could ensure that you keep things with the right distances for the player.

Ditto for puzzles a navmesh style checker could ensure no Key / Door pairs are unreachable.

Could navmesh be Utilised as a level test kit, checking that all inbounds areas are reachable and out of bounds areas are not.

 

You can make a specific sized cube to measure things like that.
Why waste valuable programmer time to build fancy rulers when a cube will do? And the game has to be play tested thoroughly anyway so you have plenty of redundancy there as well.

 

Automated gameplay tested is something that is well accepted practice now, unity offer even machine learning services about it, even game like the witness had automated pass on their level. It saves time because a program don't get tired or bored and can run at lightspeed limit.

BUT I think this is too advance for GIGAYA anyway, it's not a project planned to solve pain point, it's way too simple and safe for that, it's not the ambition. At best they might encounter some random pain point and report, be a marketing tools and an inspirational learning tool for beginner. It's best if they can get comfortable with it (and working as a team), before starting answering real questions (if they survive corporate will) with another project. I hope they have fun for themselves.

 

!?

You have links on this? Is this really a thing now?

 

Unity

not unity
http://the-witness.net/news/2012/12/mapping-the-islands-walkable-surfaces/

There is also a GDC vault about assassin's creed origin.

and more if you look about it.

 

From personal experience: yes and no. I implemented a similar system for out of bounds testing in a first person shooter I was working on and found there were a lot of issues that had to be address. Most notably, I had to reimplement the entire navmesh system myself to account for things like custom agent controller shapes (my players had cylinder colliders for ground testing instead of capsule ones) and other nuances. Accounting for jump arcs is relatively complex math as well if you have to include things like velocity inherence, air control, and basically anything else that can change the jump from a simple parabola.

Of course, this means that eventually you might also have to account for different moves.

Some hypotheticals:

• is there an air dash?
• can you air dash in a different direction?
• do you have a back dash for that instead?

The more complexities that are added to movement, the more you have to account for that in the math. It's something that must be made incredibly specifically to a project but, more than that, the amount of work it adds in its own implementation doesn't really justify it as a testing tool 99% of the time.

 

You can probably do the compute once offline to get a or many "reach" bubble/volume, then do a kind of sum of the mesh and the bubble (technical terms i think is Minkowski sum, but i was doing that before knowing that name).

And also, the techniques don't have to be perfect, it just need to capture between 60% to 95% of rot the cases to be useful, it will lift a good burden on QA. So yeah, a navmesh CAN be a good rough pass.

As far as I know, nobody use a perfect automated pass.

 

Bubble volumes are never really "good enough." You mention 60-95% but with bubble volumes you'll only get the most rudimentary of results, often on the lower end of that. There's a difference between a rational "this level has an exit" test and "you can't easily get stuck in an out of bounds area" test.

Like I am speaking as somebody who tested and implemented this sort of thing, which involves evaluating a lot of different potential solutions.

 

I guess it depend on the project, worked for me.

 

Yes, it's a thing, and people sell commercial services for it, and it's not especially new.

Example: Mighty Games' Test Bot. From the talk I saw on it, it's basically a bit of software which "plays" a game by deploying it to whatever devices are available en mass, giving it random-ish inputs, doing some error detection. If it hits an error condition it then has a recording of what inputs / other events got it there, as well as the error itself. For more complicated games a layer of game-specific smarts can be added. Advantage is that it picks up stuff that people won't, disadvantage is that because of its randomness it's statistically influenced rather than directly controlled. In any case, it works because of the sheer number of test runs you can have going simultaneously, though human testing is still also needed.

In any case, the broad idea of making bots for your games that automatically interact with them isn't new, nor is applying automated testing in general. It's not something that seems super popular amongst indies, though, for whatever reason.

 

You guys seen the DX12 thread and how Gigaya is driving serious optimisation for multiple teams in Unity? That's pretty useful. https://forum.unity.com/threads/why-is-dx12-so-much-slower-than-dx11.841903/page-3#post-8201172

 

Seems like there was more low hanging fruits that I had expected...