Game Development Megathread

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

«‹›2 »

more falafel please: Feb 26, 2005; forums poster

vanjalolz posted:

Oh poo poo, i ran into the same problem the other day, but on a bigger scale. Is there a generalisation I can make which ignores the angle the player is facing? At the moment, I have to use different math functions depending on the angle (eg 0-90, 90-180, 180-270, 270-360)

Vectors?

You should in general be trying to avoid angles and trig. Vectors are significantly more flexible and faster.

# ¿ Dec 2, 2007 20:44

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 12:23

more falafel please: Feb 26, 2005; forums poster

Vinlaen posted:

Are there any game engines (or frameworks/libraries) that include automatic network synchronization of game objects?

For example, if I create a Worms or Scorched Earth game I would to shoot a projectile (using simple physics) and have it follow the same trajectory on every game client. I'd also like to include environment physics objects like black holes, etc, etc.

It seems like no game engines include automatic network synchronization...

Unreal, although that's not exactly what you're looking for in a Worms clone engine

# ¿ Feb 29, 2008 22:38

more falafel please: Feb 26, 2005; forums poster

Vinlaen posted:

Are you guys talking about Epic's Unreal Engine? (eg. the commericial engine)

I somewhat understand the reason that a general network synchronization library can't be developed, but I would think that a simple position, velocity/acceleration system could be worked out?

Yeah, it would be prohibitively expensive and not what you're looking for at all, except the network thing.

But Tim has written a very nice (if a bit self-horn-tooting) description of the network architecture of Unreal, including actor replication, prediction, etc: http://unreal.epicgames.com/Network.htm

This is based on UE2, from what I can tell, but the basics remain the same.

more falafel please fucked around with this message at 04:26 on Mar 1, 2008

# ¿ Mar 1, 2008 04:23

more falafel please: Feb 26, 2005; forums poster

Vinlaen posted:

Unfortunately, those are both for C++ and will not work with Delphi or C# (sorry, I should have been more specific in my request). I really don't like C++ and will probably be programming in Delphi (it's the language we use at work) or C#.

Let's forget about that for a second and let me ask a different question...

How would you do simple destructible terrain like Worms or Scorched Earth?

I understand that the basic idea is to have a texture that gets modified (eg. a render target, etc) but I'm confused on how large the texture needs to be.

For example, let's say I'm using a tiny repeatable texture to create the terrain image. Even though the repeatable texture is 128x128, I need a MUCH larger texture to achieve 1:1 resolution on my 1920x1200 native resolution monitor.

This causes the texture size to be huge (espicially if the terrain will span 3 screens wide and 2 screens high) and causes the game to be unplayable on older video cards.

Can anybody help me out with this, or do I just need to require newer video cards with large texture memory?

Can't you tile the texture? The card won't store more than one copy of it.

# ¿ Mar 1, 2008 18:24

more falafel please: Feb 26, 2005; forums poster

Fib posted:

You can implement your own acknowledgement and retransmission mechanism on top of UDP; for each connection between two endpoints, each endpoint should include a sequence number in the message header that increases each time a message is sent by that endpoint on that connection. Then the receiving endpoint can tell if it is missing any messages, and send some form of acknowledgement back. You can get arbitrarily clever with how you do this, although TCP essentially does the same thing and you don't have to worry about the details if you use it.

Let me expand on this a little bit.

TCP is great, but it's generally overkill for games. It's not incredibly difficult to write a reliable UDP layer that gives you most of the benefits of TCP without the overhead.

At the most basic, you define a message -- for instance, a 2-byte length in big-endian, then a 4-byte sequence number, then the payload. Assuming your application needs more than one type of message, you probably want to devote another byte or two of the payload to specifying what kind of message it is. To keep things as efficient as you can, you want to keep all messages within the size limit of a single ethernet frame (or, if possible, half the size, so you can send out 2 messages at a time, but half as frequently to save on overhead).

The application sends a message to a client by specifying a payload. The reliability layer adds a sequence number and length, calls sendto() to send the packet, and puts the message in its output queue, recording the time it was sent.

