Game Development Megathread

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

«‹›2 »

Vinlaen: Feb 19, 2008

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

# ¿ Feb 29, 2008 22:29

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 05:02

Vinlaen: Feb 19, 2008

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?

Vinlaen fucked around with this message at 00:30 on Mar 1, 2008

# ¿ Mar 1, 2008 00:19

Vinlaen: Feb 19, 2008

Subotai posted:

You could try raknet.

krysmopompas posted:

Or OpenTNL maybe?

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?

# ¿ Mar 1, 2008 17:59

Vinlaen: Feb 19, 2008

krysmopompas posted:

Use a fixed size, resolution independent grid for gameplay purposes, then render the map by dynamically generating a mesh using triangles that connect contiguous spans of "ground" in that map. Once you get that working, you can start worrying about view dependent refinement of the mesh as well as optimizing it.

If I understand the first part you're saying to use a terrain size that is the same regardless of resolution (eg. let's say 1000x3000 "terrain units"). I agree with this and was planning to do that...

However, I'm not sure what you mean by the second part (eg. generating a mesh using triangles, etc). I always forget what a mesh is because I've been trying to do 2D programming and "mesh" is usually used when talking about 3D programming...

Vinlaen fucked around with this message at 20:01 on Mar 1, 2008

# ¿ Mar 1, 2008 19:57

Vinlaen: Feb 19, 2008

@gibbed: You're basically saying to have a huge array (1 bit per pixel) that says it's solid or not-solid, right? (eg. used for collision detection?)

@krysmopompas: Is that the algorithm for transforming resolution coordinates into terrain coordinates? (eg. a 1920x1200 resolution into the 3000x1000 terrain resolution)

@pee: I think that's the same idea gibbed is talking about...

I think I understand everything, but I'm still unsure of how to build the visual part of the terrain.

For example, I want to use several textures to create the terrain (eg. a mountain texture, then place river textures through it, etc, etc). This "visual terrain texture" would need to be HUGE for resolutions like 1920x1200 which is where I'm getting confused. The reason I'm thinking it will be huge is because instead of re-drawing my small terrain textures (eg. the mountain texture) over and over, I'll actually be creating a new texture composed of all the other textures...

# ¿ Mar 2, 2008 04:17

Vinlaen: Feb 19, 2008

I still need a massive 1920x1200x32bit * (amount of screens of terrain) texture though, right? (when using 1920x1200 resolution)

The reason I keep coming back to this is because I'm going to build the visual terrain using many smaller textures, etc. I'm concerned because 1920x1200x24 * 5 screens is a massive amount of texture memory and may not work on older video cards

Vinlaen fucked around with this message at 02:22 on Mar 3, 2008

# ¿ Mar 3, 2008 02:20

Vinlaen: Feb 19, 2008

SnakeByte posted:

Well older video cards can't handle screens that big. But then again, older video cards won't be doing 1920x1200 either. I think I understand what you're missing here. When you create a texture, it doesn't HAVE to go to the video card. It can be kept in system memory until it is ready to be drawn. So you're video card will only have to keep enough texture information to cover one screen. There's no sense is drawing what you can't see. Does that make sense to you?

Yeah, I've seen that you can actually create a texture in system memory (with D3D) and then transfer it to the video card when needed. Is this what you're talking about?

If so, I'm guessing that you are talking about tiling a bunch of large textures, and then as the user scrolls around the map you re-upload the textures to the video card as needed. All that will be stored on the video card at any time is one texture the same size as the screen resolution plus maybe some "partial" textures so that if the user scrolls around it doesn't need to load a new texture until they scroll past a certain point.

Does that sound right?

The only problem with this is that you can't use textures in system memory as render targets (which would make drawing explosion circles or whatever a LOT easier...)

# ¿ Mar 5, 2008 15:34

Vinlaen: Feb 19, 2008

So you're saying to destruct the active terrain tile texture (which is on the video card) and then copy it back to system memory?

