|
SynthOrange posted:http://unity3d.com/5 That 'low monthly payments' line seems a bit ironic now.
|
#
¿
Mar 21, 2014 00:19
|
|
|
|
| # ¿ May 19, 2024 14:46 |
|
|
The Atomic Man-Boy posted:I'm just getting into building my own game. There are lots of character models and animation packs on the Asset Store that you can use for placeholders, or you could try something like MakeHuman to make a more customised character model. With the ubiquity of Mecanim it's not terribly hard to find bipedal animations that you can use on any relatively standard human-shaped rig, but if you're thinking about a less than standard-shaped character you'll likely have to make everything for it from scratch. Personally I'd feel that creating and animating a skeleton first, and retrofitting a character model later, is a bit of a backwards workflow - normally I'd make the mesh first, then create a skeleton that fits it and animations that work with that etc. If you're going for standard human proportions though, I guess it's not necessarily a big deal. Things like having an allowance for different faces and armour etc are not something I'd worry about at the skeletal level; that'd be all in the mesh.
|
|
#
¿
Apr 4, 2015 13:41
|
|
|
poemdexter posted:I was thinking about HTR when I wrote my response and I agree with you. At most, I've worked with two developers and an artist and we already had a workflow agreed upon to help with some of the Unity quirks you mentioned. A team of your size would probably be like trying to herd cats to keep your Unity project in a state that can compile. TFU had upwards of 100 people working in Unity on it. We had a LOT of tech art scripts and importers and Perforce voodoo and automated build processes running constantly to keep everything together. From my dumb artist perspective, it worked out okay... mostly. (Then again, TFU died a horrible firey mass-layoffs death - but I don't think Unity had much to do with that.)
|
|
#
¿
Jul 20, 2015 15:29
|
|
|
I LOVE FILLING OUT SURVEYS so I'm going to respond to this one even though I'm an artist and not really a coder. I learned enough Javascript to cobble together little things-that-aren't-quite-games in Unity though so please don't run me out of this subforum. 1. Do you use a particular framework to develop your games, or do you roll your own engine? If the former, which one(s)? If the latter, what drove the design and development of that engine? I generally use Unity, because Unity is nice and I understand Unity and C# is not completely terrifying and there are lots of variously-useful things for free/cheap on the Unity Asset Store. I tried UE4 one time, and while the end result was pretty and I like their shader editor I hit a brick wall of how-do-C++/blueprints-are-confusing when it came to making things actually happen. Now that Unity has PBR shaders, I'll stick with that. 2. Do you have any formal training in game development, such as a college degree, or are you primarily self-learned? I have a BA(Hons) in Computer Games Art. I learned the fundamentals at uni(it was more useful for networking/gradually learning to adult really), and the rest has been learning on the job or in my own time. The degree did very briefly cover Actionscript at one point, but tbh all my code knowledge has come from Codecademy/hanging out with programmers. 3. Do you work in the gaming (as in video games, not gambling) industry? If not, would you want to work in the gaming industry? Yes. I've worked in games for about six years and can't really imagine doing anything else, career-wise. 4. Have you studied design theory in the context of game design? If so, how have you incorporated it into your games? What resources have you used? I read a book about level design one time? I don't consider myself a designer, or at least not a designer of gameplay mechanics. Everything I know about game design I've gathered from a) experience making and playing games and b) talking to designers. The things I make by myself aren't exactly games, but when it comes to UI design at least I look at games I've played and incorporate the ideas I think worked best. 5. Are your games open source? If not, are they at least publicly available on version control sites like Github? No. No? Nobody needs to see my 6. Have you studied the source code or design documents of other games, e.g. the Quake 3 source code? If so, what have you learned from doing so? Code/design documents no, but I do love delving into the guts of games I've enjoyed(in particular World of Warcraft and Dragon Age: Inquisition) to see how their assets are put together. I learned a lot about customisation systems and how to make modular character assets from WoW. 7. What do you feel is the largest problem (or problems) in game dev these days? What do you feel could help alleviate these problems? This is a real big question cause 'game dev' is such a huge church - from tiny indies trying to get their games noticed on crowded mobile/PC marketplaces, to AAA juggernauts running on insane budgets and production schedules that make them intensely averse to creative risk-taking. So, discoverability and conservativism are definitely problems in their particular areas. I have no idea how you solve the discoverability problem, but I'd love to see more studios turning away from chasing AAA million-dollar cannot-afford-to-fail projects and making something like... AA games? Big but not insanely big, with more breathing space to explore underserved niches and experiment with ideas. 8. Do you follow a design and iteration process, formalized or otherwise, for developing your games? I write down ideas and I draw pictures of the ideas and I keep the pictures I like best and then I make the pictures into a thing. So... not really, no.
|
|
#
¿
Sep 12, 2015 22:58
|
|
|
The Atomic Man-Boy posted:So I've decided to go from being a hobbyist to making a full fledged product. It's a hack-n-slash game targeted toward PC, and possibly console if it comes to fruition. As someone who relatively recently made a set of assets for modular character customisation for a Unity game, Unity can definitely do this just fine, but then so can UE4. So I wouldn't base my choice of engine on that, because either will do the job. And they both support more mesh formats than just .obj, thank god - obj doesn't support anything like skeletons, animation or skinning information, so you'd be a bit SOL for character art if that was all you could use! It depends a bit on what kind of art style you want to go for, but the way I usually go about it is to create the character base mesh, and all of the different clothing/armour pieces, all as separate meshes skinned to the same skeleton. Export them to your engine of choice as .fbx files and you should be able to load different items onto the character without too much trouble. As long as they share the same rig, adding more pieces as you go along shouldn't be an issue.
|
|
#
¿
Dec 19, 2015 13:31
|
|
|
Jsor posted:For 3D modelling for characters in games is it more common to sculp a high poly model and then retopo the finished product into a saner lower-poly version, or model from the ground up into your poly count with, e.g., box modelling or whatever? It varies, but generally we start with the high-poly sculpt - basing it off poly-modelled basemeshes where needed - and retopo afterwards.
|
|
#
¿
Oct 17, 2016 09:47
|
|
|
I use git at work and it loving sucks and the amount of time we as a team lose to wrangling git messes that artists and designers have managed to get into because git is incredibly difficult to understand if you're not especially technically-minded is unreal. We use Perforce for handing our art source assets and almost never have problems with that.
|
|
#
¿
Jan 19, 2019 10:12
|
|
|
The way we(small programmer-heavy team) do it is all our source art assets - concept art, Maya scenes, PSD texture files, Substance stuff, etc - go in Perforce, which the artists use and the programmers never have to think about and it's all smooth sailing except for that one time it turned out we had somehow disabled exclusive checkouts and I lost a bit of work but I had a local backup so it was fine. The actual game files, exported engine-ready assets, code, data files etc are all in git, because programmers like git and presumably they have their reasons, I wouldn't know. This unfortunately means that artists have to interact with git to pull and build the latest version of whatever feature branch we're currently making assets for, to change branches, to make changes to data files, and to push our work when it's ready. We have some scripts to automate some of these processes but can't completely avoid having artists touch git, and that means sometimes you end up having to send in a programmer to unsnarl a sobbing artist from the hideous thorny brambles of a huge merge conflict.
|
|
#
¿
Jan 21, 2019 14:50
|
|
|
limaCAT posted:Without design documents how do designers communicate their intentions and wishes to developers and artists? Slack, email(for that one programmer who refuses to use Slack), JIRA task descriptions, cryptic post-its...
|
|
#
¿
Aug 22, 2019 17:34
|
|
|
Oh my god, I just realised the 'how to use computer: this is a mouse. this is a file. what is a hard drive' classes we slept through at school because we already knew all of that poo poo might be actually valuable now that nobody has a desktop machine at home anymore. I bet they don't do them anymore.
|
|
#
¿
Apr 28, 2024 12:32
|
|
|
|
| # ¿ May 19, 2024 14:46 |
|
|
I bought Zookeeper DX for 70p in 2011 and it remains the only game on my phone. Monument Valley was good too in fairness.
|
|
#
¿
Apr 30, 2024 12:53
|
|