When a message is received with recvfrom(), it's placed in the input queue. The application is responsible for checking for messages in the input queue and popping them off for processing.

Here's where it gets interesting. You have no guarantee that your packets will get to the other side, and if they do, you have no guarantee as to what order they will come in. So let's say you've received messages 1-1000, so you're now expecting message 1001. If you receive message 1002, you know you've missed 1001. So you put it in your input queue, but in a separate "unordered" queue that the application can't access. When you get a message, you record that you've received the message with that sequence number. The next time you send a message out, you encode (at the beginning, or end, or whatever) ACKs to specify the lowest sequence number you haven't received, the highest sequence number you have received, and for each message between lowest and highest, whether you've received that message or not. When you receive a message with those ACKs attached, remove the messages the other side has seen from the output queue -- they've been received.

You now have data on how long each message took to go being sent to receiving the ACK for it. Averaging these times, you get a decent estimation of round trip time to the other side. Every time a message is going out, if there's room in it, attach a message from your output queue that's been in your output queue longer than the average round trip time. This way messages that don't get received will be resent.

It seems a lot more complicated than it is. With enough debug logging, you should be able to hack up a basic implementation in a day or two. What this gives you over TCP is the ability to control how messages are acknowledged and resent. The most important part, though, may be that you control the message size. With TCP, a connection is represented as an ordered stream of bytes. But your messages are already discrete chunks of data, and if you encode them as a stream, the TCP stack will be taking that stream and breaking it into discrete chunks anyway. This means that your TCP stack will receive incomplete messages, then wait for the rest of it to come in. When you guarantee that your message size is less than the size of an ethernet frame, you're essentially guaranteeing that it all comes through in one piece.

This allows you to run a peer-to-peer game using about 20kbits/sec of bandwidth, which can perform robustly with 10% packet loss and up to about 100ms of latency. For reference, console games are generally required to perform well with as little as 64kbits/sec of bandwidth, 2% overall packet loss with up to 10% spikes, and 100ms average latency.

# ¿ Mar 10, 2008 15:31

more falafel please: Feb 26, 2005; forums poster

Ferg posted:

I'm cross-posting this with the XNA thread:

I've added the GamerServicesComponent to my game, but it looks like I need to do something about controls when the Live Guide is open. Say I have a sprite on the game screen that moves left and right with the D-Pad. When I open up the Live guide and I'm hitting left and right to change tabs, my sprite is still moving inside the game in the background. Is there a way to disable controls when the guide is open?

The Microsoft.Xna.Framework.GamerServices.Guide has a property called IsVisible. That should tell you whether the guide is up, so you can ignore input.

# ¿ Mar 13, 2008 01:27

more falafel please: Feb 26, 2005; forums poster

Ferg posted:

Awesome, thanks!

While we're on the subject, is there a way with GamerServices to have a gamer's profile display the game they're playing as opposed to XNA Studio? My anal retentive side wants others to see what game I'm actually playing rather than seeing that I'm "just" using XNA studio.

It looks like rich presence is not supported in the XNA framework at this point, but supposedly they're working on it. The way MS does rich presence requires some server-side support that I'm not sure they want to support for XNA games.

# ¿ Mar 13, 2008 04:54

more falafel please: Feb 26, 2005; forums poster

ValhallaSmith posted:

I think physx has XNA bindings. Havok isn't really that well supported by the amateur community yet. But if you need an animation system for your game then Havok is probably a good choice. I would say neither of the engines is overly difficult, though they both have their own quirks.

Havok rules :c00lbert:

# ¿ Jun 4, 2008 17:05

more falafel please: Feb 26, 2005; forums poster

Thug Bonnet posted:

Can someone point me toward a good, no-bullshit discussion of quaternions that includes practical code examples? I always end up finding either high-level descriptions of the math involved or API-specific implementations. I'd love to see a bridge between the two somewhere. I haven't found the gamedev articles to be particularly helpful (they seem to suffer from the same problems).

The O'Reilly book Physics for Game Developers has a good explanation of quats. I haven't seen a good online discussion, but I can't say I've looked.