# ¿ Mar 6, 2008 05:27

Vinlaen: Feb 19, 2008

What are some of the most complete game engines for a indie developer?

I'd like an engine to support simple networking (eg. synchronizing player movement) and allow me to create objects for the player to interact with.

For example, I'd like to create an alarm clock that players can select and it would prompt them for a time (eg. custom scripted dialog box), and then at a set time everybody on the server would have an event fired making them lose health or whatever.

I don't want to have to worry about the engine at all (eg. object selection, collisions, networking, etc).

Does anything like this exist at all?

# ¿ Apr 23, 2008 20:50

Vinlaen: Feb 19, 2008

Nuke Mexico posted:

Look at Ogre 3D or Torque

HB posted:

The Torque engine from GarageGames would do that. Or Unity.

Thanks for the suggestions!

Unfortunately, Unity3D can only be authored on a Mac and I actually own Torque but it's incredibly difficult to modify and requires hard-core C++ knowledge to do anything "outside the box". (eg. anything except a FPS)

Also, Ogre3D is only a rendering engine and won't do anything else... I'm looking for a one-stop complete package

# ¿ Apr 23, 2008 22:40

Vinlaen: Feb 19, 2008

HB posted:

If you don't intend to sell your game, you could make it a total conversion for an Unreal or Source title.

And I didn't realize Unity didn't have a Windows editor.

That would require everbody to own Unreal if they wanted to play it

Maybe nothing exists like I'm trying to find...

(I'm sorry if it seems like I'm being difficult!)

# ¿ Apr 23, 2008 22:49

Vinlaen: Feb 19, 2008

Darnit -- double post.

# ¿ Apr 23, 2008 22:50

Vinlaen: Feb 19, 2008

I'm still trying to create my 2D Worms game and still having trouble... (yes, I'm stupid or something). This was discussed back on page seven but I'd like to bring it back up in case anybody has any new ideas. The suggestions given to me before I didn't quite understand (eg. using a mesh for the 2D terrain deformation, etc)...

Anyways, I'm trying to create a 2D worms game and I'm having some difficulty in figuring out how to store the terrain.

My plan is to create an algorithm that generates terrain by combining several images together to get one final texture. For example, I'll start with the shape of the terrain then fill in mountains, add grass on top, add rivers to the inside, create caves, etc. However, in the end I will just have one very, very large texture.

