/agdg/ - Autistic Game Design General

>Unreal's mass units are supposedly kilograms
>set mass of cube to 1
>touch it at normal walking speed of generic character controller
>it accelerates so much that it clips through walls
What the fuck?

>every day is like performing CPR on this fucking terrible game
Sounds like you're dealing with the dreaded first game syndrome where your first game will absolutely suck no matter what you tell yourself even the best devs can't escape it.

Gamemaker for complete beginners. It's easy to pick up and has a ton of tutorials. But it's more limiting and costs $100
Godot for people who either have a basic understanding of gamedev or are willing to take longer to learn. It's harder than Gamemaker, but is more flexible and free.

Only use Love if you have an extreme, probably unhealthy, love for Lua.

I don't know about the others.

try walking into a 1-kg box at full speed

>tfw closed it 10 minutes ago

why

it didn't clip through the wall

Force is going to be calculated harshly and not realistically. In real life your feet might bump into an object with the weight of your leg + very little velocity which amounts to like 15 lbs. of force. Ingame physics instead calculates tapping into something as you fully hitting it with all your weight.

I made all of this up just now. It's probably right though.

you are retarded and never touched a 3D engine before

Explain what was incorrect.

Is this too busy for a foreground?

It suspect it's even dumber than this. First of all, I can't be bothered to do the math out but I doubt the character controller has enough momentum to impart that kind of speed. Second of all, "simulate physics" seems to be off on everything so I assume the character controller handles it on its own, which means it's probably applying some ridiculous force.

100kg gives reasonable behavior, at least.

Nah. Looks fine.

Learn how to use your engine dumb dumb. There's this neat thing called documentation, doesn't UE4 have it?

Bodies applying the correct force based on their speed and mass is like the most basic shit that any engine does, even an atari game can do that.

I don't see how documentation would stop 1kg objects from accelerating to the speed of sound when gently bumped by a character controller, user.

it's useless to judge it outside of context

>Working on my first game
>No fucking idea what I'm doing
>several major overhauls to code base or engine switch
>Work is now going smoothly on my first game, but only because I've reanimated it's corpse enough that it is now a better, more powerful game
those frankenstein feels

>UE4

All I gotta do now is implement the new ammo type and get this HUD in game

>videogames simulate physics perfectly because atari
Who is the one who never used a 3D engine again?

user, calculating impact force is high school math-tier shit and if you even entertained the thought that a physics engine could lack this feature then you are retarded.

I would provide more but I'm remaking the environment from the ground up so I've got nothing else

Noted, thanks

Are you trying to imply that Unreal has horrible physics? Unity and most other game engines use the same system - PhysX. Yes, it has issues and yes, you will have to master them.
If you don't want a fast moving body clip through a wall, increase its thickness so the projectile gets caught between ticks. As for the rest - go figure it out on your own.

15k doesn't seem terrible, hell I have a lot of that saved already. If there were only a medium-quality art checkbox.

is there a speed limit in UE?

Is it bad to check whether the player is "grounded" or not in the Update() function in Unity? For some reason I feel like there's a better way of doing this.

Currently I have an input handler script that controls my person. All actions are done through the command pattern, but I feel like checking the ground status in that script isn't proper encapsulation. Should I just have it on a separate script on the player itself that sends a message to the InputHandler if there's a change or is running that ground check on a separate script going to cause performance issues if say I have multiple enemies that use the same script?

No 3D engine performs as perfectly as a pen to paper calculation would assume, why do you think clipping or any kind of physics related bug occurs in 3D engines to begin with?

You are the retard

>if you even entertained the thought that a physics engine could lack this feature
Who said 3D engines lack physics altogether? You're struggling boyo.

Think about what you'll need to check the ground for. Is it even possible for you to fall? If you can fall, it's probably best to keep it in your update function encase there's a way for you to fall without moving.

And here comes the comeback

What else do I need for basic AI for a stealth game? Doing patrols, chasing the player if they see them, looking for the player if they know they're there but can't see them, anything else?

>Are you trying to imply that Unreal has horrible physics?
No, I'm just extremely confused as to why this is happening.
It's not the clipping that bothers me. It's the fact that a 1kg object accelerates so fast it can clip through walls when all I did was touch it. I should probably look into how exactly the character controller works because I assume it is doing something non-obvious.

Remember that readability and predictability > actual intelligence for AI in most games

The calculation for velocity after bumping into the 1 kilo object is correct. The clipping is a result of velocity during collision and something else. Nothing too incorrect was stated you're just a bitchboy.

your like the embodiment of that "how much you know vs. how confident you are" graph

>physX doesn't take speed into account when calculating impact force
- agdg

no, but perhaps if the character is not moving you can choose to ignore ground checking.

Did you even read the first post? The guy literally says he made shit up, that's simply not how any physics engine works.

People can fall, so I'll need to check it.

I would think that'd be a good idea, but it depends on if checking velocity is less intensive that doing the raycast. If I am moving, then I'm checking two things instead of just one.

The Input handler is its own game object, so I think keeping it consolidated to the player it's controlling will be okay.

>anons defending blatantly incorrect information because the other guy was a meanie
This is a worrying trend.

Pro-tip to you carebears: your hugbox mechanics only generate even more shitposting.

You're not listening. Calm your autism.

What you consider blatant incorrect information wasn't even really stated as information. You're just being a sperg.

