next »

[gimymblert]

feature creep is bad?

[Schoq]

a bilinear checkbox should take approximately one second to implement?

[gimymblert]

no feature takes one second to implement, the more boring the harder

[s0]

customizable controls take like 10 minutes to implement and yet...

[gimymblert]

You mean like rewriting how you handle your entire input mapping and associated variable distributed in any object that takes input

[s0]

What.

[gimymblert]

(traumatized memory from a previous failed implementation that blew up on my face)

[s0]

oh man lol

[gimymblert]

I tend to find "ambitious" features so much easy to implement because you have definitive validation steps and clear cut isolation.

But thing that have interrelated moving part like data management, menu, input, physics, etc ... god damn it!

In fact in game you will notice that most game critical bug accumulate between features interfaces rather than broken ambition.

That's why a game like bethesda's are having a pass, I have no idea how to approach that mess where almost everything is interrelated.

[s0]

but

wouldn't you normally just write a function that handles input and then pass the output of the function onto the game logic? that way input mapping and processing is completely independent from everything else. i literally can't think of a reason why you would ever set up your engine in a way that requires the thing you had.

[gimymblert]

Yep but you have to handle focus too so that you can control only one thing, like staying in the god damn menu without moving the camera, assuming it's a RT menu. Or when you have the same class for ai and playerS but just change the input interface, and you have a dependency because now you have a manager to deal with that and now you can't just put a car, you have to compile the whole game and set up a whole scene just to test an input and it takes 5mn between each god damn adjustment.

Kids! go to programming school to learn the boring stuff, you'll have plenty time do cool stuff on your own.

It's simple if you keep your game simple, but then there is thing you can't do, which may be the thing you WANT to do.

I had made "game sample" that works just fine, but it wasn't commercial grade and very lacking in options.

Don't start me on save system.

[s0]

you would just call the function every time you need player input, focus has nothing to with it. the function on its own doesn't do anything other than process input and spit out values that you can then use whatever you need them for.

if you really want the AI to use the same control scripts and stuff as the player, you'll have to write a separate function for AI that spits out the same type of values (which btw, does not interfere with player input whatsoever).

[gimymblert]

anytime the player need input? but how do you determine when it is?
And it's not that I didn't have that, is that it has dire implication.

Considering I used unity I had separate all function in a "feedforward" script component structures (as in, the actual "engine" don' know anything about input, the input component act directly on an interface on an engine, and the sensing part is above it in a different component too). But that didn't work as planned! Because conceptually there is circle dependency I had to solve.

BTW I'm not saying it's hard, I'm saying that depending on your (unplanned) implementation it can totally backfire and take more than 1mn to solve.

Ai on the other hand took me just half a day to iterate vs 1week for input and 1 month for sorting

[s0]

anytime the player need input? but how do you determine when it is?

once every game loop for instance? you would call the function once, stick the output into a variable then use a bunch of if clauses to decide what to do with it.

like so (presented in beautiful gam makr pseudocode):

Code:

player_input = input_function();

if player_input = 0
{
  do stuff
}

else if player_input = 1
{
  do other stuff  
}

etc.

that's how i've always done it at least (heavily simplified). i don't really understand what the "dire implications" are. it's worked as it should in every game i've used it. i mean i'm not a good programmer either so i might be missing something but.

[gimymblert]

I was talking about that specific UNPLANNED implementation, but basically it's stil more complex than that, you needed a "dj" that is able to track all the on and off because I was doing much more than that.

Especially because doing stuff and other stuff where never in teh same block, It mean rewriting much more or hacking the code and overriding dependency.

And it stem from me making a system with as little coupling as possible lol.

anytime the player need input? but how do you determine when it is?
And it's not that I didn't have that, is that it has dire implication.

Considering I used unity I had separate all function in a "feedforward" script component structures (as in, the actual "engine" don' know anything about input, the input component act directly on an interface on an engine, and the sensing part is above it in a different component too). But that didn't work as planned! Because conceptually there is circle dependency I had to solve.

BTW I'm not saying it's hard, I'm saying that depending on your (unplanned) implementation it can totally backfire and take more than 1mn to solve.

Ai on the other hand took me just half a day to iterate vs 1week for input and 1 month for sorting

[gimymblert]

okay I dig up the code, First of all you can't just stop the input on the car, because it will throw up the physics which is a global calculation, you need to suspend the physics without stopping the gamelogic ticks for menu.

The engine component do had a bool engine on/off that receive input from the track manager (to handle end of race and start of race) which basically block any input from player or AI.

If you just suspend menu the car will continue if you suspend the physics you might lose the previous state from which calculation was done. Which is also a problem for ai.

Because the track manager (spawn by the race manager that control the progression, track manager being basically the current level) mean that I can't use a car without a proper level and progression settings.

Car are basically lego anyway, each race they took the abstract data and reconstruct a car by building it component by component, visual part by visual part.

All gameplay object (and components) run in pseudo parallel anyway, so you would have to block all their individual process at once (hence why the dependency on manager), you don't have a monolithic gameplay loop (you could but that would mean reprogramming everything).

[Türbo Bröther]

Seems legit to me and this is shockingly bad photography. I had to be right on the TV to get it though but I would've had to be anyway, it's only like a 13-inch.

Here's a good* example one of the colours screwing up because they're too dark. I can't remember this happening with any colour otter than blue though.

*well, an example.

[MeshGearFox]

putting in a bilinear checkbox doesn't take any effort

making it actually do something does though

lso those raen't scanlines those are just pixel gaps you have them horizontal too

[Türbo Bröther]

Scanlines or not I was pleasantly surprised that the TV I was using still worked considering it's been collecting dust and wasp nests in the shed for the past fifteen years.

[MeshGearFox]

Can we get wasp nest filters.