Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Mr Shiny Pants: Nov 12, 2012

Stick100 posted:

Well if you want since 4.15 you've been able to "Nativize" Blueprint where they compile it down to C++ for you at package time. They made it for Robo Recall and found a decent performance improvement.

Unity does the same with their IL2CPP compiler iirc.

# ? Aug 1, 2017 20:33

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 08:03

xgalaxy: Jan 27, 2004; i write code

It's true that "native-izing" blueprints (ue4) and c# (unity) gains you speed. But there is still a VM there that both have to run through that normal C++ compiled code doesn't. In the case of this UE4-mono thing, even if they did do an IL2CPP solution like unity - there would still be two levels of VM's that code would have to run through.

# ? Aug 1, 2017 20:57

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

xgalaxy posted:

It's true that "native-izing" blueprints (ue4) and c# (unity) gains you speed. But there is still a VM there that both have to run through that normal C++ compiled code doesn't. In the case of this UE4-mono thing. Even if they did do an IL2CPP solution like unity - there would still be two levels of VM's that code would have to run through.

That's the future, man!

# ? Aug 1, 2017 20:58

Sininu: Jan 8, 2014

Stick100 posted:

Well if you want since 4.15 you've been able to "Nativize" Blueprint where they compile it down to C++ for you at package time. They made it for Robo Recall and found a decent performance improvement.

If anyone is curious about approximate performance difference between BP and native stuff someone recently made a comparison:
https://www.reddit.com/r/unrealengine/comments/6qtxy3/test_blueprint_vs_c_performance_vs_nativized_bp/

quote:

Going by the above and the results from the video, C++ (in this simplified instance) is roughly 200-300x faster than BP and still 6-8x faster than nativized BP.

# ? Aug 1, 2017 21:16

duck monster: Dec 15, 2004

edit: Redacted. My google-fu sucks right now.

# ? Aug 2, 2017 06:49

Linear Zoetrope: Nov 28, 2011; A hero must cook

Is there any "UE4 shaders for people who are proficient in GLSL" guide? Because I understand pretty much every programmable stage of the GLSL pipeline pretty well, but UE4's shader thing is inscrutable to me. From what I can tell adding a lighting/shading model via shader (e.g. cel shading or whatever else) is impossible without hooking into several parts of the engine. Which, fair enough, I found several forks with various lighting models implemented. However, I still don't entirely get how shaders in UE4 work and most tutorials seem to assume I'm starting from the "what's a shader? Is that some kind of food?" level. I kinda just need a "In GLSL you do X, in UE's shadermabober you do Y" cheatsheet.

(Also, just for giggles, does UE4 support compute shaders natively?)

# ? Aug 2, 2017 07:24

Lowen SoDium: Jun 5, 2003; Highen Fiber; Clapping Larry

SinineSiil posted:

If anyone is curious about approximate performance difference between BP and native stuff someone recently made a comparison:
https://www.reddit.com/r/unrealengine/comments/6qtxy3/test_blueprint_vs_c_performance_vs_nativized_bp/

Read a little farther down the comments. The guy doing the test does 3 updates and found that if he increased the number of math operations to make the loop over head lower, the difference between C++ and nativized BP goes down significantly.

# ? Aug 3, 2017 18:33

Stick100: Mar 18, 2003

Lowen SoDium posted:

Read a little farther down the comments. The guy doing the test does 3 updates and found that if he increased the number of math operations to make the loop over head lower, the difference between C++ and nativized BP goes down significantly.

Wow:

Iterations C++ BP/Nat BP/Stand BP/PIE
100,000 120ms 155ms 8,200ms -

This shows that BP that is nativized is very near C++ performance, but without that it's painfully slower. I remember in UE streams they used to say that BP overhead was very low, on the order of 10% except for certain operations it could be extremely expensive. I'm not surprised that pure math is where that cost hits the hardest. I guess nativized blueprint is usable in performance sensitive operations. Of course it shows you need to be careful of how you build that BP as shown with the previous tests.

# ? Aug 3, 2017 21:28

baby puzzle: Jun 3, 2011; I'll Sequence your Storm.

I have a problem that seems like it is a solved problem, but I can't figure it out.

My game's framerate runs at whatever the hell your computer wants to run at, using v-sync at the users' discretion. However, my game's logic loop runs at 60 Hz. I want the game to be sure to behave the same on all machines. The logic loop and renderer are separate threads.