Read reply chains before trying to be witty next time.

>trying to be witty
I said calm your autism not rev it up.

Hows my brick walls looking art devs?

I've been reading up on the command pattern and I don't exactly see what the benefits are. Most places talk about how useful it is for changing key inputs, but doesn't Unity already have native support for that?

>using unity's default input system
heh

BUY THE NEW AND IMPROVED INPUT ASSET FOR ONLY $45

>this is what not using unity does

And don't forget to pre-order the Skyrim input asset, only $59.99 plus tax

Learning Unreal. Heard it was an awful engine to learn in but I'm quite liking the blueprint scripting so far.

Making an endless runner with it. Next I need to figure out how to procedurally spawn these platforms.

>Heard it was an awful engine to learn in
Maybe back when it was UE3, nowadays it's fine.

Not great. It looks like theres two textures fighting for dominance. Simple would be better here

Also I really dislike the design of the "totally not a whomp from Super Mario 64" enemy. It looks like both a ripoff and a shitty CG puppet

Finished this guy for Fleech's physics game!

Simple blocky guys like him will be the neutral civilians in the background in cities and hubs

I thought Unreal was supposed to be the one with better physics.

Unity physics stopped doing that shit like 5 years ago.

Fucking adorable

Both Unity and Unreal use Nvidia's Physx engine.

even tough they both use Physx

Thanks, user!

>tfw looking at my to-do list after a month of nodev was busy IRL
How the hell do I get back into this? I feel like all the passion I had for this project is gone.

nodevs say the craziest things

pretty cube but aren't you worried about identification issues? all the robots have the same colors

i always though foreground should be brighter and background darker, unless background will be darker than the foreground you posted

Yeah, I'm going to be making a new texture map next.
The game will probably have a large amount of bots, so a few of them being similar isn't going to be a big problem.

(All the bots I've made so far share the same 128x128p texture)

...

It's about decoupling different processes from each other for easier re-usability, debugging, and expanding implementation.

A good example of the command pattern would be Rubick from Dota 2 (most likely). When he steals someone's ability, it's not like his character has every ability coded into him. Rather it will call that ability (command) and have Rubick do it. Ability draft works in a similar fashion. Command pattern also allows you to store replays in commands. That's how most games allow you to view replays, it stores a list of command done at certain time in order to recreate the game.

It's one of the most well known design patterns for a reason and knowing how to use it will improve your ability to code greatly.

Yet I haven't had problems with low mass VERY HIGH SPEED projectiles penetrating meshes in Unity lately. The 2nd to last proto I made had gun bullets that had roughly realistic muzzle velocity and they collided just fine.

My submission is guaranteed, my game is never in a state of unplayability and I'm well within the schedule I set for DD15.

Anyone got some good free software to create sounds/music? I rater create my own.

Well too bad, it doesn't matter what you think. They're both the same physics engine. That's a fact.

>spending 2 days straight figuring out how to code something to make it work
>every hour is just trying to put square blocks into triangle holes
>slowly building a foundation
>at the final piece of the puzzle
>someone must of chucked it into the cursed sea
>can't figure it out
>nothing is working
>every idea isn't panning out like it should
>hope is fickle
>but dreams are strong and never going to give up
>suddenly, after one thousand idea, the golden one appears
>implement it
>IT FUCKING WORKS
>tfw this mission critical chunk of code will be used for the rest of my project

I fucking hate programming

After missing the last 3 I think Ill finally make this one.

Missing 15 for sure now

how do you "miss" a demo day?
isn't your game basically always playable?

unbelievably nodev question, well done 10/10

Just a bit more and this enemy factory will be ready to go. Gotta do some backend work to get skill support in (and define what skills are) as well as getting the Skill Reward feature working.

Once all that's good, I'll just need to update the saving feature for this thing and I should be able to finally start working on the combat system.

Just because your game is objectively playable doesn't mean it's in a state to show off or that it'll do anything useful when launched

>want to post a demo
>at this point game is just a generic platformer

weres ur game

These better?

I will try to come up with a better design for that enemy I'm mainly using them as bridges so its tough to come up with something that looks more original regardless.

Yeah, make something like a brick outcropping on the edges where the brick meets the yellow so it's not so stark.

Ah right, this has to do with the robustness of code that I'd asked about yesterday.

>implying Rubick doesn't always have a billion server-crashing bugs every time a spell is added or changed

I have no idea what you asked yesterday. I almost never post here since these generals aren't very helpful. The threads on /v/ are usually much more productive.

Despite the robustness of your code, it's good practice to use design patterns. Scripts shouldn't be much over 100 lines of code except maybe if it's your main script, which should be around 300-400. If you have more than that, then you're doing too much in one script and can probably break down what you're doing into a separate script.

Hmm, I that seems fair, but I think the distinction lies more in contrast, with contrast peaking on the main later and decreasing both forward and backward

at first i was like
>tfw you will never make a baller game like this

but when i saw the actual trailer i was like
>lol wtf is this shit

i could probably make something with similar gameplay just not with all the fancy animations and music

youtube.com/watch?v=wGQHQc_3ycE

what game? looks neat

yes but i want my demo to be fun, not just 'playable'.

In the past I'd been asking about how to make code "robust", in the way that things are grouped in a way that makes it easy to edit and add new functionality. Usually I do everything the simple way, and it works, but I know that it wont scale up should I need it to.

Sure you can, champ.