|
Pollyanna posted:I don't think Ink is going to be useful for anything other than dialog-driven games, or text adventures. You might be able to make like a visual novel with it, but it's still going to revolve around dialog, and the engine is such that programming takes a backseat to text. It's a plugin for unity. They built it for text games, but you can invoke it for cutscenes, etc and have it drop out after it's done. Haven't used it extensively myself, but my eye's on it for whenever I decide I want dialog somewhere.
|
#
?
Aug 18, 2016 05:02
|
|
|
|
| # ? Jun 7, 2024 15:09 |
|
|
Pollyanna posted:I don't think Ink is going to be useful for anything other than dialog-driven games, or text adventures. You might be able to make like a visual novel with it, but it's still going to revolve around dialog, and the engine is such that programming takes a backseat to text. Edit: Added newlines to the big dialog so I didn't break tables. code:The root of the dialog checks if "first trigger" has been set yet. If it hasn't, the the big dialog tree runs. If it has been set, it just goes to the terminal dialog. The big dialog poses some choices. If you pick "Hello back!" it will set the trigger. If you do "Derp Derp" it won't. Either way, it hits the same concluding dialog. In-game, with the reset that happens at the end of the dialog--which is triggered by "->END"--it will remember that I hit the trigger and go to the secondary dialog. I suspect I could declare variables in the script and do some serialization thing with it--even a weak little thing--but I figured I'd ask around first. Learning this syntax was kind of a pain, but having the editor play it back makes a big difference. It works as expected in-game. I have my text control that can alternate between spitting dialog and prompting for selectable choices. I should add that I think it was about 7 hours of work between embedding ink and creating the GUI control. I suppose I could have continued with IronPython and potentially come up with something else, but I think I'd be doing some butchered equivalent of coroutines in Python to get the right effect.
|
|
#
?
Aug 18, 2016 06:59
|
|
|
This is the microest of micro optimizations, but I just learned most of Mathf Unity stuff is just a wrapper around System.Math where it converts the input to a double and then converts the result back to a float. You can save yourself a function call and just call Math yourself. Probably rarely necessary but with voxel stuff sometimes I am doing a bazzillion repetitive things an update and just saving where I can and I noticed Mathf.Round in the profiler. FuzzySlippers fucked around with this message at 09:29 on Aug 18, 2016 |
|
#
?
Aug 18, 2016 09:27
|
|
|
FuzzySlippers posted:This is the microest of micro optimizations, but I just learned most of Mathf Unity stuff is just a wrapper around System.Math where it converts the input to a double and then converts the result back to a float. You can save yourself a function call and just call Math yourself. The compiler should optimize the wrapper call into nothing.
|
|
#
?
Aug 18, 2016 15:59
|
|
|
taqueso posted:The compiler should optimize the wrapper call into nothing. How would it do that? Is the runtime allowing itself to trade precision? Will it then create a new version of the System.Math calls using floats instead? It's been long time since I've been doing VM performance stuff (Java in mid 2000s), but this was a tricky point in optimizing the JVM for floating-point benchmarks. To some extent, the Java specifications even prevented them from reordering arithmetic operations because that could imply a change in floating-point precision.
|
|
#
?
Aug 18, 2016 16:23
|
|
|
Well Unity compiles IL down to CPP. So not only do you get whatever optimizations C# compiler can do when compiling to IL but you also get whatever optimizations the C++ compiler can do. Not sure at what stage in that whole pipeline the wrapper can get optimized out but I'm sure it is. If it is happening at the C++ level of the pipeline then you won't see that benefit in the Unity profiler.
xgalaxy fucked around with this message at 18:41 on Aug 18, 2016 |
|
#
?
Aug 18, 2016 18:39
|
|
|
xgalaxy posted:Well Unity compiles IL down to CPP. Just to be super pedantic IL only compiles to CPP on IOS, Html5 and UWP IL2CPP build right? Everything else is still using mono runtime?
|
|
#
?
Aug 18, 2016 18:58
|
|
|
Stick100 posted:Just to be super pedantic IL only compiles to CPP on IOS, Html5 and UWP IL2CPP build right? Everything else is still using mono runtime? Hmm. Pretty sure I read they have IL2CPP on Windows, OS X, and Android now too. But maybe I misremember. They don't appear to have a feature grid anywhere on their progress with IL2CPP per platform unfortunately. I guess a tedious way to find out would be to grab latest version and try and set IL2CPP as the backend for each platform. xgalaxy fucked around with this message at 22:46 on Aug 18, 2016 |
|
#
?
Aug 18, 2016 22:42
|
|
|
Switching to calling System.Math instead of Mathf had a pretty tiny impact when doing an absurd number of calls (15k+) of around 0.45ms. Not a super accurate benchmark (just Unity profiler) and obviously that's pretty drat small but enough for me to consider it non-zero impact. Not something I'd do much anywhere but this is on the code that converts various positions to grid values (e.g. Vector3 to a Point3 Sector or voxel space to chunk space, etc) which can run a crazy number of times when iterating through new chunk blocks or some such. That's why I've gotten to some gnats rear end tweaking and I was checking pretty much all the code that runs there pretty thoroughly. I've also never really been concerned about memory impact in my code (as opposed to textures or models or whatever) until this voxel stuff where its really really easy to balloon from a couple hundred megs of world data to gigs and gigs if you gently caress it up. Edit: Also il2cpp stuff isn't here yet for desktops but I think most everything else is tho? Once they do that is when they also upgrade mono which is definitely not in 5.4 FuzzySlippers fucked around with this message at 02:24 on Aug 19, 2016 |
|
#
?
Aug 19, 2016 02:13
|
|
|
Yeah... Definitely profile first, and then make performance optimizations. There's almost always a #1 most expensive function that you can attack - and actually get something tangible for doing so.
|
|
#
?
Aug 19, 2016 02:35
|
|
|
Cutting .45ms sounds great to me.
|
|
#
?
Aug 19, 2016 02:59
|
|
|
My worst impact stuff I haven't been able to make good headway so I started screwing around with little poo poo hoping I might stumble into something that is bigger than it seems. When I've been searching online that checking a Contains on a hashset or dictionary should always be crazy fast but when you start doing it an insane number of times should that be a pretty significant impact (30k = 11.62ms) or does that indicate my hashcode or comparer is dumb? edit: yeah typo I meant 30k calls = 11.62ms FuzzySlippers fucked around with this message at 04:01 on Aug 19, 2016 |
|
#
?
Aug 19, 2016 03:37
|
|
|
FuzzySlippers posted:My worst impact stuff I haven't been able to make good headway so I started screwing around with little poo poo hoping I might stumble into something that is bigger than it seems. 12m * 60 s = 720s 30000 / 700 = 43 checks per second..? That seems crazy slow, so maybe I'm missing something.
|
|
#
?
Aug 19, 2016 03:57
|
|
|
I assume milliseconds?
|
|
#
?
Aug 19, 2016 03:59
|
|
|
If you're doing Contains with a struct type and the struct isn't a primitive then make sure you're either using a customer comparer or implementing IEquatable<T> on the struct because if it has to call Equals(object) to do the compare then it will box it and everything that it has to compare to.
|
|
#
?
Aug 19, 2016 04:02
|
|
|
Yep I've done both (implement IEquatable and a custom comparer). Edit: wait I noticed Hashset.Contains is creating gc alloc. Shouldn't that only happen if it was boxing? My comparer: code:Edit2: gently caress a duck. Replacing the hash with something from stack code:FuzzySlippers fucked around with this message at 01:42 on Aug 20, 2016 |
|
#
?
Aug 19, 2016 04:04
|
|
|
rarbatrol posted:Yeah... Definitely profile first, and then make performance optimizations. There's almost always a #1 most expensive function that you can attack Optimization is about speeding up the slow stuff. Profiling is the only way to optimize, anyone can look at code and guess what's slow but it's darn near impossible to be 100% correct with compilers, system optimizations, os optimization, and cpu optimization occurring beyond your control. Best thing to do is profile or create your own profiling and find out what is slow, then figure out if you can speed that up. Repeat until fast enough.
|
|
#
?
Aug 19, 2016 08:14
|
|
|
I need some books on C# bullshit! I have no idea what are good ones! So, I'm asking you fellows, since you're all very smart and kind and such and such. Leper recommended Martin Reddy's API Design for C++, which I got on PDF, and its pretty cool, if mostly over my head in terms of discussing problems in a more professional environment or in dealing with things that I haven't gotten anywhere near encountering. I was looking for stuff more related to Game Programming directly. I'm looking for things related to AI, engines (even if I'm not dealing directly with engine stuff due to using Unity, I'd still like a good reference on things), implementation (I've gotten some loose understanding of design patterns but still a bit lost on the nitty gritty of the how-to), the Unity engine itself, and really anything else that anyone would feel a C# wannabe programmer ought to have around. I'm not looking necessarily for a tutorial/textbook sort of thing; a good reference book for being able to look up information on broader concepts than the more narrow stuff that web resources like MSDN covers would be really helpful to me. I might be asking for things that are not necessary/useful and/or too broad or whatever, I am aware. I'd just like to have something on hand. e: current list of things recommended I have is just reddit ( https://www.reddit.com/r/gamedev/comments/42lsih/game_programming_essential_books/ ), but the recommendations look pretty good. Curious if there is stuff more centered around C# or Unity itself, but that's probably not essential, I imagine. Tiler Kiwi fucked around with this message at 07:38 on Aug 20, 2016 |
|
#
?
Aug 20, 2016 07:17
|
|
|
The Game AI Pro series is a pretty good overview of AI techniques in industry, and they're generally language agnostic. They're current (and essentially a continuation of the AI Game Programming Wisdom series, which are also good if a bit dated). Someone in the thread you linked recommended Abrash's programming black book. While it's available for free, I'd stay away from it; it's mostly about low level optimization, and will be unusable if you stick with C#. It will also be mostly unusable if you go to C++ and aren't a crazy person. It's on my reading list for historical curiosity rather than relevance. Someone who's read through it may be able to provide more context, but I expect you would not enjoy it at present regardless. Unity In Action seems to be along the lines of what you're looking for, but I can't recommend it as I haven't read it. Good reviews though, so maybe roll the dice?
|
|
#
?
Aug 20, 2016 13:34
|
|
|
I haven't tried the Game AI Pro books. I did read this one though awhile ago and thought it was excellent: https://www.amazon.com/Artificial-Intelligence-Games-Ian-Millington/dp/0123747317/ref=sr_1_1?ie=UTF8&qid=1471717823&sr=8-1&keywords=game+ai
|
|
#
?
Aug 20, 2016 19:31
|
|
|
Here's another crazy good gem for finding learning material about AI: http://aima.cs.berkeley.edu/ai.html (you're welcome)
|
|
#
?
Aug 20, 2016 19:42
|
|
|
How do the cool kids manage level changes in Unity? I was hearing a lot about single-scene games, with level data just getting swapped in and out. That would do pretty well with the global GameObjects I have. One is for InControl, in particular. However, I'm not sure what would be the best way to swap out all the ProBuilder level data objects that I have running around. A scene change would make better sense with that. So what's a poor boy to do?
|
|
#
?
Aug 20, 2016 21:59
|
|
|
What's a good datatype/container class(In Unity/C#) for storing a 2d tile-like map that can frequently expand/contract in real time throughout the game? And do so in any direction. My first thought is just a 2d array but resizing that, especially in the west/south(assuming east/north is positive), would be a pain. I'm thinking I could use something like a Dictionary<IntVector2, MyTileType>, but is there some downside to that? Would it be really slow to iterate through when I have to? I cant think of why there would be but I have never seen a dictionary used like this so I wanna make sure there isn't some obvious drawback I haven't considered. Or some obvious better choice for that matter.
|
|
#
?
Aug 20, 2016 23:13
|
|
|
Rocko Bonaparte posted:level changes edit- misunderstood the problem, oops Tann fucked around with this message at 21:32 on Aug 21, 2016 |
|
#
?
Aug 20, 2016 23:29
|
|
|
Rocko Bonaparte posted:How do the cool kids manage level changes in Unity? I was hearing a lot about single-scene games, with level data just getting swapped in and out. That would do pretty well with the global GameObjects I have. One is for InControl, in particular. However, I'm not sure what would be the best way to swap out all the ProBuilder level data objects that I have running around. A scene change would make better sense with that. So what's a poor boy to do? I've done both and I'm not sure there's much difference. Your global objects can be set to Object.DontDestroyOnLoad so you keep them on scene changes. Loading a scene does allow some auto cleanup of old objects. OTOH, most of the commercial Unity projects I've looked at keep everything in one scene. At the moment I keep everything in one scene even the main menu as it is simpler managing object pools and such. I really liked the idea of keeping all my UI objects in their own scene and use LoadLevelAdditive (so if you want to load your current UI anywhere even a dummy box it is easy) but I've run into some editor bugs that can end up with a scene saved with the additive objects so I've abandoned that too. They might have fixed those recently though.
|
|
#
?
Aug 21, 2016 00:20
|
|
|
Rocko Bonaparte posted:How do the cool kids manage level changes in Unity? I was hearing a lot about single-scene games, with level data just getting swapped in and out. That would do pretty well with the global GameObjects I have. One is for InControl, in particular. However, I'm not sure what would be the best way to swap out all the ProBuilder level data objects that I have running around. A scene change would make better sense with that. So what's a poor boy to do?
|
|
#
?
Aug 21, 2016 01:04
|
|
|
Spek posted:What's a good datatype/container class(In Unity/C#) for storing a 2d tile-like map that can frequently expand/contract in real time throughout the game? And do so in any direction. But probably the best answer is to just encapsulate whatever you use (optionally using an iterator for adjacent sequences); this way later if it turns out to be a performance issue (it probably won't) you can revisit it and switch out the underlying container easily.
|
|
#
?
Aug 21, 2016 01:19
|
|
|
In unity I always do one scene. My game objects are generally mutable, pooled, or culled, depending.
|
|
#
?
Aug 21, 2016 01:37
|
|
|
Shalinor posted:I do the same single scene thing, for a procedural game. Previous game we did scenes as levels, and it's honestly kind of a nightmare to manage for a large project. In practice, objects surviving scene means you have to refresh references post scene change, and doing that without something breaking on one side or the other is just... ugh. I'd much rather go single scene data driven in the future. Loading scenes on top of other scenes may also be viable? But the scenes as levels thing, nah, can't recommend it for bigger stuff. What's an example of references that have to be refreshed on a scene change? The games I've worked on at work change scenes frequently and I can't say I've run into any problems like that (and we have a whole mess of DontDestroyOnLoad objects).
|
|
#
?
Aug 21, 2016 02:19
|
|
|
Thought I read somewhere that they are planning on deprecated DontDestroyOnLoad in favor of some Scene management api changes that are coming down the pipe.
|
|
#
?
Aug 21, 2016 03:38
|
|
|
I added scene changes to one project to keep everything in memory budget. It was mostly to let the artists go ham on the level selection menu. Probably could have done the same thing with prefabs, but it would have required me to be more diligent about it. Scenes for levels means you can let the scene management stuff take care of most of the loading/unloading objects. It worked pretty well, but I was functionally the only engineer on the project, so it wasn't terribly large.
|
|
#
?
Aug 21, 2016 04:35
|
|
|
Shalinor posted:I do the same single scene thing, for a procedural game. Previous game we did scenes as levels, and it's honestly kind of a nightmare to manage for a large project. In practice, objects surviving scene means you have to refresh references post scene change, and doing that without something breaking on one side or the other is just... ugh. I'd much rather go single scene data driven in the future. Loading scenes on top of other scenes may also be viable? But the scenes as levels thing, nah, can't recommend it for bigger stuff. What does the workflow look like for trying out different scenes and editing the levels? As it stands, I have this shitpile of ProBuilder pb-Cube-143317 crap in my hierarchy. I am not so sure what I should be doing to shuffle that out with another shitpile of ProBuilder pb-Cube-###### stuff. I suppose that's more an issue of what ProBuilder is doing than anything else. All I can really think of is trying to create some handle and then cram all the stuff under it. That wouldn't address how to create different levels though.
|
|
#
?
Aug 21, 2016 06:48
|
|
|
Triarii posted:What's an example of references that have to be refreshed on a scene change? The games I've worked on at work change scenes frequently and I can't say I've run into any problems like that (and we have a whole mess of DontDestroyOnLoad objects). We solved it by making almost all the managers die with the scene. Only a handful survived, and we gated access to them very carefully. Meant loads were less performant, but who cares at that point. (Though I think the more typical reason for single scene games is just that unity scene loads are slow, and their streamed load doesn't actually give you smooth loading - it hitches constantly, or at least did on 4.x) Shalinor fucked around with this message at 17:32 on Aug 21, 2016 |
|
#
?
Aug 21, 2016 17:26
|
|
|
Spek posted:What's a good datatype/container class(In Unity/C#) for storing a 2d tile-like map that can frequently expand/contract in real time throughout the game? And do so in any direction. It depends on your performance constraints, the maximum size of your map, whether the tiles are reset on resizing and how often resizing happens. Dictionary is fine if you don't iterate through it/populate it in performance-critical. The 2d array thought is good, in my opinion. A way to handle growth could be to create new arrays, and have them organized in a separate data structure. You can then cull this according to visibility to keep memory usage down. Your viewport (ie the width, height and coordinate offset) and the actual position of tiles doesn't necessarily have to be reflected in the storage of your tile data, as it relates to object lifecycle management. It depends on what you need to do with the objects and how often. Also consider why you need to create and destroy tile objects - are they Unity game objects? Perhaps a better choice is to pool them and change the properties as the active data set changes?
|
|
#
?
Aug 21, 2016 21:11
|
|
|
IMO. You should figure out what your maximum tile / grid size will be and just used a fixed array or whatever data structure. If the map shrinks just account for that when indexing. If you are destroying and recreating your data structure every time your map shrinks or grows that will be by far your biggest performance impact. Whereas if you keep it fixed, by determining your maximum size and just allocating for that up front you will fair much better.
|
|
#
?
Aug 21, 2016 21:22
|
|
|
Well I couldn't really figure out how a level-based game would generally load level data in and out of Unity using its own built-in stuff. The documentation really heavily favors a level per scene. I suppose I should just try that first and if I find the load times or data shuffling to be too onerous, I come up with some level manager thing. It's very useful to have all the different levels in different files, that's for sure, but that leaves me with little one-off areas like walking into little buildings or whatever. I am supposing I can just put them in different locations and just make sure no AI in different segments gets fixated on trying to walk towards the player or something.
|
|
#
?
Aug 22, 2016 03:43
|
|
|
Rocko Bonaparte posted:Well I couldn't really figure out how a level-based game would generally load level data in and out of Unity using its own built-in stuff. The documentation really heavily favors a level per scene. I suppose I should just try that first and if I find the load times or data shuffling to be too onerous, I come up with some level manager thing. It's very useful to have all the different levels in different files, that's for sure, but that leaves me with little one-off areas like walking into little buildings or whatever. I am supposing I can just put them in different locations and just make sure no AI in different segments gets fixated on trying to walk towards the player or something. - Is your game procedural (so you can avoid making a huge custom map editor) - Do you have a tools team (who can make you a huge custom editor) - Is your game 2D / tile-based (so at least the tools are easy a/o there are good tools on the AssetStore already) ... 3D content-driven games are up poo poo creek without a paddle, here. Hot Tin Roof, even if we knew what we knew now, we'd still have had to make it levels-as-scenes. Maaaaaybe we could have turned the levels into prefabs, and spawned them into place, but given how slow Instantiate is, I seriously doubt that would have been workable, especially in Unity 4.X. Our solution moving forward, having done that once, is more "hahahaha content driven games? ahahahahahah...". Stuffing everything into one scene is sometimes an option, but for something like Hot Tin Roof, that scene would then melt anything short of a super computer. Some of our LEVEL scenes were complex enough that we could barely work inside them, since in normal-game, most of the scene was disabled based on visibility.
|
|
#
?
Aug 22, 2016 17:10
|
|
|
I can reassure myself it's a hot mess and just roll in it. As it stands, the world's basic scene change worked "fine" when I triggered it, but that was basically moving to a scene that just had a cube, light, and camera. While I have your attention, I guess I can at least share how I imagine it will go. I figure I would set up my player to be something of an either/or from a prefab or whatever. So if I start from a scene, it will create the player at some fixed location with some given settings that I would find useful for spot testing. However, if the scene is loaded in-game, that is omitted and I pop the player in at some designated spot. I'm assuming some of the heartache here is what to do when global state changes. Say, I just added InControl and that requires a global GameObject. I know to put that in my start scene, but now I have to know to lug that around or whatever. So I potentially have to pop that thing in every scene I'm doing spot testing. I assume this is just how I have to live my sin-cursed life.
|
|
#
?
Aug 22, 2016 17:37
|
|
|
My advice would be to mentally and architecturally decouple the game logic and the actual way you accomplish it with Unity (or another game engine). I am not saying to overengineer some bloated architectural beast on top of Unity with a bajillion interfaces and innumerable layers of indirection, (in fact I would advise you not to do that), but to accept that HOW you do something does not need any kind of logical connection to WHAT the operation is named. You want to load locations (ie 2d maps) and you want to populate them with stuff (ie the player). So you make some code that you can call to transition to a new location and place the player somewhere in it. Whether you do this by modifying the current scene or load a new one is a choice made depending on is easiest, most maintainable and gives the best result. Neither choice is inherently right or wrong. Ideally you want to be in a situation where you are perfectly capable of implementing either. I would suggest manipulating a single scene, and focusing on how to achieve your desired result by instantiating/destroying/activating/deactivating/modifying GameObjects. For example: As with the HOW/WHAT mentioned above, location in space only matters in relation to the camera. There is no need to have the actual position property be bound to the player's concept of character position. The important thing is that the position looks right in the final game. Perhaps the player object is fixed and the map is moved, perhaps the player object is child/sibling of the camera, perhaps each tilemap has a separate object and you just swap which is active - there are tons of possible solutions. Focus more on manipulating your objects form code and less on the scene abstraction. A scene is really just a collection of GameObjects and some handy logic. The gameplay concept of a location or level does not necessarily imply having to use the Unity concept of a scene. You might at some point want to use scenes to manage resources and handle memory constraints, but at an early stage just get the game up and running. Worry about the resource management later.
|
|
#
?
Aug 22, 2016 23:00
|
|
|
|
| # ? Jun 7, 2024 15:09 |
|
|
My real sore spot is that I'm using ProBuilder for level editing. That has worked out pretty well, but it now leaves me with a sack of GameObjects that it has created. If there's a convenient way to move that stuff in and out while being able to edit it, then I'm all ears. I can think of creating a UI extension that swaps in and out all GameObjects implement ProBuilder stuff, as well as supporting stuff that I know is level-related, and just use serialization for it. I guess that would let me move things in and out to edit them, right? Edit: ProBuilder is a plugin for Unity. I was not finding anything else that worked really well for slapping out the kind of basic levels I wanted to have for a top-down 2.5d action RPG.
|
|
#
?
Aug 23, 2016 00:10
|
|