# ¿ Jun 13, 2008 03:52

more falafel please: Feb 26, 2005; forums poster

poemdexter posted:

I've been using pygame for a roguelike I've started to develop and notice a little flickering everytime I update the screen. I might take a look at pyglet.

Either you're running that on a 386 or the problem is not with PyGame, it's with your code.

# ¿ Jul 21, 2008 08:49

more falafel please: Feb 26, 2005; forums poster

poemdexter posted:

Could be the code, but seriously, it's like 150 lines of code max. All I'm doing is placing strings on a surface, blit, and flip. Am I missing something to cut down on the flicker?

I have some Python code that prints "hello world" 10 times but it's really slow, Python must be really slow.

code:

for i in range(1,10):
    print "hello world"
    for j in range(1,1000000000):
        pass

It's only 4 lines, it can't be the code.

I think this is a lot of the reason why people tend to think languages like Python and Ruby are so slow -- when complicated algorithms (regular expression matching, any string processing crap, etc) are hidden behind a really nice layer of abstraction, you don't realize when you're doing (for instance) n^2 operations n^2 times.

Here's a data point: the vast majority of gameplay code for Gears of War is either written in UnrealScript, expressed as data, or in Kismet, which is UE3's graphical scripting environment. You don't write AI in savagely optimized C.

# ¿ Jul 22, 2008 00:22

more falafel please: Feb 26, 2005; forums poster

krysmopompas posted:

Christ, I thought all this Kynapse stuff I've been staring at had something to do with AI...no wonder these bugs never get fixed.

The needs of Epic in Gears are vastly different from the needs of the general industry. Go ask someone from Midway about native vs. unrealscript performance.

Kynapse is middleware, which completely changes the discussion.

And I realize the native vs. script performance, that was my point. It works for Epic because they have lots of technical designers and gameplay programmers who can write UnrealScript. We don't really use UnrealScript for gameplay for a number of reasons, but we use gobs of Kismet and some other homebrew stuff. It isn't fast, but it doesn't have to be, it's barely even on the list of things that should be optimized/parallelized/etc. My point was that it's generally unnecessary to make gameplay code crazy fast -- it's usually much better to make it so designers and gameplay programmers can quickly iterate on it, ideally without rebuilding every time they try something.

# ¿ Jul 22, 2008 19:06

more falafel please: Feb 26, 2005; forums poster

StickGuy posted:

I think you missed some of the point. Your example has terrible performance because scripting languages just can't handle huge numbers of operations that are actually in the scripting language. If they are hidden away in "savagely optimized C", you won't notice it that much. Python et al. are good for games because you can let them deal with a number of game objects as individual objects and let the hidden C/C++ deal with the hundreds of thousands of individual triangles and vertices.

No, my example has terrible performance because it's algorithmically horrible. My point was that a lot of times perceived performance issues in languages like Python come from the language/library obscuring the algorithmic complexity of what it's doing under an awesome interface. This was in reference to someone saying that PyGame was taking a huge and noticeable amount of time to draw each frame. It wasn't PyGame that was the problem, it was that he was essentially reinitializing the entire surface every frame.

# ¿ Jul 22, 2008 19:09

more falafel please: Feb 26, 2005; forums poster

Vinlaen posted:

and "automatic" networking support.

This doesn't exist, and likely never will.

# ¿ Jul 28, 2008 20:01

more falafel please: Feb 26, 2005; forums poster

ultra-inquisitor posted:

Speed. They'll still be using malloc & free (or a variant) somewhere to actually (de)allocate the memory, but they're potentially expensive functions, so you sometimes want to give them a helping hand in various ways, eg pre-allocating memory, making sure it doesn't get too fragmented, etc. Also, wrapping memory allocation like this makes it easier to find leaks, segfaults, etc.

Memory allocation in games doesn't get discussed nearly enough, but it's very important for writing robust programs, especially ones which can run for a long period of time and perform lots of allocations without the memory getting too segmented.