However, I also plan to allow very large resolutions (eg. 1920x1200 [my 24" monitor's native resolution], 1280x800 [laptop's native resolution], etc), and thus this requires massive amounts of video memory and lots of textures.

For example, if I want to use 1920x1200 (w/32-bit color) and have 6 screens worth of terrain (3 screens wide and 2 screens high), then it will require 55 MB of video memory. Even 1280x800 requires 24 MB of video memory.

The other problem is that typical maximum texture size is only 1024x1024 so I'm guessing I'll need to split my image into many, many smaller textures and then figure out which ones to deform when a collision happens, etc.

Am I approaching this problem wrong? It seems like 1920x1200 * 6 screens just requires a ton of video memory and there is no way around it...

# ¿ May 9, 2008 21:00

Vinlaen: Feb 19, 2008

Pfhreak posted:

I'm going to take a stab in the dark here, because I'm not sure if this solution would work, buuuut, couldn't you build a big 2 dimensional array, 1920x1200, and store bits in it? 1 for visible/collideable and 0 for not? Then, you can break up your giant level texture into smaller pieces, and use the bit field to determine whether that section of the level should be drawn?

Yeah, I was thinking about that. Actually I'd use a static resolution-independent texture size (eg. array) that just contains 1 or 0 (for solid or not solid).

Pfhreak posted:

Also, you could only send the visible pieces of the large texture to the video card. Keep them loaded and ready to go, but only draw them when they are in the frustrum of the player's camera.

You're saying to create my huge (1920x1200x32x6) textures in system memory and then copy only a display resolutions worth of data to the video card? I've thought about this too and think it might be my only option but I'm hoping for an easier/faster solution.

Thanks a ton for the help though!

# ¿ May 10, 2008 02:59

Vinlaen: Feb 19, 2008

If somebody wanted to create a multiplayer tower defense game, what would the best option be?

I'm asking this because I think what I want simply doesn't exist which is a library/engine that provides collision detecion, particle effects, built-in GUI, and "automatic" networking support.

I'm mostly considering XNA but it seems like "Easy-Mode" DirectX with a handful of helper functions for managing input, etc, but it doesn't provide any kind of built-in GUI or networking support (other than allowing you to send reliable/unreliable order/unordered packets).

I'd really like some type of game library/engine that will let me create some sprites on the screen, move them around (providing collision detection) and keep everything in-sync across multiple players on the internet.

I guess nothing like this exists, huh?

What is the closest option available? I've actually purchased TGE (no idea why I did this), TGB (too difficult to do ANYTHING besides what is built-in espicially since the sourcecode is very advanced C++), and BlitzMax.

BlitzMax seems quite popular and not a bad choice (built-in windows, mac, and linux support!), but it doesn't have too many "intermediate/advance" features like using render targets or stencil buffers. It also doesn't have any sort of GUI and it forces you to use BASIC (with a tiny, tiny bit of OOP thrown in)

# ¿ Jul 28, 2008 03:19

Vinlaen: Feb 19, 2008

Vinlaen posted:

and "automatic" networking support.

MasterSlowPoke posted:

Honestly I'd just forget about XNA Game components, they're more trouble than they're worth for someone without any experience.

For your first question, in your Draw method, only draw the objects you want to draw?

How would this work? I need to keep track of all drawable game objects so I need an array or a list or something, right? That list must stores objects of the same type (or interfaces) so wouldn't I need an implement IDrawable or something like that on every drawable object and then add them to the list?

I'm just wondering if interfaces are best or components, or...

# ¿ Jan 12, 2009 13:09

Vinlaen: Feb 19, 2008

Bizarro Buddha posted:

In general you don't want a huge amount of GameComponents, so that working out their behaviour with respect to each other is simpler. If you're going to use them, have a GameComponent that manages moving entities, rather than a GameComponent for each moving entity, for example.

I'm not really sure what you mean here.

For example, I have a TextRenderComponent that renders some text. If I want five entities to render text then I need five TextRenderComponents, right?

Right now I have a hash table for entities attributes for things such as current position, etc. The TextRenderComponent has a pointer to it's parent entity and looks up attributes using that.

Although, I'm just fooling around with .NET and GDI+ and I am already having CPU issues. I'm maxxing a core on a Pentium D 3.4 GHz CPU even with 500 entities with TextRenderComponents attached to them. However, I'm just using .NET with GDI+ and nothing fancy like SDL or DirectX or anything. (I'm staying away from XNA for now)

# ¿ Jan 13, 2009 13:21

Vinlaen: Feb 19, 2008

Fancier than GDI+, right?

One last question...

Are there any good alternatives to XNA for .NET? I'd like to create a simple game that doesn't require the user to install any additional runtime packages (eg. XNA) besides .NET 2.0. I really like XNA but the runtime packages are the dealer breaker. I just want to distribute a zip file with a couple of DLLs and have the user go from there without any installation required.

I've found SDL.NET (which hasn't been updated in over six months) and OpenTK (OpenGL). OpenTK seems nice since it appears to be actively updated, etc, but it doesn't provide any of the utility functions like XNA, etc.

# ¿ Jan 13, 2009 14:27

Vinlaen: Feb 19, 2008

Thanks for the suggestion.

However, it looks like it requires an end-user redistributable package just like XNA. (...or can you just include the DLLs with your executable and not require the redistributable?)

# ¿ Jan 13, 2009 15:31

Vinlaen: Feb 19, 2008