The problem I have is that objects that are updating their positions on every update appear to move in a very jittery fashion, because the 60 Hz logic loop, and the 60 Hz refresh on my machine aren't actually lining up, and they aren't supposed to.

What's the general solution here? My main thread is storing a time-stamped position and velocity, so that the render thread can try to figure out where things should be at the time of rendering, but it is still very jittery. I think I'm trying to go about this the wrong way.

# ? Aug 4, 2017 22:26

Spatial: Nov 15, 2007

The article everyone will point to: https://gafferongames.com/post/fix_your_timestep/

The basic idea is to split up time into discrete chunks and use the remaining fraction as the interpolation input between the previous and current render states. This way you get a perfectly smooth interval between each frame even if the two threads are out of sync, or one is running at a much different rate than the other. (e.g. 144Hz monitor)

# ? Aug 5, 2017 00:37

baby puzzle: Jun 3, 2011; I'll Sequence your Storm.

So my game logic needs to update in my render thread? I suppose I can make that change but it doesn't seem fun.

# ? Aug 5, 2017 00:49

Spatial: Nov 15, 2007

No, the same principle works for separate threads too.

I actually have the same architecture as you do in my own game, so I'll try to explain a bit better. The render thread continuously adds to the elapsed time accumulator (producing) while simultaneously the logic thread subtracts discrete time steps from the accumulator and updates the game each time it does that (consuming).

You have to be real careful how it's implemented to avoid jitter. I use triple buffering so the two threads don't have to wait for each other. Two of the buffers are always being used by the render thread to generate a frame while the other is being written by the logic thread.

Here's what my code looks like. These are member functions, any variables not declared in scope are persistent in timing manager. The render and logic threads call into these functions to update and render the game:

Logic update, the simplest part.

C++ code:

void logicThreadUpdate() {
    while (accumulatedTime >= targetTimePerStep) {
        gameUpdate( tripleBuffer.acquireWriteBuffer() );

        SpinLock lock( mutex );
        tripleBuffer.releaseWriteBuffer();
        accumulatedTime -= targetTimePerStep;
        lock.unlock();
    }
}

The render thread calls this function. It does the work of computing how much time elapsed and updating the current time value.

C++ code:

void renderThreadUpdate() {
    SpinLock lock( mutex );

    const Time currentTime = Timer::now();
    const Time delta       = currentTime - deltaReference;
    deltaReference   = currentTime;
    accumulatedTime += delta;
    
    // Prevent out-of-control time buildup.
    clamp( &accumulatedTime, maxAccumulatedTime ); 
    
    const auto  renderBuffers = tripleBuffer.getReadBuffers();
    const double interpolation = accumulatedTime / targetTimePerStep;

    lock.unlock();
    
    render( renderBuffers.previous, renderBuffers.current, interpolation );
}

You're probably wondering about that mutex lock. That's the only source of contention of between the two threads; it's necessary because if accumulatedTime is changed by the logic thread during that tiny window between the addition of the deltatime and the divide then it causes a visible glitch. It's implemented as a spinlock because it's held for an extremely short time.

'Timer' is just a helper class which wraps the system-specific high precision timer. It needs to be high precision, regular old 1ms accuracy won't cut it.

The clamp on the accumulated time variable is necessary to prevent the game accumulating too much time and running too fast in order to catch up. This kind of thing happens if the machine is really slow, or if you pause the game to debug it.

Let me know if you need any other info and I'll do my best.

# ? Aug 5, 2017 01:40

Zerf: Dec 17, 2004; I miss you, sandman

Spatial posted:

Words

This is pretty much how we are going to handle it in our game as well. We'll update our gamestate @10Hz, while the graphics interpolates (maybe also extrapolates?) between previous gamestates.

One thing that is worth to mention however is that this scheme will lead to lagging feedback for the player, so you should be prepared to deal with that in some way. Here's a simple schematic for our game:

Here you can see that gamestate being updated every 100ms, and the graphics thread every 16ms. The rendering is also buffered, so that means that even more lag will occur before we actually see each new gamestate. Depending on your game, this latency might be something you need to work around to give more immediate feedback to the player. Our current plan is to happily ignore it until it becomes a problem though

# ? Aug 5, 2017 10:01

