New Gamedev thread. This is thread is only for people who have deved something. Don't post in this thread if you're just an idea bro who has never deved anything in their life.
The engines:
>Unreal
>Unity
>Godot
>Cocos
>etc.
Go pickup one of these engines and start deving. My advice is don't ever get too caught up with reinventing the wheel if your goal is gamedev. Even people who want to "develop their own engine" are using a million frameworks. If you're developing a 3D game, you're going to use a preexisting graphics engine instead of developing one yourself because that would be pointless. You are not going to improve on the graphics engines developed by 1000s of engineers smarter than yourself. It's a lot of advanced trigonometry, I foolishly bought a graphics programming book when I was young and dumb and overly ambitious. There's no point to it.
So basically every game engine works fundamentally in the exact same way. The only difference might be more in the realm of performance handling, but unless you're like a computer genius, that's not even relevant to you. Unreal gives you full access to the source code. If you're so smart you can decipher it and modify it to your heart's content. I recommend real. I'm no programming whiz, but what actually counts:GAMEPLAY PROGRAMMING is very intuitive. It's very easy. If you can write out the rules for a board game, you could easily write those same rules out in code. That's how simple and intuitive gameplay programming is.
>This is thread is only for people who have deved something. Don't post in this thread if you're just an idea bro who has never deved anything in their life.
<I'd ammend the statement to say that inquiries into gamedev are fine. No one wants to hear your ideas though unless you are determined to invest the time and effort into making them a reality
Ok so I'm going to put my money where my mouth is.
This is some preliminary work I did years ago in effort to make an action shooter like RE4 and 5 and etc. Only really similar thing is the camera motion for aiming. I have it that you are in a parallel chase cam by default, then when you aim, the camera flies over the right shoulder to give you an aim view which is still 3rd person. Also when you enter aim mode, it cancels sprint mode and the most you can do is fast walk.
I created multiple walk modes. Default walk, jog speed, then sprint speed. When you double tap shift you get sprint speed. How much different speeds deplete your stamina, which is the second bar from the top which fills out on both sides, is dependent on the angle you are walking. On a perfectly horizontal plane, walking refills your stamina, jogging keeps your stamina constant, neither refilling or depleting it, and sprinting depletes your stamina. All of these numbers are multipled or divided by the angle you are going. If you are going uphill it is multipled, so even jogging depletes your stamina, if you're going downhill, even sprinting can keep your stamina constant.
I also programmed in fall damage but no point in showing that. Every game has that.
So yeah this is all mechanics I programmed from scratch in a couple days. It's not too hard at all. It's just basic logic. I did this all in blueprints./
>>40777That blue debug sphere shows the characters center of gravity. I did that by getting all the joint locations, then averaging between each joint to get the center of each limb, then I looked up the mass ratios for limbs, then I weighted each location by the mass ratio and found a dynamic center of gravity for no matter what pose the skeleton is in.
Past that I didn't do anything with it, but I have some ideas.
>>40789Woo you picked a hard topic. Just reminded me I was working on a universal base mesh. It depends how high poly you want to go. All the advice I've seen is don't worry about polycounts so much. I'm not done with it yet. I just got down to starting to work on the feet and there's a lot of shit I should probably fix.
Basically the ideal is to keep everything a square grid, because that's how things divide. But you're going to need to create intersections where five squares meet sometimes. This is how edge loops are formed. Edge loops are nice to separate different areas on the mesh for sculpting as well.
So where do we need polygons? We need them in areas that deform especially like you said. But we also need them in an area that is going to be highly curved as well. You can use normal mapping to make the blocky polygons look rounded as they're supposed to from head on, think of normal maps like a hologram, but from silouhette, you need the polys unless you want a blocky curve.
This shit looks really high poly but it's only 27k tris right now. That's still pretty low.
No one really suggested this to me, so this may be a dumb idea, I'm trying out tris so I can split an edge into another edge loop so I can add more polys in places where I need it like da booba. I'm planning on using this as a universal base mesh so I definitely wanted more polys to be able to handle even large booba than this.
The part that just fucking pissed the hell out of me is doing the retopo on the under armpits. Also I don't know if my technique is good, but I'm using Houdini for this retopo and they have a smooth tool, and that's kind off how I've been informing my choices is, draw some polygons, hit smooth, see where they go, add more polys until they stay in regions where I need them. The armpits are fucking bastard. In general you want circular edge loops around circular areas, and you can see in that video, that's how he did the booba, but I was finding with my smoothing that was making everything concentrate to the center of the booba. so I instead went with the grid approach. I think that will work better for deformations as well.
You can see with the face and the mouth I went with a circular edge loop around the mouth and eyes.
>>40793And the number of reasons you want one single base:
>Better for performancethe game only has to load the polys once.
>the rigging and everything is saved between them>This is how all character customizers workIs that there is one basemesh, and then their are different deformers you can blend between. You can checkout Daz3D to get more of an idea how that works. You'll see that people sell all kinds of "characters" so to say, but these are all just deformers for the like handful of Daz basemeshes, Genesis3 etc.
Since this thread is up, I might aswell post some tips given that I actually do have some experience in game development
First off, if you’re going to code movement, never lock the any actions to a specific key or even worse—the frame rate. It’s so easy for developers to attach movement to the game’s updates accidentally instead of an interval and they end up paying the price for it. Even AAA studios fuck up movement by keeping movement actions attached to the frame rate.
To address the “don’t attach movement actions to specific keys” thing is fairly easy. Create a class, array, or a matrix that stores all the potential actions (personally I like to keep the actions stored as Booleans or functions) a character can have. Then whenever the player presses a combination of keys or a key while another action is playing, the game’s avatar will respond by allowing multiple of these actions update and express themselves simultaneously.
In application, movement matrices allow players to move diagonally, have inertia, move while interacting with the game’s menus, and perform complex actions like strafing, reloading with a gun while sprinting, or riding vehicles.
I’ll also throw in this idea. You know how in online games where if your ping is garbage you’ll frequently find yourself “teleporting?” The thing that causes this effect is the game’s tick rate being responsible for the physics instead of the frame rate. This means that if your game is experiencing lag or if your frame rate tanks, you can expect that your character will still move around the way they should if your game was running normally.
In fact, teleportation during moments of lag in gaming is a sign that the game is running properly.
>>40807The second and last thing I’ll post about is fall prevention.
In games, falling is generally obnoxious and is a common problem in nearly all indie games I’ve found. I think it’s inappropriate in games not explicitly designed for platforming. If you’re designing any game with a jump mechanic or some form of platforming, make sure that you put up guard rails and that you walk off cliffs.
For additional interventions in designing your levels, make sure that any flat inclines are turned into staircases so that if your character ragdolls or runs too fast that they won’t like fall off the terrain awkwardly.
>pic rel >>40807>Then whenever the player presses a combination of keys or a key while another action is playing, the game’s avatar will respond by allowing multiple of these actions update and express themselves simultaneously. I don't follow what you're saying. I don't see how that has anything to do with input actions. Yes you don't hard tie inputs to specific keys because you want them to be reprogrammable.
>(personally I like to keep the actions stored as Booleans or functions)Input action functions are dependant on the kind of input action. For example, a joystick will update every tick for the value it's being held to, whereas buttons fire once per press. Mouse axis input fires every time the mouse data is updated, dependent on the hertz rate on your mouse.
>In application, movement matrices allow players to move diagonally, have inertia, move while interacting with the game’s menus, and perform complex actions like strafing, reloading with a gun while sprinting, or riding vehicles.For movement you want a 3dvector for 3d movement or a 2d vector for 2d movement, then the rest of that are just variables. They're not all in an array together.
>First off, if you’re going to code movement, never lock the any actions to a specific key or even worse—the frame rate. It’s so easy for developers to attach movement to the game’s updates accidentally instead of an interval and they end up paying the price for it. Even AAA studios fuck up movement by keeping movement actions attached to the frame rate.The tick is the framerate.
<"Ticking" refers to running a piece of code or Blueprint script on an actor or component at regular intervals, usually once per frame. Understanding the order in which your game's actors and components tick relative to each other and other per-frame tasks performed by the engine is essential to avoid off-by-one frame issues, as well as to ensure consistency in the way your game runs. Actors and components can be set up to tick each frame, at set minimum time intervals, or not at all. In addition, they can be grouped together at different phases in the engine's per-frame update loop, and can be individually instructed to wait for specific ticks to complete before beginning.The way Unreal and Unity handle variable frame rates is they have a float variable that updates with each tick that tells you what the frame rate is, then you multiply your variables that you're firing on the tick based on that. So if you want the velocity to be 5 meters a second, at 60 fps, that's .083 meters a second. If the frame rate drops to 30 fps, it will increase the value to .16.
This coding plugin I'm using has an even better method called steady tick.
https://turbanov.ru/wiki/en/toolworks/docs/apparatus/steady-tick
>I’ll also throw in this idea. You know how in online games where if your ping is garbage you’ll frequently find yourself “teleporting?” The thing that causes this effect is the game’s tick rate being responsible for the physics instead of the frame rate. This means that if your game is experiencing lag or if your frame rate tanks, you can expect that your character will still move around the way they should if your game was running normally.This is about whether movement updates happen client side or server side. It's good too because it prevents cheating. I'll let the AI go more into pros and cons.
>>40811>In games, falling is generally obnoxious and is a common problem in nearly all indie games I’ve found. I think it’s inappropriate in games not explicitly designed for platforming. If you’re designing any game with a jump mechanic or some form of platforming, make sure that you put up guard rails and that you walk off cliffs. Unreal has a function in their default character movement component that can prevent you from walking off an object. It flat out detects any ledge, so you have no need to put up invisible walls. It's also dependent on the the height of the ledge so it won't prevent you from walking off a curb for example.
>For additional interventions in designing your levels, make sure that any flat inclines are turned into staircases so that if your character ragdolls or runs too fast that they won’t like fall off the terrain awkwardly. You can easily program the ragdoll. You can have a physics simulation and control it at the same time. For example if you think the body is falling to far, you can just tell it to apply more friction or even stop all movement of the capsule, which is the actual thing that's moving, it's not running a true sim, it's just simulating the joints.
Another piece of advice about ragdoll, is you can make the joints as stiff or soft as you like, no reason to have the arms and legs flying all over the place at silly angles. Also you can combine ragdoll with animation. For example, you can have a character playing a punch animation, then have his head or arm for that matter react to a blow with ragdoll, while the animation is still playing, and even on the bone that is ragdolling, you can have it blend at any percentage with it's animation, 10% ragdoll reaction 90% animation, or 90% ragdoll 10% animation. Hope that makes sense. I'll post some stuff later. It's a pretty awesome technique that can get you some very realistic results.
>>40815Far cry 3 also had a slide mechanic that kept the player grounded if they were moving down inclines. You would slide instead of fall if you were sprinting near an incline which kept the movement much more grounded. Crazy to omagine that that shit is rare to find even in modern shooters.
Also far cry 3 also brought a mechanic from far cry 2 too. The game kept people from falling off stairs when sprinting by locking the movement speed whenever the player’s avatar triggered a staircase’s collision. Such old games but they had such good designs.
Wish I could see that level of expertise in modern games more
>>40820There's a lot of low polly examples out there. My recommendation is just look up each up the areas, and look up the kind of edgeloops suggested.
>headhttp://wiki.polycount.com/wiki/FaceTopology>breasts>shoulders,http://wiki.polycount.com/wiki/ShoulderTopology>elbows, kneeshttp://wiki.polycount.com/wiki/Limb_Topology>hands>feeteverything else between those areas can be straight forward for the most part.
>>40774>Unreal>Unity>Godot>Cocos>etc.Game Builder Garage on Switch allows me to click together polygonal worlds and it's flexible enough for puzzlers, platformers, racers, whatever. In terms of graphics and sound customizing it got very few choices though. I'm making a 3D-platformer level with N64 complexity.
The software doesn't directly provide higher concepts like pathfinding, but my level's architecture is mostly static, so putting some invisible sensors and triggers into the environment works well enough. Sadly there seems to be no special view mode for revealing invisible sensor stuff while playtesting, instead I have to go into edit mode and manually turn a sensor's visibility on or off.
There is a big tutorial that suggests setting sensors to react to the player character, and that's what I got atm; but I'm thinking about making the sensors instead react to an invisible object around the player that gets bigger when you do noisy actions.
I initially thought it would be elegant to have some
logical if-then relations realized directly through
physics… But object interactions play out differently on repeated runs (and no, it's not due to variability in user input, I have made sure of that). The physics are so jank that I don't even trust the physics to implement the physics :/ Now I have to use logical fallback solutions to potential physics fuckups: If I wish a big rolling ball to stop in some place after X seconds, I will make sure of that by deleting the ball wherever it may be and teleporting instantly a replica ball into that place.
>>40777>All of these numbers are multipled or divided by the angle you are going. If you are going uphill it is multipled, so even jogging depletes your stamina, if you're going downhill, even sprinting can keep your stamina constant.I can see downhill means less stamina lost per meter than running uphill, but that's not the same as less stamina lost per second.
>>40774>you're going to use a preexisting graphics engine instead of developing one yourself because that would be pointlessI am personally offended by that, but if you can't articulate a need for a custom renderer it's true.
>>40775Most the performance wins if you're already using an engine aren't tricks or digging into the rendering code, it's just following best practices.
>>43292>No, but graphics can be so much clearer and better directed than Blurry UE5 TAA Upscaleslop. Somewhere along the way epic and unity lost their fucking minds on what looks good and we all have to suffer the endless torrent of samey indie games with their insane defaults.You can always disable whatever feature of the engine you don't want. But thanks for bringing it to my attention. I haven't looked into that enough.
https://dev.epicgames.com/documentation/en-us/unreal-engine/dynamic-resolution?application_version=4.27Relatedly, UE has this HORRIBLE motion blur enabled by default. It looks especially terrible in 3rd person where you're going to spin the camera around the character frequently. Literally the entire screen blurs up, and on top of that it makes the game lag like crazy. I always see rookie UE devs leaving it on but I think most pros have the good sense to turn that shit off. I think some games have it as a selectable option in the graphics settings.
Unique IPs: 9