Thanks for all of the help with my other questions but now I have some about networking...

I'm trying to create a "simple" networked/multiplayer 2D game and so I've been trying to a read a lot about networking principles, player synchronization, etc. However, it seems like most articles (eg. gaffer.org) tell you to send keyboard/mouse inputs to the server, have the server process them, and send the results back to the client.

Why?

Is this only done for cheat protection?

What is the disadvantage to sending actual player position to the server and doing a sanity check? It seems like this way is better because then players will know their position even while moving and won't require interpolation or prediction.

Keep in mind that I'm talking about a simple 2D game with different objects moving around, etc.

I'm going to have a bunch of other networking questions I'm sure, and I thought about starting a new thread but hopefully you guys can help me out here.

# ¿ Jan 15, 2009 14:17

Vinlaen: Feb 19, 2008

Does size really matter though?

I can see if you're talking about a 3D FPS where there is constant, fast-paced action but in a Mario Brothers or Legend of Zelda game (simple 2D) then I'd assume that you only send position information when the player is moving. While the player is moving then constant updates are being sent but since it's only 2D it seems like the data wouldn't be all that bad.

It also seems a LOT more simple to have players send position rather than input. By sending position then each player knows where their own character is currently located and doesn't need to wait for the server to tell them and thus you don't need client side prediction (or anything) for your own character.

Sending inputs instead of position seems very complicated

I really appriciate the help though! I'm just trying to understand everything...

# ¿ Jan 15, 2009 16:16

Vinlaen: Feb 19, 2008

Hubis posted:

Your second solution is what Half-Life/Half-Life 2 do. They have the advantage of having less latency -- when you press a key, you move immediatly instead of waiting 2-10 frames to have your input realized.

It sounds like you have the same idea as Mithaldu...

quote:

This is good, but the downside is that (a) you now need to make sure the client has all the relevant world state needed to interact with the world properly (so, more data) and

Can you explain what you mean by this?

quote:

(b) if it doesn't update correctly (say some other player moved in your way for example) then you have to overwrite the local value with one from the server, and then have to deal with "bouncing" or "popping" or "lurching" movement, as the world state is changed. So, in some cases it can be more smooth, while in others (esp. those with high lag/packet loss) it can be worse.

That makes sense but making the player wait 2-10 frames before their character moves seems really annoying. (this seems to be the problem with the Byond engine)

However, let's say I send a "start moving forward packet" and start moving locally on my machine. The server receives this packet (100ms or whatever later) and starts moving my character locally and sends back an knowledgement packet. Does the server then send a position update every few seconds? If so, wouldn't the position be "old" by the time it reached my players machine? ...or does the server predict ahead of time where I will be based on the latency between the two computers?

Also, what happens if the player holds down the up arrow? Do I keep sending packets every XX milliseconds? I'm guessing I would need to keep track of when I sent the last packet and implement a delay.

Finally, do I need to include velocity or any such thing? If the other players aren't using prediction, then if the packet stream is too slow wouldn't it appear as though everybody is bouncing/popping all over the place?

quote:

It's also a simpler design, since all your logic is being handled in one place, and the specialized client-side physics and rollback code is something else you wouldn't have to write anymore. Unless round-trip latency between client and server are a problem, I'd stick with the "dumb client" model.

Are you saying that the server does all the logic and physics? Wouldn't I still need some type of interpolation on the clients to help when packets arrive too slowly (or get dropped) from the server?

I'm really sorry for all of the questions and I GREATLY appriciate your help.

# ¿ Jan 15, 2009 18:47

Vinlaen: Feb 19, 2008

I'm still interested in a reply from Hubis on my questions above, but I also have a few for digibawb...

Are the snapshots you mentioned only deltas from the previous snapshot or is it an entire world state? If it's the entire world state, isn't that a LOT of data to be sending to every client every 50 ms?