Dr. Stab: Sep 12, 2010; 👨🏻‍⚕️🩺🔪🙀😱🙀

185 ms is a very long time.

# ? Aug 5, 2017 12:18

Zerf: Dec 17, 2004; I miss you, sandman

Dr. Stab posted:

185 ms is a very long time.

It truly is, and that's not even the worst case. In the diagram above, the start time for the gamestate update is omitted. This means that if you click exactly at the wrong moment, you are looking at 100ms + gamestate update time(~30ms?) before the click has any effect. But it's also the time that elapses between the click and the visual impact of the gamestate change, and that doesn't imply that the user gets zero feedback during that period.

UI, sound and/or graphics can of course update much faster, if they know or can speculate what is going happen. For our game, we don't think it's going to be much of an issue, it's also why we've chosen the relatively slow update frequency of 10Hz.

Of course, timing charts like this gets even more interesting once you throw in network latency into the mix :getin:

# ? Aug 5, 2017 12:57

Ranzear: Jul 25, 2013

What could possibly require that to be 10hz? Are you trying to run the whole game at a minimal network tick rate so you can run a hundred servers at once or something?

# ? Aug 5, 2017 19:58

Spatial: Nov 15, 2007

I'm guessing it's an RTS. Supreme Commander did the same thing.

I run at 100Hz since I'm making an action game.

# ? Aug 5, 2017 20:02

Xerophyte: Mar 17, 2008; This space intentionally left blank

Spatial posted:

I'm guessing it's an RTS. Supreme Commander did the same thing.

I run at 100Hz since I'm making an action game.

StarCraft and Total Annihilation also ran at 10 hz, but all those games also used a lot of complicated lag hiding hacks. For instance, StarCraft would blend in unit turning animations from input that hadn't been processed for simulation yet in order to fake being responsive. It sounds pretty difficult and fiddly to do well so it's probably an approach best avoided unless you absolutely cannot run the sim faster.

If your project is Supreme Commander for phones or something then sure, still relevant.

# ? Aug 5, 2017 20:17

Zerf: Dec 17, 2004; I miss you, sandman

Ranzear posted:

What could possibly require that to be 10hz? Are you trying to run the whole game at a minimal network tick rate so you can run a hundred servers at once or something?

It's a game where you control agents by commands, and they decide if they want to do stuff or not. Think Banished, where you control a village. We could of course up the update interval to 60Hz or whatever, we just don't see a compelling reason to do so yet.

# ? Aug 5, 2017 21:49

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Zerf posted:

It's a game where you control agents by commands, and they decide if they want to do stuff or not. Think Banished, where you control a village. We could of course up the update interval to 60Hz or whatever, we just don't see a compelling reason to do so yet.

Why not just run the AI at 10hz? You're shooting yourself in the foot for no apparent reason, otherwise.

# ? Aug 6, 2017 02:00

Zerf: Dec 17, 2004; I miss you, sandman

Shalinor posted:

Why not just run the AI at 10hz? You're shooting yourself in the foot for no apparent reason, otherwise.

Why? 10Hz gives us a huuuge 100ms budget for gamestate updates and lowers network traffic. Why should we choose a higher update speed if gameplay doesn't necessitate it?

# ? Aug 6, 2017 05:45

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Zerf posted:

Why? 10Hz gives us a huuuge 100ms budget for gamestate updates and lowers network traffic. Why should we choose a higher update speed if gameplay doesn't necessitate it?

Because anything user facing can't be. Particles, physics, UI tweens, cursor movements, shader effects - the pretty stuff, that all needs to be at framerate. So why fake/hack ALL of that instead of just airlocking your gameplay logic and AI into its own fixed framerate segment? It's more controllable, it'll look and feel better, etc.

# ? Aug 6, 2017 18:54

Zerf: Dec 17, 2004; I miss you, sandman

Shalinor posted:

Because anything user facing can't be. Particles, physics, UI tweens, cursor movements, shader effects - the pretty stuff, that all needs to be at framerate. So why fake/hack ALL of that instead of just airlocking your gameplay logic and AI into its own fixed framerate segment? It's more controllable, it'll look and feel better, etc.

Because we aren't sure where we'll land with our render performance. Sure, we aim for 60Hz to begin with, but I wouldn't be surprised if we could achieve even higher framerates with gsync/freesync, since I anticipate that our game won't be that taxing when it comes to performance.