It also allows them to know exactly how memory is getting allocated, essentially independently of the OS or hardware.

# ¿ Sep 11, 2008 22:34

more falafel please: Feb 26, 2005; forums poster

Skeletal animation question:

I'm trying to reduce cumulative error from animation compression. Our current animation compression is simple but error-prone: translations/rotations per keyframe per bone are stored in fixed point, so the error propagates down the bone tree.

The way I'm trying to fix this is (at import time) to use the world space position/orientation of each bone atom and recompute the deltas from the parent bone's compressed data.

I don't know anything about animation though, so I'm trying to make sure I understand the problem first. World space is still local to the skeleton, right, since this is all done offline? So wouldn't that make it local space?

# ¿ Jul 15, 2009 20:57

more falafel please: Feb 26, 2005; forums poster

3D math question:

I've got model-space scale/rotation/translation as vector3, quaternion, and vector3, respectively, for a parent bone in a skeleton, and bone-space scale/rotation/translation for a child bone, and I need to get model-space scale/rotation/translation for the child bone (as vector3 scale, quat rotation, vector3 trans). I don't know a lot about 3D math, so I'm kind of winging it:

- make 4x4 scale matrices out of the two scales
- make 4x4 rot matrices out of the two rotations
- make 4x4 trans matrices out of the two translations
- multiply ParentScaleMat * ParentRotMat * ParentTransMat to get ParentTM
- multiply ChildScaleMat * ChildRotMat * ChildTransMat to get ChildTM
- multiply ParentTM * ChildTM to get a 4x4 model-space basis for the child bone
- decompose into scale/rotation/translation using: http://www.ziggyware.com/readarticle.php?article_id=15

But I don't think it works right. Here are some of my numbers:

code:

ParentModelSpace scale: 1.00 1.00 1.00 rot: 0.29 0.56 0.39 -0.67 trans: 0.00 0.00 102.42
ChildBoneSpace scale: 1.00 1.00 1.00 rot: -0.06 0.16 -0.02 -0.98 trans: 8.56 -0.00 -0.78
ChildModelSpace scale: 1.00 1.00 1.00 rot: 0.17 0.64 0.45 0.60 trans: -24.30 -12.23 95.46

Is there a way to do what I want without converting everything to matrices and doing all of the decomposition? Or is there a better way to do the decomposition?

# ¿ Aug 4, 2009 20:12

more falafel please: Feb 26, 2005; forums poster

OneEightHundred posted:

You're looking for N where P * N = C

You're solving it as P * C, the correct solution is P' * C

(In other words, concatenate the child to the INVERSE of the parent's matrix to get its location in the parent's space)

Inverting a translate = Negate
Inverting a scale = Reciprocal
Inverting a quaternion rotation = Negate the X, Y, and Z, or negate the W

If you want to do it with matrices, I'd strongly recommend switching to 3x4's as they're less error-prone. If you're using SSE3 or vertex shaders to do transformation then you want them in 3x4 anyway.

Also scale fucks everything up because the correct order depends entirely on whether the scale is before or after the translate.

No, I've got the child in the parent's space already, so I'm looking for C. Sorry if I didn't make that clear.

TSDK posted:

Double post!

I'd double check this as well. The way you've written that looks like you're constructing ParentTM and ChildTM ordered as if you're using DirectX row matrices, and then combining them with an ordering that looks like you're using OpenGL column matrices. Which would be bad.