Interpolating other player position seems easy enough, but I'm not sure on the re-simulation part of the local player. Is there any easier method for making the local player appear to have fluid controls without waiting for the server? Your re-simulation sounds very complicated...

As for the inputs, I noticed that you said they were sent 15/30 packets per second (from the clients?) but were they only sent if the player changed directions or are you saying that if the player held the up arrow that 15/30 packets per second would simply contain "up arrow"?

Also, my game isn't going to be twitch-based like Quake or other shooters. It's also not going to be in 3D (only 2D with little physics). I'm just hoping to design a system that works nice enough without going overboard (espicially since it's my first realtime networking project)

Thanks so much for the help!!

# ¿ Jan 16, 2009 01:28

Vinlaen: Feb 19, 2008

Well, I'm getting a little frustrated trying to develop my own networking engine (eg. the client-side interpolation stuff and not the winsock/sockets layer).

Are there any 2D engines that take care of this stuff for you? Synchronizing movement in 2D space seems like a fairly common/general type of thing.

# ¿ Jan 19, 2009 01:20

Vinlaen: Feb 19, 2008

Thanks... RakNet is probably the closest thing to what I'll find, but I'm hoping to find more of an engine that already implements RakNet, etc. Ideally I'd like to find something with the features of BYOND but implements much, much better.

RakNet certainly helps things out but you still need to create an entire game engine and then hook it up to RakNet, etc.

I'm not afraid of programming. In fact, I often very much enjoy it, but I don't want to create an entire engine... I just want to program the _game_ (but all my ideas are for multiplayer/networked games) using programming langauges, etc.

# ¿ Jan 19, 2009 01:48

Vinlaen: Feb 19, 2008

Does anybody have any links to any really good isometric tiling tutorials? I've found a few tutorials (including on GameDev) but they all seem to be a little bit lacking or hard to understand.

I'm also trying to remember the name of a website I found (on here I think) that had a small section of free 2D (isometric?) artwork but it was VERY, VERY high quality. It had an article that contained "Most people come here for the free artwork but here is a tutorial..." or something like that. I can't find the site on Google for the life of me though!

# ¿ Jan 21, 2009 14:42

Vinlaen: Feb 19, 2008

I'm able to draw basic isometric tiles without any problem (that's fairly easy) but I'm having trouble with two different things:

1) Drawing tiles with different heights. Eventually I'd like to implement a Final Fantasy Tactics system where each corner of a tile has a different height and can create sloping terrain, but I'll leave this for later since it seems much more complicated. For now I just want tiles with varying heights to create bridges over terrain, etc.

2) Using the mouse to pick tiles. I'm guessing this would get even more complicated given different tile heights too.

# ¿ Jan 21, 2009 15:52

Vinlaen: Feb 19, 2008

Thanks for posting the code.

Could you also use a special mousemap? I found this one gamedev: http://www.gamedev.net/reference/articles/article2026.asp

# ¿ Jan 22, 2009 19:42

Vinlaen: Feb 19, 2008

Ok, what about isometric tile sizes?

Most tutorials online are using 64x32 but I can't seem to draw a perfect diamond inside that size. I've also tried 32x16 but that doesn't work either. However, 32x15 works perfectly.

How are people using 64x32 and drawing perfect diamonds inside of them?

# ¿ Jan 25, 2009 21:32

Vinlaen: Feb 19, 2008

Here is the exact type of map that I'm trying to obtain: http://www.tangerinepop.com/experiments/AS2/YCollision/

Right now I have a very simple, very flat, isometric map that is rendered like this:

code:

For x = 0 to 50
  For y = 0 to 50
    tilePosition.X = x
    tilePosition.Y =y

    m_tile.position = Isometric.Math.MapToPixelPosition(tilePosition, m_tileSize)    
    m_renderWindow.Draw(m_tile)
  End for
End for

It's about as basic as you can get but it works and I also have a very simple function to translate from a pixel position to a map tile. (without using mouse maps!)