And if gameplay somehow breaks your framerate budget, you need to start hack around that instead, by only updating X agents per frame or whatever.

By just determining up-front that gameplay and graphics thread run independent of eachother at different rates, we have already determined what kind of problems we need to solve - we are then free to tweak the rates however we want.

# ? Aug 6, 2017 22:06

TheresaJayne: Jul 1, 2011

Just wondering how others resolve this issue,

1. Want to write a game,
2. Start the Boilerplate / engine/level gen
3. Get bored
4. Go play some other game like warframe, World of tanks, Overwatch, World of warcraft
5, Can't remember what you were doing and give up.

# ? Aug 7, 2017 12:22

Mr Shiny Pants: Nov 12, 2012

TheresaJayne posted:

Just wondering how others resolve this issue,

1. Want to write a game,
2. Start the Boilerplate / engine/level gen
3. Get bored
4. Go play some other game like warframe, World of tanks, Overwatch, World of warcraft
5, Can't remember what you were doing and give up.

Perseverance. Just keep doing it, have small targets you want to achieve. Otherwise you go nuts with the amount of work that goes into a game, or really any software for that matter.

# ? Aug 7, 2017 12:28

Absurd Alhazred: Mar 27, 2010; by Athanatos

TheresaJayne posted:

Just wondering how others resolve this issue,

1. Want to write a game,
2. Start the Boilerplate / engine/level gen
3. Get bored
4. Go play some other game like warframe, World of tanks, Overwatch, World of warcraft
5, Can't remember what you were doing and give up.

Between 1 and 2 you should add
1.2 Create a simple prototype.
1.3 Let someone else play with it and take notes.
1.4 Refine prototype.
1.5 Go back to 1.3 until you're ready to go to 2.

# ? Aug 7, 2017 12:50

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Mr Shiny Pants posted:

Perseverance. Just keep doing it, have small targets you want to achieve. Otherwise you go nuts with the amount of work that goes into a game, or really any software for that matter.

^this

Basically, you need to be a good producer/project manager for yourself. Enumerating things you need to do and making tickets is massively useful, despite being somewhat banal and feeling like a waste of time while you're doing it.

# ? Aug 7, 2017 13:11

stramit: Dec 9, 2004; Ask me about making games instead of gains.

My big switch came when I started to get actually proficient at programming. It slowly changed from a thing that felt like a 'learning activity' to something that became my default activity. I massively minimized my game playing and switched to coding instead. At the very least just try and do 15-20 minutes a day... habit forming helps.

# ? Aug 7, 2017 14:54

Elentor: Dec 14, 2004; by Jeffrey of YOSPOS

TheresaJayne posted:

Just wondering how others resolve this issue,

1. Want to write a game,
2. Start the Boilerplate / engine/level gen
3. Get bored
4. Go play some other game like warframe, World of tanks, Overwatch, World of warcraft
5, Can't remember what you were doing and give up.

I write huge spreadsheets with the game design.
Then I add //TBI -> What the hell I need to do in the functions and delete the TBI comment as I implement them. Once an entire tab of a spreadsheet is implemented, I add headers to it pointing out it's done already and which functions refer to it. Otherwise I do the opposite and add which spreadsheet or .txt each function I'm writing refers to.

I also write short and long term bullet lists and keep a history of what I've written like the one I'm maintaining on project.log.

Elentor fucked around with this message at 14:58 on Aug 7, 2017

# ? Aug 7, 2017 14:55

Jo: Jan 24, 2005; Soiled Meat

Strumpy posted:

...
At the very least just try and do 15-20 minutes a day... habit forming helps.

Habit is huge. I try the, "just one line" approach. After I get home in the evening, I have to add just one line. Sometimes it stops there, but usually it doesn't. Pick a recurring time each day or three times a week to work. Stay regular.

# ? Aug 7, 2017 15:49

Zerf: Dec 17, 2004; I miss you, sandman

Something that I found out was important to me (but might not be to others) was to be proud of your code and try to keep hacks and temporary solutions to a minimum. While this isn't the fastest of development methods (some of the code I write can safely be labeled as premature optimizations), I found out that I quickly lose interest if the code is full of temp/todos/hacks and bad code. My brain just gets full of "I really need to fix that later"-thoughts, and that takes away all the joy from writing new code.