Ugh, of course that matters -- which means my decomposition math is all wrong because I got the math from a website that I assume is doing DirectX, but this is another coordinate system altogether (it's some hosed up left-hand inverted Y thing)

# ¿ Aug 4, 2009 22:14

more falafel please: Feb 26, 2005; forums poster

There were two problems:

One, I was multiplying parent and child in the wrong order, and two, I'm pretty sure I wasn't decomposing the result right. I did find a class in the codebase that has a 4x4 matrix ctor (with no scale component) and stores rotation and translation. So I used that and did the scale calculation manually to simplify the code, and by gum it worked.

Thanks.

# ¿ Aug 7, 2009 17:03

more falafel please: Feb 26, 2005; forums poster

Sindow posted:

I know DirectPlay is depreciated and Microsoft is removing support for it so they can push their stupid Windows Gaming Live! bullshit, but does anyone know what platforms it will still work on? They say the dlls were removed from Vista but according to this website, the dplay dll is still in Windows 7. I would assume that means that the NAT Traversal stuff is still in there, but how well will it work?

Games For Windows Live! uses the XBL APIs, right? Because trust me, it doesn't get much easier to use than the XBL APIs.

# ¿ Aug 11, 2009 16:07

more falafel please: Feb 26, 2005; forums poster

Doh004 posted:

How viable is C# for game development? I imagine XNA plays a big part in this. I just started a full time job where I develop C# and Silverlight stuff, so I'd hope I get good enough at this stuff to be able to make games with it.

(Awesome, new page with a stupid question)

It's perfectly viable, XNA is pretty powerful. It's also pretty easy to get up and running, especially for 2D stuff.

# ¿ Aug 15, 2011 22:12

more falafel please: Feb 26, 2005; forums poster

OneEightHundred posted:

I think there are still practical issues, mainly with input and sound.

Well, I mean if you wanted to scale XNA up to the quality of game on XBLA there really isn't anything about XNA that's stopping you. It has a very high capability ceiling. What stops anyone is the lack of a good platform for it, i.e. a decent asset pipeline, physics boilerplate, etc.

The asset pipeline does leave a lot to be desired, but for physics, BEPU isn't bad.

# ¿ Aug 18, 2011 22:27

more falafel please: Feb 26, 2005; forums poster

Xik posted:

Yeah that's the ticket thanks, looks like it will give me some initial reading.

I remember it being very briefly touched on in the context of a command stream and undo/redo in game programming patterns, but if anyone has anything like this with more design tips/gotchas etc that would be cool.

My big lesson from shipping multiple lockstep-networked AAA titles: your biggest problem is going to be error/desync detection. The approach I've used in the past is to make a system that can record lightweight log entries (__FILE__/__LINE__) and generate a CRC of the new logs every frame. Record the CRCs (and, in debug, the logs themselves) in your replay file and during playback compare them (for networked games the equivalent is to send the CRC over the wire and compare it) -- if they're different, dump the logs so you can diff them and find where it went wrong. 95% of them will be either uninitialized/uncleared statics or improper usage of rand(), at least if you happen to be working on a title that still has code ported from 90s arcade machines and a lead gameplay programmer who literally never tests the game online.

# ¿ Sep 26, 2019 01:31

more falafel please: Feb 26, 2005; forums poster

Rocko Bonaparte posted:

This is a continuation of my suffering that you might have had to see in the gamedev Discord. I figured out that after updating Unity to 2019.2.17f1 and VS2019 that I could not longer step into my own DLLs. My workflow is to copy the .dlls and .pdbs into Assets/References, let Unity munge on them (generate .mdbs), attach, then start the scene. Usually that's enough. VS2019 definitely is reporting that it can't find the symbols.

Last night, it wouldn't even let me explicitly load symbols. The dialog wouldn't bother to come up. Manually setting symbol paths was useless. I ultimately just set VS2019 to update overnight. Today, I figured out one important thing: apparently you need to build your PDBs as portable PDBs:

https://forum.unity.com/threads/automated-mdb-generation.755237/

This wasn't enough to solve my problem. I made those changes for the projects I was trying to step in particular, and I still couldn't step in. On the other hand, I finally got the old file dialog when trying to load symbols. VS2019 just refused to recognize the .pdb file was being the one it wants.

On the other hand, if I open the project for the external DLL and attach to Unity from there, I can walk around in my own code just fine. I just can't go back and forth with the Unity project and the code in the DLL, which is frustrating because I'm debugging integration right now.

I did this update a few months ago, and I think it first started then, but I treated it as basic upgrade pains and it wasn't really getting in the way. I just dealt with it at that time.

I've also generally noticed that there's a lot of pain and suffering trying to attach. Usually this manifests as Unity hanging until I disconnect the debugger. Sometimes it works afterwards. Should I move off that particular Unity version?

I should also note that I have VS2017 and an older version of Unity still sitting around in case that can be causing interference. I'm not actively using them, but who knows?

I'm only using Unity on consoles at the moment (and 2018 at that) but my experience is that debugging kinda works, occasionally, and for no reason, then stops working again. I don't care for Unity.

# ¿ Apr 2, 2020 21:56

more falafel please: Feb 26, 2005; forums poster

Tip posted:

I had what I thought was a pretty great release window for my game up until I got coronavirus and was knocked on my rear end for two months straight. Now we're delayed, and running out of money, and it looks we're going to have to launch around the same time as the steam summer sale.

I feel like it would probably be a bad plan to launch during the sale, as even an aggressive launch discount will be overshadowed by games that are like 60% off.

After the sale I feel like people are going to be all spent out for a while, with a bunch of new games to play. But I have no idea how much that actually affects the launch of a new game, or for how long.

Am I overthinking this? Anyone have any insight?

I'm terribly sorry and I'm sure your game is great, but if you're trying to make money off an independent game on steam you either need a time machine to 2015 or a slot machine that always hits jackpot

# ¿ May 15, 2020 07:53

more falafel please: Feb 26, 2005; forums poster

xgalaxy posted:

I thought it was interesting and funny to discover that Minecraft Dungeons is made with Unreal Engine.
I would have thought they would have just built on the existing Minecraft C++ engine.

Unless you really need to reuse a lot of poo poo from a custom inhouse engine written by an incel it probably makes sense to start over in something that you don't have to spend half your development time hacking it up to make it work for your game

# ¿ May 23, 2020 00:40

more falafel please: Feb 26, 2005; forums poster

OneEightHundred posted:

There's other stuff you can reuse too (i.e. gameplay systems), but it's mostly a function of how similar the game you're making is to the one you already made, and Minecraft Dungeons and Minecraft have almost nothing to do with each other aside from the art style.

Yeah, this is my point. A company I used to work for tried to make a God of War/Batman-style action adventure game in their extremely custom fighting game engine and it was basically the worst idea

# ¿ May 23, 2020 21:23

more falafel please: Feb 26, 2005; forums poster

Tip posted:

Back in 2000 there was an FPS called Project IGI that was built on a flight simulator engine. It was pretty neat at the time because the maps and draw distances were huge compared to most other FPS.

https://m.youtube.com/watch?v=f_9LtmxDPiI

NBA Ballers (and Ballers 2: Phenom and Ballers 3: ~~Contractual Obligation~~Chosen One) were built on a flight sim engine, with some wacky +Z down coordinate system.

# ¿ May 24, 2020 05:23

more falafel please: Feb 26, 2005; forums poster

roomforthetuna posted:

The problem is there is no really good solution. Some games want a third-party server controlling everything, some games want one of the players to be the server, some want to be peer-to-peer, some want to transmit state, some want to transmit only timestamped changes to state, some want to transmit only timestamped *inputs* that provoke changes to state... Each of the options has advantages and disadvantages, so you can't really make a "one networking solution" that isn't poo poo for somebody.

It's definitely not one-size-fits-all but UE4's replication system can handle all of the situations you mentioned. It's not a great option for lockstep games, but that's a pretty niche category (and the networking side of lockstep games isn't the hard part, it's making your simulation 100% deterministic with the same inputs, and handling rollback if you're doing rollback).

# ¿ Jun 21, 2020 19:47

more falafel please: Feb 26, 2005; forums poster

Just want to vent about a certain C#-based engine that supposedly supports a certain mobile-like console platform but implements the C# file operations by assuming that any file path you specify should be under the "Rom:/" mountpoint and will prepend it if the path doesn't start with "Rom:/", meaning that if you want to read or write ANY FILES NOT INCLUDED IN YOUR PACKAGE then you need to write a separate native library that implements any file operations you might want to do and rewrite all your code that uses File.* or Directory.* to use your poo poo instead. Oh also this platform crashes if you attempt to access a file that doesn't exist, you cannot handle the exception

# ¿ Jun 24, 2020 19:12

more falafel please: Feb 26, 2005; forums poster

I imagine it would be much harder to get your stuff approved by the Nevada Gaming Commission/whatever similar entities if it's on an engine they're not familiar with. If you're using a binary Unity build they've already audited, it's probably much easier.

# ¿ Sep 14, 2020 17:21

more falafel please: Feb 26, 2005; forums poster

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 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.

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

more falafel please: Feb 26, 2005; forums poster

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

more falafel please: Feb 26, 2005; forums poster

ddiddles posted:

I was going to try and recreate the quick 2v2 matches you get in COD but make it more goofy/cartoon-y and with a top down/orthographic camera so I didnt have to deal with two sets of animations. I thought adding in the fun of physics gameplay would be interesting, but you are right, I'm breaking off too much for the first go through, I cant even imagine how you go about syncing a ragdoll to other clients.

The physics part should definitely come later/in another game, I feel like I'm overcomplicating it. My main goal is to just make something stupid you can play with your friends using P2P and it'll run on a 10 year old machine.

Speaking of physics, I found that even syncing a physics based bullet that travels pretty slow can desync very easily, would you recommend just doing a hitcast and simulating bullet travel?

If the bullet's trajectory is deterministic once it's fired, there's no reason to sync that over the network. As long as all clients (and the server if there's a separate server) know the origin/orientation of the bullet, they can all simulate it locally. Depending on your network model, you may need one of the machines to be authoritative about what that bullet hits, but the visual/audio/etc simulation can be done separately.

# ¿ Nov 6, 2020 20:45

more falafel please: Feb 26, 2005; forums poster

xgalaxy posted:

Looks like Unreal Engine 5 is reintroducing a scripting language to live alongside blueprints.
It�s a completely new scripting language from the ground up specifically for UE.

https://twitter.com/saji8k/status/1339709691564179464?s=20

Havn�t watched the video yet. Looks like:
- first class support for coroutines based on the "Wait*" functions.
- some sort of pointer type, possibly in the vein of Swift
- significant white space

$5 says it's effectively text-based Blueprint, which is just visual UnrealScript (Blueprints are compiled to UnrealScript bytecode). It'll be easier to diff/merge at least!

# ¿ Dec 18, 2020 18:53

more falafel please: Feb 26, 2005; forums poster

Narzack posted:

Does anyone have experience with writing text adventure/interactive fiction? I'm wondering what the best accepted practice is- right know, I'm writing most of the text in word, just to get the n arrative and ideas down. After I get that sorted, I plan to explore the different engines to start inputting all the information. Is this normal or backwards?

Twine is the typical engine used for text adventure/narrative games -- I imagine even if you're planning on putting it in a different game, a tool like twine would be useful to organize your structure beforehand.

# ¿ Feb 1, 2021 22:31

more falafel please: Feb 26, 2005; forums poster

Tip posted:

Thanks, I'll have to check these out!

Vivox might actually be totally fine on it's own since it supports up to 5000 simultaneous users for free. If I ever hit the point where that's not enough, well, that's a problem I will be happy to have (and should have the resources to handle at that point).

Vivox is reliable and pretty standard too. Basically every game I've worked on the last 7 or 8 years has used it.

# ¿ Feb 22, 2021 04:22

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 12:23

more falafel please: Feb 26, 2005; forums poster

Aeka 2.0 posted:

I'm kind of in a desperate situation. I need to reach out to someone who works for Microsoft, specifically on the new halo game. I'm working on a project for this. But I'm like with a sub sub contracted company and getting info to complete this has been absolutely painful. Like I can't do it without getting in touch with someone. It has to do with art assets. I'm posting here because I really don't know what to do. hah.

"I need such and such information from <company you're contracted by>, and I'm completely blocked on this task until I have it, here's why." This is a production problem -- force it up the chain and make it clear every step of the way that you can't do your job without this information.

# ¿ Mar 8, 2021 15:27

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

«‹›2 »