However, I'd really like to make my map a little more interesting to having sloping tiles or various height terrain. (eg. think of Final Fantasy Tactics, or the link I've listed above)

How can this be accomplished? I'm assuming that this involves changes to the rendering, collision detection, mouse picking, etc, etc.

# ¿ Feb 5, 2009 20:21

Vinlaen: Feb 19, 2008

How is XNA looking now-a-days? I see that it keeps getting updated and a new version is coming soon (v3.1) which is really great and I'm thrilled that Microsoft has such a dedication to it.

In the past I didn't want to use XNA because I wanted to develop Windows games that didn't have a difficult installation process requiring several different runtimes but it looks like Microsoft fixed the problem with Click-Once installation so I'm not quite as turned off from it as I used to be.

Anyways, is XNA still the best thing for somebody who just wants to create a game without worrying about much of the low-level details?

For example, I'm also thinking about using OpenTk (eg. OpenGL for C#) but it seems like if I'm using .NET (which I'm definitely going to use) than I might as well use XNA.

# ¿ May 7, 2009 15:53

Vinlaen: Feb 19, 2008

Does anybody know of any 3D tiling engines?

I'd like to create something like Final Fantasy Tactics (or Disgaea, etc)...

I've started writing my own in XNA and it's coming along decently but it's very, very slow even with my optimized (which probably isn't very) terrain structure. (eg. I'm creating one single batch of triangles that contains the entire terrain so than I only need one DrawIndexedPrimitives call to the graphics card).

# ¿ May 14, 2009 21:29

Vinlaen: Feb 19, 2008

Does anybody know of a good reference to learn about 2D lighting? (or do any existing engines support 2D tilemaps and built-in lighting with networking capability?)

Jaded Samurai's (work-in-progress) Space Station 13 remake has me inspired to fool around a little bit with creating a remake of my own.

Thanks for any advice!

# ¿ Jan 12, 2010 20:21

Vinlaen: Feb 19, 2008

Oh, thanks!

Do you know of any others off the top of your head? (that support 2D and lighting I mean)

# ¿ Jan 12, 2010 23:06

Vinlaen: Feb 19, 2008

That looks really neat!

What engine/libraries did you use?

# ¿ Feb 3, 2010 12:19

Vinlaen: Feb 19, 2008

Thanks for the info!

How easy do you find Unity?

It's awesome they released the indie version for free but their prices for the professional versions seem a bit high. ($1500) Luckily the indie version has mostly everything but lacks real-time shadows which bothers me.

Also, the iPhone version looks nice ($399) but lacks networking support and requires you to purchase Unity3D Pro ($1500) PLUS iPhone Pro ($1500) which is a bit expensive.

Anyways, I'm still interested in using it. How difficult do you think a Final Fantasy Tactics/Disgaea clone would be?

# ¿ Feb 3, 2010 19:00

Vinlaen: Feb 19, 2008

How do you create rooms and indoor environments for Unity3D? (ie. Neverwinter Nights, etc)

It seems like I need to learn Blender (or Google Sketchup?) but I'm not sure.

What's the _easiest_ way for a programmer who knows very little about modeling to create some simple rooms and hallways with a few textures?

# ¿ Feb 4, 2010 15:24

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 05:02

Vinlaen: Feb 19, 2008

What would you suggest besides Blender?

It seems like I almost want a map editor (like the one for Half-Life 2, etc) so I can create rooms, hollow them out, add textures, etc, etc.

# ¿ Feb 4, 2010 23:45

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

«‹›2 »

Subotai posted:

krysmopompas posted:

more falafel please posted:

krysmopompas posted:

SnakeByte posted:

Nuke Mexico posted:

HB posted:

HB posted:

Pfhreak posted:

Pfhreak posted:

Vinlaen posted:

more falafel please posted:

MasterSlowPoke posted:

Bizarro Buddha posted:

Hubis posted:

quote:

quote:

quote:

code: