|
Triarii posted:I would say that, rather than hacking TextMesh Pro to understand that <button="attack"> translates to some particular sprite, instead have a method in your input manager that says "get me the sprite tag corresponding to the attack button" (probably pass in the action in as an enum) which would return <sprite="SquareButton"> if you're using a PlayStation controller with square bound to attack, or <sprite="AButton"> if you're using an XBox controller with that as your attack button, etc. Then call that function and insert it into your string when you want to tell the player how to attack something. This is smarter than I would have figured out on my own. You are now my vacation coding buddy.
|
#
?
Dec 27, 2018 18:15
|
|
|
|
| # ? May 11, 2024 23:39 |
|
|
I think the Button issue is a good example of a Command Pattern working well (also people should read all of this book if they haven't, fantastic stuff that's great for even for non-game-development): http://gameprogrammingpatterns.com/command.html
|
|
#
?
Dec 27, 2018 19:48
|
|
|
Nybble posted:I think the Button issue is a good example of a Command Pattern working well (also people should read all of this book if they haven't, fantastic stuff that's great for even for non-game-development): http://gameprogrammingpatterns.com/command.html I love stuff like this, I've been having a hard time finding good books. Thanks!
|
|
#
?
Dec 28, 2018 06:28
|
|
|
Pseudo-God posted:The reason I am doing everything from scratch is to experiment with a novel networking model for web apps (UDP in JavaScript), and none of the existing engines fit my needs. The physics in the game will be very simple, and the existing engines had behavior that was unsuitable or too complex. I've been down this road and even have a semi-abandoned infinite multiplayer maze project laying about. Are you doing independent server and client sim with forward prediction or just server-only sim? Mine is all line and radius collision, deconstructing boxes and arcs, with some mild AABB checks. It's intended for top-down rather than platformer. My main issue was not incorporating the forward-sim position into the AABB I was using for broadphase. You could skip a lot more checks by first running an AABB that is the maximum extents of your current and next frame, finding any possible penetrations, then continuously sweeping only where those penetrations can 'reach' your true AABB. Now you have no speed cap again and do zero checks in most cases.
|
|
#
?
Jan 1, 2019 00:28
|
|
|
Is Phaser a decent pick if I want to make some short 2D jam games and only know really know JavaScript/Python? Or is there a better option?
|
|
#
?
Jan 3, 2019 22:32
|
|
|
GitHub is now giving unlimited private repos for free. The only paywall for private repos is number of people who need access. I figured this change was coming since they already offer a similar structure for Visual Studio Team Services. So if you are an indie developer and only 3 or less people need to access your repo than the only thing you really need to possibly pay for is LFS storage. 200gigs is $20/mo xgalaxy fucked around with this message at 06:29 on Jan 8, 2019 |
|
#
?
Jan 8, 2019 06:26
|
|
|
Oh fiiine. They start to do this after I got a VPS and set up git on it. So wait--are all the cool kids just cramming their code and assets together into one repository? This is timely since I have some sprites I am referencing that I am trying to figure out how to version.
|
|
#
?
Jan 8, 2019 07:53
|
|
|
Bitbucket does a great job of managing my unlimited free private repos I think I'll stick with them. What are the benefits Github offers? Because, until now there was a clear disadvantage.
|
|
#
?
Jan 8, 2019 12:21
|
|
|
Rocko Bonaparte posted:Oh fiiine. They start to do this after I got a VPS and set up git on it. For small projects just dump everything in git. For large projects, git + git lfs. For very large projects, git for code and p4 for assets.
|
|
#
?
Jan 8, 2019 14:02
|
|
|
leper khan posted:For small projects just dump everything in git. For large projects, git + git lfs. For very large projects, git for code and p4 for assets.
|
|
#
?
Jan 8, 2019 16:35
|
|
|
Remember when GitLab lost something like a week+ of everyone’s commits etc because they didn’t know what the gently caress they were doing and their backups were hosed as well? 
|
|
#
?
Jan 8, 2019 19:22
|
|
|
I find it's easier to not bother with backups and when something goes wrong pretend the backups are hosed.
|
|
#
?
Jan 8, 2019 19:42
|
|
|
So lfs still costs money? Visual studio hosting can do unlimited git with lfs for free and I haven't had any problems so I'll be staying there. It's nice having a whole project backup easy and having code plus assets in one repo hasn't caused any problems.
|
|
#
?
Jan 8, 2019 20:32
|
|
|
Self-hosted Gitlab can run on a $20/mo linode and doesn't have that hilariously low quota. This being the gamedev thread, 50GB/month is nothing especially if you're dealing with unity bundles where they'll ding you for every rebuild. Maybe I should tutorialize this for people not afraid of a little linux, or maybe I should just get a GoonLab going :V
|
|
#
?
Jan 8, 2019 20:45
|
|
|
Self hosted git is comically easy, there's no reason to use an online service just because setting up your own repo seems scary or impossible. I'd only put my poo poo online if I was done and it's open source, or wanted to get someone to help with code. And even then getting git over ssh to work has a million tutorials out there that work fine for groups with a handful of people. Git only gets hard if you gently caress something up. But you keep backups too, right? 
|
|
#
?
Jan 8, 2019 21:02
|
|
|
I lost half my code projects in school to a hard drive dying. Source control doesn't save you from that on it's own. I still don't have the money or the desire to build a setup that would prevent that (or a fire or whatever), so up into the cloud it goes, where it's someone else's problem.
|
|
#
?
Jan 8, 2019 21:24
|
|
|
I'm a threading noob. I have pathfind data I am reading from multiple threads but I write to it only on the main thread. ConcurrantDictionary has GC churn so I don't want to use it. Is ReaderWriterLockSlim on a regular dictionary my best performing bet? Profiling mostly ReadLocks with the occasional WriteLock seems quite a bit better than ConcurrantDictionary even without the GC issue. The idea I've seen of double booking with swapping between a writing collection and a thread safe reading collection would be messy with how often the main thread does need to write data*. * My half rear end local avoidance is that cells with an agent on a current path get a traversal penalty and cells right around the player get a huge penalty. This works surprisingly well since I'm okay with agents walking through each other if they absolutely have to (bottlenecks). In my testing they crush through corridors and then widen in rooms just as I want. With the player penalty they also surround rather than swarm right up to the player. The only downside is that I am updating traversal costs a lot.
|
|
#
?
Jan 9, 2019 23:22
|
|
|
FuzzySlippers posted:I'm a threading noob. I have pathfind data I am reading from multiple threads but I write to it only on the main thread. ConcurrantDictionary has GC churn so I don't want to use it. Is ReaderWriterLockSlim on a regular dictionary my best performing bet? Profiling mostly ReadLocks with the occasional WriteLock seems quite a bit better than ConcurrantDictionary even without the GC issue. The idea I've seen of double booking with swapping between a writing collection and a thread safe reading collection would be messy with how often the main thread does need to write data*. I'm only responding because I may have Dunning-Krugered into asynchronous development like this from random work I did. I just know that when this stuff comes up that people usually get very quiet because there be dragons. I don't have piles of experience with this particular topic but I have some. The impression I got from ConcurrentDictionary--and I assume we're talking all .NET here--is that it will protect individual operations, but you could get into trouble with coherency anyways. Like, if your writing thread has to perform multiple write function calls to the structure to denote one coherent unit of change, a read could come in and get a hosed up view of things. Like, say if the write thread has to mark changes in five different entries, a request could come in to read from them and only get the changes for whatever write calls had finished at that point. It's still technically thread-safe in that whatever has cleared in a write operation should be readable afterwards. I am not using multiple threads in a game, but I have to do a lot of crap with concurrency at work. My default course of action these days for stuff like this is to encapsulate the contented resource around an agent running in a thread on a queue that external agents access through exposed method calls. The exposed calls just put a request on a queue to be run later but return a Future object immediately so that the call doesn't block. In cases where the system has its own stuff to do on the data, it calls its own internal functions that puts stuff on the queue too. For something like that to work well with what you want, accesses to the structure will probably have to return copies of data and not reference into the actual data structure. You'd also have to be really careful with callbacks. On the plus side, I imagine the things requesting paths could take a Future object and wait multiple frames on it to clear before having to block on an absolute necessity of getting a path. Edit: If you set up what you want to run in a queue, you can go looking for a lockless queue that works on multiple threads writing but one thread reading. Rocko Bonaparte fucked around with this message at 00:10 on Jan 10, 2019 |
|
#
?
Jan 10, 2019 00:06
|
|
|
Yes I use that kind of structure for pathfinding requests since those are comparatively few so the callback structure works very well. This is why units continue to move as they wait for their pathfinding request to be filled and the requests are a distinct object. The question is for when a pathfinding thread goes to query the cost of traversing a square while finding its path. This information is being read by each request's thread and will be changed on the main thread mildly frequently (every few seconds compared to many many times a second reads). Requesting traversal cost will happen 1 time for every single grid cell a pathfinding thread touches. Since a path with many obstructions (common) may require checking a large number of cells and multiple agents are requesting paths at once then the number of times this information is accessed each frame can be quite huge. This is why the code is particularly performance sensitive and so reads must be as fast as possible. This is also why stale data is not very important. The gameplay ramifications for a unit having a frame old traversal cost is pretty minimal. It'll happen incredibly infrequently and if it does the result is just an imperfect path until the next path update. More concerning is the performance implications which is why I wasn't concerned about the potential coherency issues of ConcurrentDictionary but just its performance. For that matter I'm not sure if thread safety matters at all beyond making sure the whole thing doesn't explode in the nebulous way people do get twitchy about online.
|
|
#
?
Jan 10, 2019 01:01
|
|
|
So are you looking for a thread-safe, associative data structure for this? Is that how you're storing your pathfinding data? If so, what I'd be afraid of functionally is a race where a room gets cut off, but a route is generated to it in the middle of the data being update to cut it out of the paths. Edit: I'm just focusing on the functional aspects of this because that would do a lot to restrict what you could or couldn't do. Rocko Bonaparte fucked around with this message at 01:24 on Jan 10, 2019 |
|
#
?
Jan 10, 2019 01:17
|
|
|
This is the absolute best pathfinding tutorial I have found for a grid which is perfect for me. I'm just unsure about what to do about hard corners. I don't want people to assume they can move diagonally when there is a barrier on the corner, if there's no barrier then go hog wild of course. https://www.youtube.com/watch?v=KNXfSOx4eEE
|
|
#
?
Jan 10, 2019 03:11
|
|
|
This seems like a decision Unity is gonna regret. https://arstechnica.com/gaming/2019/01/unity-engine-tos-change-makes-cloud-based-spatialos-games-illegal/ It's obvious why they're doing it, they want to get in on that sweet cloud money, but this seems a bit heavy handed.
|
|
#
?
Jan 10, 2019 17:13
|
|
|
xzzy posted:This seems like a decision Unity is gonna regret. Yeah they went at it too hard, hopefully they pull back. Most people think they should have changed the terms to disallow future implementations but let current running (at LEAST) games continue to function. Then they could figure out what to do about games in development (maybe give them a year to release) then after that not allow it. Just out of the blue doing this is way too heavy-handed and is sure to bite them in the rear end. It makes everyone using Unity a bit worried that Unity could shut them down in an instant.
|
|
#
?
Jan 10, 2019 17:30
|
|
|
the way those terms are worded would also affect Rust and VRChat, no?
|
|
#
?
Jan 10, 2019 19:11
|
|
|
Why make the change at all? I don't deal with anything massively multiplayer so I'm unclear on why they changed this in the first place. Unity have a competing product or something?
|
|
#
?
Jan 10, 2019 20:06
|
|
|
Because cloud hosting is where the money is at now. The ToS language indicates Unity will let you continue to run Unity in the cloud, but you gotta negotiate a price with them.
|
|
#
?
Jan 10, 2019 20:08
|
|
|
Rocko Bonaparte posted:So are you looking for a thread-safe, associative data structure for this? Is that how you're storing your pathfinding data? If so, what I'd be afraid of functionally is a race where a room gets cut off, but a route is generated to it in the middle of the data being update to cut it out of the paths. Basically. Walkable status almost never gets changed during play so that isn't much of a concern. The constant updates are to the traversal cost which are just to encourage pathing route changes. Agents also repath every 0.5-1 second so an invalid path isn't held for very long. This is also why performance is the largest concern.
|
|
#
?
Jan 10, 2019 20:19
|
|
|
xzzy posted:This seems like a decision Unity is gonna regret. From what I can tell, this is being blown way out of proportion. It sounds like someone generalised their terms too much and what they were trying to target is what SpatialOS is offering: SpatialOS host Unity processes themselves in the cloud, running their own licenses. Those Unity processes take third-party code from SpatialOS clients. That third-party code was written by non-SpatialOS game developers potentially using free licenses of Unity, but benefit from SpatialOS's license. The alternative to that is that they offer some manner of SDK, and the non-SpatialOS game developers build a Unity application of their own using that SDK, then host it themselves in the cloud/wherever. The problem is that the actual hosting in the cloud/wherever is currently also being blocked, but it just sounds like an accident in wording it, not intentional money-grabbing.
|
|
#
?
Jan 10, 2019 20:32
|
|
|
Regardless of their intentions, Unity keeps stepping on PR rakes and it's gonna hurt them if they don't pay more attention to this stuff.
|
|
#
?
Jan 10, 2019 20:41
|
|
|
Unity keeps giving me reasons to be really glad I jumped ship a long time ago.
|
|
#
?
Jan 10, 2019 20:45
|
|
|
Yeah that's really unsettling.
|
|
#
?
Jan 10, 2019 20:55
|
|
|
xzzy posted:Because cloud hosting is where the money is at now. The ToS language indicates Unity will let you continue to run Unity in the cloud, but you gotta negotiate a price with them. I have to wonder if Unity is thinking of changing it's licensing terms and not charging developers by the seat and instead just trying to make money on cloud stuff. Seems hard to believe but they have been open sourcing it's new stuff and apparently much of their new engine code is now C# instead of C++.
|
|
#
?
Jan 10, 2019 21:21
|
|
|
Stick100 posted:Yeah they went at it too hard, hopefully they pull back. I am not a lawyer but you agree to ToS at the point that you start using unity. Those ToS that you agreed to should remain in place until you agree with a new ToS. I imagine Unity might be able to prevent you from using a new version of Unity without agreeing to the new ToS but otherwise couldn't in development/released games continue to do what they're doing?
|
|
#
?
Jan 10, 2019 23:58
|
|
|
Nolgthorn posted:I am not a lawyer but you agree to ToS at the point that you start using unity. Those ToS that you agreed to should remain in place until you agree with a new ToS. I imagine Unity might be able to prevent you from using a new version of Unity without agreeing to the new ToS but otherwise couldn't in development/released games continue to do what they're doing? You'll note they said the games would continue to run for the time being. I bet what they can't do is update the engine they're running, because that would require agreeing to the new ToS. It's like being stuck using Windows 7 -- you may be okay for now but eventually your poo poo's gonna break because you can't update to a more recent OS.
|
|
#
?
Jan 11, 2019 00:01
|
|
|
Red Mike posted:That third-party code was written by non-SpatialOS game developers potentially using free licenses of Unity, but benefit from SpatialOS's license.
|
|
#
?
Jan 11, 2019 02:38
|
|
|
Unity put up a blog post trying to clarify this but it really isn't helping me understand anything. The plain language of the TOS makes it pretty clear that just hosting a server on a VPS would now be a violation without explicit permission from Unity, but in the blog post they say that is only true if the host is including "their own additional SDK" which is incredibly vague and not helpful. I've been playing around with some toy games in Unity but it looks like it might be time to give ue4 another look.
|
|
#
?
Jan 11, 2019 02:48
|
|
|
My hot take: the ToS basically doesn't matter until you get Unity angry. And if you make them really angry, they can just change the ToS anyway. And if you don't make them angry, they're not gonna take action against ToS violations. So the ToS is basically just a guideline about what might make them angry. I don't think any games are in danger -- I think they learned from the PR disaster that happened today.
|
|
#
?
Jan 11, 2019 03:21
|
|
|
Given what they let slip in the blog post, it seems like they've been quietly shaking down cloud companies (playfab, etc.) and improbable told them to take a hike because there's not an actual requirement in the EULA that they pay. So now there is one. I suspect that unity didn't want anything in the EULA because it would cause people to say, "hey it's weird that you're charging all these cloud hosting companies money just to provide unrelated platforms for your engine".
|
|
#
?
Jan 11, 2019 05:08
|
|
|
Suspicious Dish posted:My hot take: the ToS basically doesn't matter until you get Unity angry. And if you make them really angry, they can just change the ToS anyway. And if you don't make them angry, they're not gonna take action against ToS violations. So the ToS is basically just a guideline about what might make them angry. Revoking licenses for retroactively-applied rule changes is a big deal.
|
|
#
?
Jan 11, 2019 05:49
|
|
|
|
| # ? May 11, 2024 23:39 |
|
|
FuzzySlippers posted:Basically. Walkable status almost never gets changed during play so that isn't much of a concern. The constant updates are to the traversal cost which are just to encourage pathing route changes. Agents also repath every 0.5-1 second so an invalid path isn't held for very long. This is also why performance is the largest concern. Okay so compromises like that do let you get away with more, although having only one writer to multiple readers is the more important thing. I can't see a problem with using ReaderWriterLockSlim but I am surprised the ConcurrentDictionary is being so bad. On the other hand, it is also guaranteeing atomicity on multiple writers so it would likely be slower regardless. That must be some intense pathfinding to calculate that you have to sweat this. Have you checked the actual number of operations you are performing when calculating routes? I would be worried I botched my heuristics and am actually calculating (recalculating?) my entire domain.
|
|
#
?
Jan 11, 2019 07:28
|
|