|
Gearman posted:They're not just used in animation. That is one of their bigger use cases but it's disingenuous to say that they're only needed for implementing 3D animation from scratch. For example, all of the major VR HMD APIs use quaternions. You're also very likely to run in to them if you're working with AR, such as Google's Tango or Apple's ARKit. Few people are going to be implementing VR from scratch either. So easy to screw that up and  Just using an existing engine / library that has quaternions math methods to deal with them for you is pretty straightforward. Shalinor posted:git is a flaming pile of garbage Heretic! Zaphod42 fucked around with this message at 05:01 on Oct 6, 2017 |
#
?
Oct 6, 2017 04:48
|
|
|
|
| # ? May 31, 2024 20:26 |
|
|
Shalinor posted:If it makes you feel any better, git is a flaming pile of garbage for other reasons and we abandoned it for Unity's thing. Perforce or MS Teams was our fallback tho if that hadn't worked out. What's even wrong with perforce? I've been using it my whole career and I'm pretty happy with it. I thought the main complaint against it was the setup required to run a server and all that.
|
|
#
?
Oct 6, 2017 04:58
|
|
|
Triarii posted:What's even wrong with perforce? I've been using it my whole career and I'm pretty happy with it. I thought the main complaint against it was the setup required to run a server and all that. If you don't have streams setup, there is no way to setup lightweight branches with Perforce. Perforce also has no support for performing a bunch of local commits to work iteratively, quickly. Shelves can be OK at this, but require you to put a lot of effort into managing your outstanding changelists. Perforce also does not play well with offline work. Reconcile offline work kind of works, but not super well. There seems to be many more code review tools that support Git than those that support Perforce. Perforce also can get expensive, you have to pay for the licenses for bigger teams. Perforce also scales in hiccups that can get frustrating, when you hit the capacity of your current server and aren't financially ready to move up a tier. A lot of diligence for setting up a backup system that can actually be used to recover data is necessary for Perforce, where-as if you configure Git correctly, everyone's local copy has a complete backup. For projects with a long history, Perforce can be more beneficial to not have all that bloated history on your machine, instead leaving it up on the central server, but I'm sure Git has some configuration for dealing with this. I still prefer Perforce for projects that have a lot of team members. File locking is necessary when dealing with large numbers of files that aren't really human merge-able. There are Git plugins for file locking, but they kind of remove a lot of benefits of Git by having a central server managing these locks.
|
|
#
?
Oct 6, 2017 05:59
|
|
|
I hear some teams use svn and I wonder how viable it is these days as a middle ground between p4 and git.
|
|
#
?
Oct 6, 2017 06:06
|
|
|
File locking is basically mandatory when working with assets in UE4. Coming from a couple of years working with git outside the games industry, P4 is pretty garbage for managing source code, but it's basically the only version control that's even remotely reasonable to use for something with as many non-mergeable assets as UE4.
|
|
#
?
Oct 6, 2017 06:15
|
|
|
[quote="“Chainclaw”" post="“477105145”"] If you don’t have streams setup, there is no way to setup lightweight branches with Perforce. Perforce also has no support for performing a bunch of local commits to work iteratively, quickly. Shelves can be OK at this, but require you to put a lot of effort into managing your outstanding changelists. Perforce also does not play well with offline work. Reconcile offline work kind of works, but not super well. There seems to be many more code review tools that support Git than those that support Perforce. Perforce also can get expensive, you have to pay for the licenses for bigger teams. Perforce also scales in hiccups that can get frustrating, when you hit the capacity of your current server and aren’t financially ready to move up a tier. A lot of diligence for setting up a backup system that can actually be used to recover data is necessary for Perforce, where-as if you configure Git correctly, everyone’s local copy has a complete backup. For projects with a long history, Perforce can be more beneficial to not have all that bloated history on your machine, instead leaving it up on the central server, but I’m sure Git has some configuration for dealing with this. I still prefer Perforce for projects that have a lot of team members. File locking is necessary when dealing with large numbers of files that aren’t really human merge-able. There are Git plugins for file locking, but they kind of remove a lot of benefits of Git by having a central server managing these locks. [/quote] Basically all of this. I'm used to creating and switching between a bunch of branches for speculative work. Looks like doing something similar with p4 is going to take a lot more effort (== time == why bother). Really painful to me as it means it's difficult to work on multiple issues at a time or jump to something when someone's hair is on fire and decided to bang their head on my desk. The only issue I see with it is binaries that are subject to change (eg all art). Pretty sure that's the only reason we're using it. Maybe git-lfs et al aren't good enough, but even then I'd almost prefer using multiple VCS than adopting a worse workflow. Does anyone have experience with git-p4? I've used git-svn successfully in the past...
|
|
#
?
Oct 6, 2017 11:20
|
|
|
Perforce also goes from inexpensive (free) at <=20 instances to very expensive.
|
|
#
?
Oct 6, 2017 11:22
|
|
|
Zaphod42 posted:Few people are going to be implementing VR from scratch either. So easy to screw that up and If you do anything with the virtual camera or do anything with hit testing you're likely going to run into them, even using something like Unity. I ran in to them just the other day working on improvements to our ARKit and ARCore apps. I'm not suggesting that anyone be a pro at dealing with them, but they're much closer to the surface in all kinds of dev nowadays, so it's good to at least have a fundamental understanding of what they are.
|
|
#
?
Oct 6, 2017 13:05
|
|
|
[quote="“blastron”" post="“477105447”"] File locking is basically mandatory when working with assets in UE4. Coming from a couple of years working with git outside the games industry, P4 is pretty garbage for managing source code, but it’s basically the only version control that’s even remotely reasonable to use for something with as many non-mergeable assets as UE4. [/quote] Basically all this. I just swapped back to straight game dev from doing first party middleware. And after 5 years of git I hate having to deal with p4. My workflow is way way multi-tool. So the fact that I have to stop and p4 edit files before I want to vi them in an OS X shell, or have to reconcile here/there/everywhere pisses me off to no end. The best part of it is I brought over one of my guys who's never used p4 and spent their entire professional career on git, and his daily frustration over smashing his head into the wall is amusing. (Yesterday's: So, I edited this file, then I had to move it so I moved it in finder, and marked the new location for edit, then later I reconciled and the old was marked for delete, I later saw the rename/move option, so how do I clean up the change list without losing my changes so I can do the rename/move? ) EDIT: I do agree that the file locking is so mandatory in many cases. and I really wish git LFS wasn't a flaming piece of poo poo. That is the best thing p4 has going for it. But for doing actual software development / source code management p4 is the worse. Hughlander fucked around with this message at 13:31 on Oct 6, 2017 |
|
#
?
Oct 6, 2017 13:28
|
|
|
I think the issue basically comes from trying to make one version control system handle two very different things (code and binary assets). That and engines really need to get away from binary formats for metadata a lot of people will want to change. Unity supposedly added file locking to Git via their own plugin, but it only works with GitHub because 
|
|
#
?
Oct 6, 2017 14:50
|
|
|
Hughlander posted:(Yesterday's: So, I edited this file, then I had to move it so I moved it in finder, and marked the new location for edit, then later I reconciled and the old was marked for delete, I later saw the rename/move option, so how do I clean up the change list without losing my changes so I can do the rename/move? ) If you have a file open for edit, you can just do a move on it and it'll do it automatically. If you have a file open for add (which is more likely given the description of your steps), there's a flag which you can use to match existing add/delete operations into a "move" (move/delete+ move/add pair). Or you can revert -k to keep your changes and then do the move. Perforce isn't that hard, really. E: that said, it's obviously not without its pitfalls, but then, what source control ever is? The main "hassles" I had to deal with all involved merging UE4 updates - we had licensee VPN access, not public git. So integrations involved deleting our upstream UE4 directory, dropping the new version in, then reconciling. Hurdle #1: Our fearless leader did not initially populate the game depot from a UE4 branch. So any files that were "new" to source control had to be resolved without a base. Hurdle #2: It turns out that perforce has a mostly undocumented but terribly inconvenient feature in this case: when reconciling, it looks at adds and deletes using fuzzy logic and tries to pair matches into move operations. But UE4 is massive and standardized with that lots of skeleton files end up similar or identical, and unrelated files end up getting matched by this feature. We went through 2-3 integrations before these matches started bubbling to the surface and I could disable the matching functionality before it got worse. Hurdle #3: Shelves look and feel a lot like "local" branches, down to the resolve terminology when unshelving, but this is treacherous. I once shelved a fully resolved 4.11 integrate we decided not to go forward with, and had to integrate 4.13 after all. So I unshelved 4.11 first before integrating 4.13, hoping that'd spare me from resolving 4.11 again. But any files that were already resolved for an operation (add/delete/edit) but had that operation changed by integrating 4.13 silently failed to resolve because perforce does not support that in a pending changelist... But it does support it while merging a new changelist. In this case, both integrates would have behaved the same in git and this was absolutely a painful mistake on my part. Jan fucked around with this message at 16:08 on Oct 6, 2017 |
|
#
?
Oct 6, 2017 15:41
|
|
|
Jan posted:If you have a file open for edit, you can just do a move on it and it'll do it automatically. Oh I know this, I started with p4 in 1999. I'm just pointing out the foibles of someone who has worked with git his entire professional careers being thrown into p4 last week. The steps described were exactly what he did: code:code:Biggest problem I personally have now is that the typemap was made ridiculously restrictive. Far too many files marked exclusively checked out than should be. Like .gradle is exclusively checked out.
|
|
#
?
Oct 6, 2017 16:32
|
|
|
As an artist screw git and its weird rear end made up illogical vocabulary forever.
|
|
#
?
Oct 6, 2017 17:09
|
|
|
leper khan posted:Basically all of this. I'm used to creating and switching between a bunch of branches for speculative work. Looks like doing something similar with p4 is going to take a lot more effort (== time == why bother). Really painful to me as it means it's difficult to work on multiple issues at a time or jump to something when someone's hair is on fire and decided to bang their head on my desk. I do still miss P4Win though, RIP running man cursor.
|
|
#
?
Oct 6, 2017 17:12
|
|
|
Game jobs megathread: gitHub or gitGud
|
|
#
?
Oct 6, 2017 17:22
|
|
|
There's nothing like watching people fail over and over and over on some gameplay that you thought was going to be easy.
|
|
#
?
Oct 8, 2017 20:46
|
|
|
baby puzzle posted:There's nothing like watching people fail over and over and over on some gameplay that you thought was going to be easy. Don't hate the player, hate the game (designer). 
|
|
#
?
Oct 8, 2017 21:58
|
|
|
GC_ChrisReeves posted:Don't hate the player, hate the game (designer). B-b-but that's me.
|
|
#
?
Oct 8, 2017 22:54
|
|
|
If you aren't in a constant state of self-loathing you might not be doing game development right.
|
|
#
?
Oct 9, 2017 19:20
|
|
|
*sob* our company is running JIRA, Confluence, HP Application Lifecycle Management and basecamp all at the same time on a per-project basis. kill me. Also part of the network just got hosed up by ransomware so none of it works. And neither does the source repository. *barf*
|
|
#
?
Oct 24, 2017 02:53
|
|
|
JIRA works pretty well for the most part. Confluence on the other hand is a mess.
|
|
#
?
Oct 24, 2017 02:56
|
|
|
I hate Confluence. I'm not even sure what else it does aside from act as a doubly confusing wiki but it makes documentation even less likely by being super opaque and overly complicated.
|
|
#
?
Oct 24, 2017 03:26
|
|
|
Zaphod42 posted:JIRA works pretty well for the most part. Confluence on the other hand is a mess. It is my experience that JIRA scales poorly. Diddo Testrail. Confluence is even worse. I'm honestly stunned that this is the best the industry can offer because these products are mediocre at best. I swear their existence is being perpetuated by middle management that insists on implementing these toolsets because, 'they are the industry standard!'. It's the worst kind of vicious cycle. Canine Blues Arooo fucked around with this message at 03:56 on Oct 24, 2017 |
|
#
?
Oct 24, 2017 03:42
|
|
|
mutata posted:I hate Confluence. I'm not even sure what else it does aside from act as a doubly confusing wiki but it makes documentation even less likely by being super opaque and overly complicated. I will go to my grave yelling about Google Docs/Sheets/etc. This is the right answer for collective documentation, dangit. Shalinor fucked around with this message at 05:48 on Oct 24, 2017 |
|
#
?
Oct 24, 2017 05:44
|
|
|
[quote="“Canine Blues Arooo”" post="“477679826”"] It is my experience that JIRA scales poorly. Diddo Testrail. Confluence is even worse. I’m honestly stunned that this is the best the industry can offer because these products are mediocre at best. I swear their existence is being perpetuated by middle management that insists on implementing these toolsets because, ‘they are the industry standard!’. It’s the worst kind of vicious cycle. [/quote] I'm not going to claim jira is good, but it handles large numbers of projects rather well. Scale isn't typically the problem I have with it.
|
|
#
?
Oct 24, 2017 06:02
|
|
|
This is why you solo dev from home and make tiny games. My entire workspace is various untitled text documents scattered across very organised something called New Folder (13)
|
|
#
?
Oct 24, 2017 06:06
|
|
goku i won't do what u tell me
|
Never once have I sat at my desk thinking to myself, "Man if only Jira were less confusing, then we would be able to make a game."Synthbuttrange posted:Also part of the network just got hosed up by ransomware so none of it works. And neither does the source repository. Hmm. I would have some serious second thoughts about working at a company where this is possible.
|
|
#
?
Oct 24, 2017 06:24
|
|
|
bluuuuurh. Oh well at least it's gotten fixed since last week... mostly. Stuff is still up and down though. One thing better collaboration tools wont help: A project director that wants different things depending from moment to moment and is confused when you have his older jira entries showing that you've provided exactly what he asked for. 
|
|
#
?
Oct 24, 2017 06:54
|
|
|
Man if you don't like Confluence I kind of understand (but want to know what you use). If you don't like Jira I'd love to know what you recommend. It might be because I went Jira -> Cherwell -> Jira but Jira makes me pretty happy. (don't ever use Cherwell it is garbageware for MSPs)
|
|
#
?
Oct 24, 2017 10:40
|
|
|
Don't use Confluence, love yourself and use Google Docs/Sheets instead.
|
|
#
?
Oct 24, 2017 11:07
|
|
|
Any goons at Ubisoft Toronto? Saw a couple positions open that I'm actually somewhat qualified for, so any help with/advice on the process would be spectacular.
|
|
#
?
Oct 24, 2017 15:07
|
|
|
leper khan posted:I'm not going to claim jira is good, but it handles large numbers of projects rather well. Scale isn't typically the problem I have with it. Oh, it definitely handles a lot of projects pretty well. It however does not handle big projects very well.
|
|
#
?
Oct 24, 2017 17:51
|
|
|
I like confluence at work, but we use it as a wiki, and not a place design docs
|
|
#
?
Oct 24, 2017 18:20
|
|
|
Bug tracking and project management are inherently unfun except to a small group of people who inevitably end up in production, which means most people hate the software and processes attached to those activities. JIRA has a fine interface for writing bugs, but terrible for managing large volumes of them, and non-existent you're-on-your-own reporting tools. Also, at Blackbird we are hiring a lot. https://blackbirdinteractive.com/jobs/
|
|
#
?
Oct 25, 2017 01:28
|
|
|
EgonSpengler posted:JIRA has a fine interface for writing bugs, but terrible for managing large volumes of them, and non-existent you're-on-your-own reporting tools. Maybe my memory is a little busted here, but I think default JIRA's bug writing window is a 600 x 900 screen child window that allows you to see about 4 fields before you have to start to scroll and does not let you interact with it's parent window until you close the child window. That is awful beyond awful and screams to me that the people writing this software aren't dogfooding their product, or they just don't care...
|
|
#
?
Oct 25, 2017 08:07
|
|
|
Open a new tab on the create button to avoid quick create and get a nice beefy tab. There's uh, there's a lot wrong with JIRA though.
|
|
#
?
Oct 25, 2017 09:21
|
|
|
All I want from JIRA is an easy way to handle tickets that need to be in more than one team's sprint.
|
|
#
?
Oct 29, 2017 16:35
|
|
|
Leif. posted:All I want from JIRA is an easy way to handle tickets that need to be in more than one team's sprint. If they allowed sub-tasks to appear in a sprint other than the parent, that'd be marvellous. But while aggregating time estimates from sub-tasks to the parents in planning view still proves too difficult for Atlassian to bother with, I can't see them bothering.
|
|
#
?
Oct 29, 2017 20:19
|
|
|
I am looking for a game journalist or designer who can do a mock review/in-depth playtest of a PC game. I've already done a bunch of playtesting of the very beginning of the game, but now I want something more in-depth.
|
|
#
?
Nov 1, 2017 23:03
|
|
|
|
| # ? May 31, 2024 20:26 |
|
|
baby puzzle posted:I am looking for a game journalist or designer who can do a mock review/in-depth playtest of a PC game. I've already done a bunch of playtesting of the very beginning of the game, but now I want something more in-depth. They charge money for their services, but this group offers that service: http://www.eedar.com/ We've used them, and they deliver pretty good results.
|
|
#
?
Nov 2, 2017 06:24
|
|