|
Fashionable Jorts posted:Sorry in advance if this question has been asked a dozen times already. I'm looking at working on a game idea I've had rolling around in my head for some time now, a third-person shooter with some rpg elements. I know practically nothing about coding, but am currently going through some tutorials. If you are a beginner Unity will be way more useful as a starting point. If you are not a programmer I'd recommend postponing learning C++ until you get the hang of another programming language. It's not friendly, has many gotchas, and the build system (the process that turns your code into executable files) is arcane. Luckily for you Unity uses C# which is gentle enough as a starting point and capable enough to do most of your tasks. (You still need to learn C++ at some point but for better results you don't want to do it while also learning how to program). If you are feeling adventurous you can also try Godot which is free and open source. I only used it for 2D stuff and it's been perfect for that but I hear the 3D features have some rough edges. Godot can use both C# and its own language called GDScript which has some similarity to Python and is easy enough to learn for beginners. Check out these youtube channels: Brackeys (they recently decided to stop updating the channel but the content is still relevant): https://www.youtube.com/channel/UCYbK_tjZ2OrIZFBvU6CCMiA GDQuest (if you would like to explore Godot): https://www.youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ
|
#
?
Sep 21, 2020 00:26
|
|
|
|
| # ? May 13, 2024 19:41 |
|
|
Raenir Salazar posted:
Now all you have to do is pick a blue line and there's your mountain ridge! With an l-system of course. 
|
|
#
?
Sep 21, 2020 00:56
|
|
|
xzzy posted:Now all you have to do is pick a blue line and there's your mountain ridge! With an l-system of course.  That isn't my problem right now!
|
|
#
?
Sep 21, 2020 01:18
|
|
|
That voronoi stuff reminds me. I saw on Twitter recently someone posted an animated gif of a prototype of a isometric 2D game with mining & terrain destruction. And the destruction looked an awful lot like it was governed by a voronoi algorithm. And I was trying to brainstorm how the tiling system would work with that and how they accomplished it. Is it possible to have 2D tiling over an irregular grid like voronoi?
|
|
#
?
Sep 21, 2020 01:29
|
|
|
xgalaxy posted:That voronoi stuff reminds me. I saw on Twitter recently someone posted an animated gif of a prototype of a isometric 2D game with mining & terrain destruction. And the destruction looked an awful lot like it was governed by a voronoi algorithm. And I was trying to brainstorm how the tiling system would work with that and how they accomplished it. Voronoi are usually convex polygons, so I imagine you can use some bitwise masking, i am not 100% if they are expected to have n-many sides or if that's needed but as long as you have X neighbours of Tile Y set it to be some other tile based on a formula.
|
|
#
?
Sep 21, 2020 01:32
|
|
|
Irregular faceted marching cubes looks kinda voronoi-ish to me or maybe just have a 2D grid and voronoi the damage. Either just purely visual or you change voxel info in the MC grid based on a voronoi over the top. So you hit something and it checks the voronoi and then does damage to every cube in the shape. Some kind of faking it would seem easier than doing it for real.
|
|
#
?
Sep 21, 2020 01:48
|
|
|
xgalaxy posted:That voronoi stuff reminds me. I saw on Twitter recently someone posted an animated gif of a prototype of a isometric 2D game with mining & terrain destruction. And the destruction looked an awful lot like it was governed by a voronoi algorithm. And I was trying to brainstorm how the tiling system would work with that and how they accomplished it. Not sure if this is what you're talking about, but Townscaper uses an underlying Voronoi "grid" for its building placement.
|
|
#
?
Sep 21, 2020 01:51
|
|
|
roomforthetuna posted:(If you *do* already have a programmer way of thinking of things then Unity will keep getting in your way and is really annoying, and you should choose Godot even for 3D which still isn't its forte.) I have to strongly disagree with this, I'm a pure programmer type and I have no issues with Unity at all. xzzy posted:Unity also has that critical mass where you can google search almost every problem and find the fix. Agree on these xzzy posted:But I think the suite is a disaster, they relentlessly hype up amazing new features that are in beta for two more years and don't work with any of their other new features. So it's really drat hard to figure out best practices. This I also agree with, its not a huge deal but it is a thing with Unity. But probably exists on Unreal too to some extent. Zaphod42 fucked around with this message at 02:08 on Sep 21, 2020 |
|
#
?
Sep 21, 2020 02:05
|
|
|
Thanks for all the info! I think I'll go with Unity simply because theres ten times the number of tutorials available compared to Unreal. Godot seems good for people who know what they're doing, but theres really not much support or many resources for it.
|
|
#
?
Sep 21, 2020 02:21
|
|
|
Fashionable Jorts posted:Godot seems good for people who know what they're doing, but theres really not much support or many resources for it. Yeah I spent all day today trying to make a very simple low-poly not-even-transparent water shader in godot's custom shader language. I wouldn't have known how to do it anyway and the finished product is admittedly much easier to read than any GLSL example, but there really wasn't anything out there.
|
|
#
?
Sep 21, 2020 02:51
|
|
|
Zaphod42 posted:I have to strongly disagree with this, I'm a pure programmer type and I have no issues with Unity at all. It's weird that Godot isn't, since a Python-like language should feel worse than C#, but my point wasn't not about the programming tools, it's about *everything else* Unity does. It tries pretty hard to push you into a drag-and-drop mindset, which doesn't fit the way I think about things at all. Godot feels more like it's offering you those kinds of features, rather than forcing them on you. And again, that view might be out of date, maybe Unity is less pushy in its opposition to code-generated content now than it was a few years ago. (And to be clear, it's not that you *couldn't* do code-generated content with Unity, it just felt like it hated you for trying.)
|
|
#
?
Sep 21, 2020 06:01
|
|
|
There's absolutely nothing stopping you from using unity to build your game for various targets and otherwise ignore it. I think it's pretty common for commercial Unity devs. I think finishing a game is the hardest thing to learn in game dev. Anything that helps make that more likely should be embraced. Few solo /tiny team ue4 games have been made. If you go by numbers nothing really compares to Unity in tiny teams and finishing games. If you don't want Unity I'd think more about rpg maker or game maker or similar engines. People have been using them to crank out games for a long time and some have made incredible games within their constraints. Don't make your dream game make something small and clever.
|
|
#
?
Sep 21, 2020 06:45
|
|
|
roomforthetuna posted:Maybe I meant more specifically "if you have an old, crotchety, C++ programmer way of thinking of things then Unity will be annoying". This doesn't grok for me. Even working in C++, if you're a smart dev, you're going to program tools and then let other people use those tools you made in C++ to drag and drop to build the levels. That's how AAA games got made in the old days and how they are now. Doing everything hard-coded isn't C++, that's just... I'm tempted to say bad practice. Isn't Unreal also "drag and drop" ? Just because you're working in C++ doesn't mean you store everything in the .cpp or .h files, you can have C++ read some kind of serialized level data same as any language. Right? I'm not entirely sure what you mean by "code-generated content". You can definitely do procedural stuff in Unity. FuzzySlippers posted:I think finishing a game is the hardest thing to learn in game dev. ... Don't make your dream game make something small and clever. Yeah, wisdom. Back in college, writing games from scratch, I'd spend months just to get basic poo poo rendering. If you want to actually make games, especially as a solo dev, don't work on game engines or fancy lighting systems or cutting edge this or that, just work on the game part. Only do what is essential for that game play to work. You can spend your time making game engines or you can spend your time making games. Also why if you want to get good at game design its a good idea to work on board games or D&D content, because you can test and iterate so much faster than things where you have to code and compile and test. Zaphod42 fucked around with this message at 09:06 on Sep 21, 2020 |
|
#
?
Sep 21, 2020 09:02
|
|
|
roomforthetuna posted:Maybe I meant more specifically "if you have an old, crotchety, C++ programmer way of thinking of things then Unity will be annoying". FWIW I agree with this 100% and I couldn't stand unity, thought godot was slightly better, but I've dropped both for writing my own stuff in a text editor. I'm not particularly old or crotchety and I don't know c++ but I just really prefer to work and think in terms of text files in a tree with no other interface.
|
|
#
?
Sep 21, 2020 17:20
|
|
|
The Caves of Qud "Unity port" initially consisted of building the entire CoQ executable into a C# library, then making a Unity scene with a single gameobject that, on awake, invoked the library's "run" function. This worked fine for getting CoQ to platforms other than Windows. I assume there's been a fair amount of iteration since then, but it wouldn't surprise me if Caves of Qud's implementation still looks nothing like a "normal" Unity project.
|
|
#
?
Sep 21, 2020 17:54
|
|
|
TooMuchAbstraction posted:The Caves of Qud "Unity port" initially consisted of building the entire CoQ executable into a C# library, then making a Unity scene with a single gameobject that, on awake, invoked the library's "run" function. This worked fine for getting CoQ to platforms other than Windows. I'm working on a (AAA) game right now that has all the game logic in a giant, codegen heavy C++ DLL that's linked in to a Unity project. It's a mess.
|
|
#
?
Sep 21, 2020 20:16
|
|
|
I heard a lot of Asian devs do most of their game logic in Lua (for whatever reason, bleh Lua syntax) so they mostly use Unity as just a big wrapper around that. Seems to be working out for them.
|
|
#
?
Sep 21, 2020 22:30
|
|
|
TooMuchAbstraction posted:The Caves of Qud "Unity port" initially consisted of building the entire CoQ executable into a C# library, then making a Unity scene with a single gameobject that, on awake, invoked the library's "run" function. This worked fine for getting CoQ to platforms other than Windows. This is how Doom works now.
|
|
#
?
Sep 21, 2020 22:42
|
|
|
How does that work with rendering and OS-specific calls? Don't you need to get those components from Unity in order for multi OS support to work?
|
|
#
?
Sep 21, 2020 22:52
|
|
|
Polio Vax Scene posted:How does that work with rendering and OS-specific calls? Don't you need to get those components from Unity in order for multi OS support to work? The game I'm working on basically uses Unity for anything that interacts with the user in any way, while the C++ DLL does the game simulation. So there's lots of data driven/codegen'd glue between the DLL and the Unity side to, say, trigger animations/audio/etc when a game event happens, and to send user input to the simulation.
|
|
#
?
Sep 21, 2020 23:12
|
|
|
Zaphod42 posted:This doesn't grok for me. Even working in C++, if you're a smart dev, you're going to program tools and then let other people use those tools you made in C++ to drag and drop to build the levels. That's how AAA games got made in the old days and how they are now. Doing everything hard-coded isn't C++, that's just... I'm tempted to say bad practice. Isn't Unreal also "drag and drop" ? quote:I'm not entirely sure what you mean by "code-generated content". You can definitely do procedural stuff in Unity.
|
|
#
?
Sep 22, 2020 01:24
|
|
|
roomforthetuna posted:It's not about "doing everything hard-coded", it's just a whole structural thing. Unity has its concept of a scene and its concept of an object, and its idea of when you should load stuff and its idea of how you can implement a loading screen and its idea of how physics should work and its idea of how you set values on individual instances of objects through the editor UI, and if you don't want to work within that model then it hates you. You *can* work outside that model, but then there's this whole huge interface of useless garbage cluttering up the place. I don't know what else to say other than... that hasn't been my experience whatsoever. I mean, yeah to scenes... but Unreal has similar concepts too, right? But as for "you have to load things the Unity way", or even "physics has to work a certain way" I'm not sure that's true at all. There's definitely a lot of different ways you can achieve those things. "It hates you" is a kinda nebulous thing to argue against, but... I dunno man. Compared to writing 6502 assembly, sure... but compared to using any other game engine like Unreal?
|
|
#
?
Sep 22, 2020 02:16
|
|
|
roomforthetuna posted:Yeah, I literally said that too. You *can* do procedural content in Unity. But again, if you want to, then it hates you. Basically all of my content aside from fundamental assets like models, sounds, and sprites is code-generated at runtime. It's not hard. Instantiate an empty GameObject, or a prefab if you like. Stick whatever components you need on it. Done.
|
|
#
?
Sep 22, 2020 02:24
|
|
|
Zaphod42 posted:I mean, yeah to scenes... but Unreal has similar concepts too, right? But as for "you have to load things the Unity way", or even "physics has to work a certain way" I'm not sure that's true at all. There's definitely a lot of different ways you can achieve those things.  It's not that you *have* to do things the Unity way, it's that there's a big honking framework pushing you to do it that way, so if you don't then you're fighting against the framework, and all the documentation for how to do a thing is how to do it the Unity way, so if you don't then you're venturing into poorly documented territory. I'm totally on board with the Caves of Qud / TooMuchAbstraction way of doing things, using Unity as a cross-platform engine rather than as a game engine. My objections are specifically to Unity as a game engine. I mean you're clearly aware that there *is* a Unity way of doing things, because you're saying you can work around it, and you're aware that the Unity way isn't that great, or you wouldn't know so much about all these ways to work around it, we're just differing in that I find the existence of - and encouragement to use - a lovely way of doing things to be annoying and frustrating, and you apparently don't mind working around it. (And I'm certainly not arguing in favor of Unreal engine!) Maybe you use an external code editor? When I used Unity I was using all its tools, which might have made it seem a lot more in-your-face with its preferences.
|
|
#
?
Sep 22, 2020 02:50
|
|
|
roomforthetuna posted:It's not about "doing everything hard-coded", it's just a whole structural thing. Unity has its concept of a scene and its concept of an object, and its idea of when you should load stuff and its idea of how you can implement a loading screen and its idea of how physics should work and its idea of how you set values on individual instances of objects through the editor UI, and if you don't want to work within that model then it hates you. You *can* work outside that model, but then there's this whole huge interface of useless garbage cluttering up the place. This is an odd grog take. I don't use any Unity physics and the fact that buried somewhere in the engine is a whole bunch of Unity code for physics doesn't affect me. I don't use scenes. I've been doing things like this in Unity for over 5 years so it's not even new. The new ECS stuff also has little to do with what you are talking about. If it's a performance worry a lot of the hand wringing about Unity also has little impact on tiny team indie games. Usually indie game performance problems come from more basic issues that would be present in any engine and would actually be a thousand times worse if they were doing it all by hand. The reality is that the alternative to a badly coded Unity game that runs like butt is not a better performing game but often no game at all. Unity allows them to gently caress up their code or asset management or whatever but still actually build. That's glorious not terrible. That helps them finish games which is still the #1 problem for a game dev. That's why the alternative to Unity for new game devs is something that holds your hand *more* like rpg maker or similar engines. If your objective is to make games specifically and not learn python or whatever than any weird grog poo poo, even if you have a programming background, is just getting in the way.
|
|
#
?
Sep 22, 2020 03:00
|
|
|
roomforthetuna posted:Yeah, that's why I said exactly the opposite of those things you put in quotes there. How is "you have to do it one way" the opposite from "it hates you if you don't do it one way" ? That seems disingenuous. Let me say it exactly how you are expecting then: No, it does not hate you for rolling your own physics. It does not hate you for any of those things. It has some APIs but they do not get in your way by existing. You are free to not use them and the unity marketplace is in fact full of people rewriting them and selling alternatives.
|
|
#
?
Sep 22, 2020 03:12
|
|
|
FuzzySlippers posted:That's why the alternative to Unity for new game devs is something that holds your hand *more* like rpg maker or similar engines. If your objective is to make games specifically and not learn python or whatever than any weird grog poo poo, even if you have a programming background, is just getting in the way. It's not a performance worry at all. It's that it will, for example, encourage a beginner to use physics for a game that doesn't need physics, so they'll end up with "stuck inside a door" or "catapulted off the world" bugs, or movable objects that weren't supposed to be movable, that wouldn't have happened if they were using a tool more appropriate for the job. There's a tutorial literally using a pill-shaped object to represent the player character specifically so that it can walk up hills and small stairs using the physics engine, where what you're more likely to actually want, for a beginner-made game, is a play area that acts flat and maps your vertical coordinate to whatever puts you on the ground. Their way you can get stuck on bumps, fall through the ground, or otherwise escape the play area, your speed varies annoyingly on different surfaces, etc. and if you try to work around it while still using the physics you end up with a mess of special cases and a different set of subtle bugs; the non-physics (or 2D physics) way, on the other hand, is super simple and relatively unlikely to have surprise bugs that go undetected. RPG Maker won't steer you wrong the way that Unity will, if that's the kind of game you want to make. And physics-based movement pretty much always feels like gross floaty garbage compared to a bespoke game-specific form of movement. You see that effect a lot in indie Unity games. And that's just the physics. The editor will encourage you to assemble content visually, so your beginner UI will be imperfectly aligned and your beginner levels will have weird seams in them. The scene system will have you put unnecessary load-breaks between levels in your 50MB game. A beginner won't know all these workarounds for how to not use Unity's poo poo when it's not appropriate, they won't even know when it's not appropriate. But yeah, okay, Unity's fine if, as a beginner, you want to just make a game and don't care if it's a bit poo poo, I agree it will get you there faster than making your own mistakes would.
|
|
#
?
Sep 22, 2020 03:17
|
|
|
That's a criticism of a specific tutorial though, not the engine. Nothing forces you to assign capsules or rigidbodies.
|
|
#
?
Sep 22, 2020 03:20
|
|
|
Zaphod42 posted:How is "you have to do it one way" the opposite from "it hates you if you don't do it one way" ? That seems disingenuous. "You *can* work outside that model, but then there's this whole huge interface of useless garbage cluttering up the place," which I said in the same post, is the thing that's the opposite of "you have to do it one way", in that it literally says, using words, that you can do it not that way. Is that not the opposite? Zaphod42 posted:That's a criticism of a specific tutorial though, not the engine. roomforthetuna fucked around with this message at 03:29 on Sep 22, 2020 |
|
#
?
Sep 22, 2020 03:23
|
|
|
roomforthetuna posted:And that's just the physics. The editor will encourage you to assemble content visually, so your beginner UI will be imperfectly aligned and your beginner levels will have weird seams in them. The scene system will have you put unnecessary load-breaks between levels in your 50MB game. A beginner won't know all these workarounds for how to not use Unity's poo poo when it's not appropriate, they won't even know when it's not appropriate. This applies to Unreal and every engine with a GUI, even game maker, so I'm confused why you're laying it at Unity's feet? You can load multiple scenes at once, or asynch load scenes in Unity. Everything you're saying is not Unity, but as mentioned, just how bad/new developers do. That's not the engine's fault. And while there may be consequences of dropping things according to a tutorial, again, if the alternative is 6502 assembly the newbie will spend 2 years learning programming not game making. Or if you're a programmer, 2 years on rolling your own physics. But these are all issues with using ANY existing library for game dev. Nothing about Unity hates you for rolling your own code. roomforthetuna posted:Jesus. It's not a criticism of a specific tutorial, it's a specific example of what will go wrong, from a specific tutorial. Are you trying to not understand the point? I agree that you can use Unity without all the things it provides! I recognize it is a product that can be used without sucking! My whole point is if you give it to a beginner, they will use the things, because they don't know not to use the things and it will tell them to use the things, and the game they make will be worse for it, as compared to if they used Godot or RPG Maker, which provide different, less harmful things. Yes, RPG Maker is simpler because you can't program physics, you're just forced to build an RPG. Lmao. This is such an insane apples and oranges argument where you're conflating like 10 different things together because you have a weird perception of what Unity is or just have an axe to grind or something. You're mad at Unity because it forces you to use a GUI editor... but you suggest to use RPG Maker which is that but worse. There's no way to program from source code or use procedural content in RPG maker dude. Also now I'm kinda losing my mind, because I just googled Godot Tutorial because I'm not as familiar with that particular engine and you seem real keen on it, and, I swear to god: https://docs.godotengine.org/en/stable/getting_started/step_by_step/your_first_game.html They start by telling you to create 3 scenes and how to organize your data through a GUI. So... I am lost on what you're saying here. Looking through this tutorial, everything they have you do is exactly the same as how a Unity or Unreal tutorial would go about things. They're using a WSYWIG editor to set up data structures through drag-and-drop and then they're writing C# files to execute code when the API calls them. Its literally the same thing. Am I taking crazy pills here? To quote this tutorial: quote:Now that we're done creating the HUD scene, go back to Main. Instance the HUD scene in Main like you did the Player scene. The scene tree should look like this, so make sure you didn't miss anything Its the same!  I think you have a misperception of what Unity is.I thought Godot was more like pico-8 but its literally the same thing as Unity the more I look into it. So I'm completely lost on what you think is so bad or different about Unity. I could understand advocating pico-8 if you were a purist, there's no libraries there you're just coding everything yourself. But pico-8 is obviously very hard and limited. But Godot is literally the same as Unity in this regard dude, they both have existing libraries you can use or not use. Zaphod42 fucked around with this message at 07:52 on Sep 22, 2020 |
|
#
?
Sep 22, 2020 03:24
|
|
|
GameMaker 2 ends up being very DIY. It has its own issue's, but a pretty standard way of making any non platformer seems to be create a room drop a Init object into it and then do everything else by code. I'm honestly super glad I learnt to program using GMS2 I really kinda makes you work out everything yourself, while still giving enough support to get things working quickly. I understand why so many games get made in it. It teaches you well, and has a serious sense of momentum. It has some real problems with things like team work and the such though. And if you wanna do 3d you really are doing everything yourself lol!
|
|
#
?
Sep 22, 2020 12:01
|
|
|
Anyone have recommendations for building the in-game UI in Unity? They seem to have their own GameObject based primitives but I'm wondering what else people use.
|
|
#
?
Sep 22, 2020 17:47
|
|
|
Less Fat Luke posted:Anyone have recommendations for building the in-game UI in Unity? They seem to have their own GameObject based primitives but I'm wondering what else people use. It depends upon the context and how fancy your UI needs to be, an FPS UI is pretty simple compared to like a Diablo UI. I just stuck a bunch of sprites and text on a canvas and had a custom class turn them on and off or manipulate the images or text contents and that worked decently well, but would probably get messy if you have a lot of things to manipulate or if you depend upon mouse/touch controls. I think this is the new hotness: https://www.youtube.com/watch?v=t4tfgI1XvGs
|
|
#
?
Sep 22, 2020 18:35
|
|
|
As of about two months ago, UI Builder does not cooperate with the new input system. It might have changed since then but I doubt it, I'm not mashing F5 on their changelogs. Which sucks because both packages are game changers for Unity.
|
|
#
?
Sep 22, 2020 18:37
|
|
|
xzzy posted:As of about two months ago, UI Builder does not cooperate with the new input system. It might have changed since then but I doubt it, I'm not mashing F5 on their changelogs. Wow 
|
|
#
?
Sep 22, 2020 18:41
|
|
|
Haha goddamn. It's going to have to be pretty complex, making an in-depth strategy game that will probably have a lot of menus and similar UI.
|
|
#
?
Sep 22, 2020 19:09
|
|
|
Less Fat Luke posted:Anyone have recommendations for building the in-game UI in Unity? They seem to have their own GameObject based primitives but I'm wondering what else people use. I use Unity's stuff, just a bunch of panels and text objects and so on. It sucks, but all UI development tools suck. Maybe Unity sucks a bit more than many, but I've definitely also seen worse.
|
|
#
?
Sep 22, 2020 19:09
|
|
|
I also use the Unity UI and I agree it sucks like every UI thing I've had to deal with. The new stuff whenever its finished looks much better. My game has a lot of complex RPG crap so I'm using it pretty extensively. There's nothing really difficulty about it, it's just tedious. My suggestion: do not wire up everything through a rat's nest of Unity UI events. I use classes like UIGenericButton and so on that takes the Click and other events and register them to a Mono attached to the prefab. All the individual crap in my UI are all prefabs. Then I do my UI via code where I can just grab the generic button class and have easy access to all its events. I find that much easier to debug and deal with but YMMV. Whenever I can be procedural in my code I just pull those generic elements from a prefab pool and it works very well. Still, the UI is the only thing I do that relies on complicated GameObject hierarchy because avoiding it was even more bother. The new UIElements system is more compatible with a no GO setup like all the new systems with an eye towards ECS, but its still in the oven.
|
|
#
?
Sep 22, 2020 22:24
|
|
|
Thanks for the tips!
|
|
#
?
Sep 22, 2020 23:20
|
|
|
|
| # ? May 13, 2024 19:41 |
|
|
xzzy posted:As of about two months ago, UI Builder does not cooperate with the new input system. It might have changed since then but I doubt it, I'm not mashing F5 on their changelogs. This is supposedly fixed now
|
|
#
?
Sep 23, 2020 01:20
|
|