I also believe that this is something that can be remedied with lists; keep writing everything you need to fix down and never let the list get too big. Again, it's probably something only a minority here can identify with, but that's what has helped me.

# ? Aug 7, 2017 16:39

Elentor: Dec 14, 2004; by Jeffrey of YOSPOS

I 300% agree with you about moving on even if you think of a better solution but I honestly cannot say I feel proud of looking at my code in any way.

# ? Aug 7, 2017 19:28

SupSuper: Apr 8, 2009; At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

Zerf posted:

Something that I found out was important to me (but might not be to others) was to be proud of your code and try to keep hacks and temporary solutions to a minimum. While this isn't the fastest of development methods (some of the code I write can safely be labeled as premature optimizations), I found out that I quickly lose interest if the code is full of temp/todos/hacks and bad code. My brain just gets full of "I really need to fix that later"-thoughts, and that takes away all the joy from writing new code.

I think this is a really common pitfall for new programmers. They think writing bad code is "cheap and easy" while writing good code is "hard and slow". But then what would the point of writing good code be? So they write fast and sloppily hoping to get to the finish line quickly, and then wonder why it's actually taking them much longer and feels much more morose and annoying to work with.

Don't aim for "perfection", aim for "making your job easier" and you'll stay better motivated.

# ? Aug 8, 2017 11:36

Paniolo: Oct 9, 2007; Heads will roll.

I feel like I see the opposite more often. Newer programmers struggle to be pragmatic and create overdesigned and overengineered solutions to everything.

# ? Aug 8, 2017 17:03

everythingWasBees: Jan 9, 2013

So I'm making a 2D tile-based game in Unity (think 2D Zelda). I'm gonna be making use of a* pathfinding. Is it best to adapt the a* pathfinding project, or, for something like that, would it be better to roll my own version better suited to my specific needs, as I probably won't need the optimizations or all of the other features.

Time-cost not being an issue.

# ? Aug 8, 2017 18:41

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

everythingWasBees posted:

So I'm making a 2D tile-based game in Unity (think 2D Zelda). I'm gonna be making use of a* pathfinding. Is it best to adapt the a* pathfinding project, or, for something like that, would it be better to roll my own version better suited to my specific needs, as I probably won't need the optimizations or all of the other features.

Time-cost not being an issue.

If you don't care about your time, A* is easy enough to implement to just do that.

If you do care about time cost, there's a well reviewed working implementation for nominal cost.

Rolling your own would let you toy around with JPS+ and such though, as well.

# ? Aug 8, 2017 18:59

Stick100: Mar 18, 2003

everythingWasBees posted:

So I'm making a 2D tile-based game in Unity (think 2D Zelda). I'm gonna be making use of a* pathfinding. Is it best to adapt the a* pathfinding project

Unless you personally care about learning A*, I'd suggest using the standard well review asset in the Asset store. No reason to reinvent the wheel.

# ? Aug 8, 2017 23:46

KillHour: Oct 28, 2007

Stick100 posted:

Unless you personally care about learning A*, I'd suggest using the standard well review asset in the Asset store. No reason to reinvent the wheel.

On the other hand, implementing A* is a great introduction to graph theory. Once I did it once, I was much more comfortable using graphs to solve problems in programming - I find I use them all the time and they're applicable in a ton of areas.

# ? Aug 9, 2017 02:18

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

everythingWasBees posted:

So I'm making a 2D tile-based game in Unity (think 2D Zelda). I'm gonna be making use of a* pathfinding. Is it best to adapt the a* pathfinding project, or, for something like that, would it be better to roll my own version better suited to my specific needs, as I probably won't need the optimizations or all of the other features.

Time-cost not being an issue.

Any particular reason you aren't just updating to latest-Unity and snagging the new built-in pathing tech? It uses navmesh, and actually looks pretty solid. I think it's in as of... 5.6.x?

# ? Aug 9, 2017 08:19

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 08:03

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Shalinor posted:

Any particular reason you aren't just updating to latest-Unity and snagging the new built-in pathing tech? It uses navmesh, and actually looks pretty solid. I think it's in as of... 5.6.x?

Can you configure a navmesh so it only allows gridded movement, or movement in certain directions?

# ? Aug 9, 2017 08:42

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »