hannesnisula

There are several different ways of doing all of this. From what I've read it seems to be common to move the objects, detect a collision then solve the intersection by moving it along a vector make the objects not intersect anymore and then apply some force/impulse to make it bounce (if that's what you want, otherwise just move them apart).

 

 

The first circle to the left might be where the intersection is detected and the red vector is the direction it has been moving. Then moving it along the normal of the surface (green vector) it would appear sliding along this plane. This might be sufficient for your application.

 

EDIT: Just realized the image is a bit misleading. The image implies the sphere that is intersecting the plane still is moving along the red vector but my point is that it has moved along its entire vector and should only be moved "up" along the plane's normal. But the red vector is the direction it has already moved (to get to its current position). Sorry, this is perhaps quite confusing. If you have any questions about this, please ask.

In Unreal Engine 3 they support multiple weight sets for meshes so they can have limbs detached but not having weird artifacts where the removed bones are influencing the body (described a little bit here).

 

My question is, do any of you have an idea how this might be done? I've been thinking they store each part/limb in its own vertex buffer and swap the buffer used depending on the weight set wanted. They also say that when exporting meshes from 3d modelling software "There is no performance penalty for creating your skeletal meshes this way. The individual parts are all combined when being imported into Unreal Editor." Does this mean they are all stored in the same buffer? Otherwise it would be a penalty right?

 

When having an object (in this case a humanoid) that's rigged with a skeleton and have multiple meshes (parts of the body), how are they connected? Let's say I have a class for objects like this and I want to be able to cut off limbs and having these limbs be completely separate objects, should the bones from the skeleton have a mesh associated with them? Because some parts may contain several bones (like the hand) and I want to keep the hand like 1 logical object and not destructible, how can this be structured in the code?

 

Let's say I want the forearm and hand to be one atomic part of the body and it contains multiple bones from the skeleton and perhaps several different meshes (maybe not this exact case, but there are other cases). If this is an object of its own, it's not clear to me what would be this objects transform, as there are several bones inside of it with their own transforms. Does anyone have experience with similar stuff?

 

I'm not sure I was sufficiently clear about these questions, and there are a lot of them, and if so I apologize and just ask and I'll try to clarify.

I'm actually working on my own network code right now and perhaps not able to give great answers, but here's my 2 cents:

1) Yeah that's true, though I would guess that the sorting etc in the hardware could be ignored because its done so much faster than the "network" part(?).

2) To handle the connection abstraction for the game (and other stuff) I have a Connection class that contains all connection specific information, like received sequence numbers and send sequence number, along with a timestamp for the last time it was active (received a packet). I use this timestamp to every frame check if the time since this timestamp exceeds some time I've decided is the time out time. If this is the case I just close the connection.

I don't know if having this information in the packet itself brings any advantages, but it might work.

3) I haven't actually encountered any case where my packet order makes a difference so I've completely ignored this (apart from discarding old update packets, since they're old). Do you have any case in mind? Like what packets must be ordered in your situation? If packet order is required I would assume it's a pain to handle this in software for UDP. TCP could be a good choice in this case.

4) I've heard some numbers that generally there's a less than 5% packet loss when on a line connection, which probably varies a lot too. I have some packets that needs to arrive, like console commands (chat messages, name changes) so I made it possible to send "reliable" packets with UDP with a simple ack/resend system (all packets contain 33 ack numbers in 8 bytes like described by Gaffer here). I've heard of some other ways to try to minimize impact of packet loss, like sending the same important packet several times and hope for the best.

You are basically the one deciding if it matters or not if packets are lost. If you are worried only about object updates it doesn't really matter. Resending old updates because it was lost, doesn't help since it would make that update packet outdated anyway.

5) Well it depends on the game, but the standard server client architecture nowadays is basically what you're describing, with some interpolation/prediction of objects' positions etc.


I like UDP since it has no "unnecessary" features for my project (like packet ordering and blocking for lost packets) and it's basically what I needed, except the resending of lost packets that I made the game handle.
UDP vs TCP comes down to the requirements of the program really. If you need packet ordering then TCP might be the best choice. If you are only sending real time updates, and no resending of lost packets nor packet ordering is needed, the UDP seems like a good solution.

Are you planning on writing code or just learning about networking in games (specifically (MM)ORPGs)? If you're planning on writing something, what platform and language are you using, and what platforms are you targeting?

he game specific aspects of networking isn't bound to any programming languages. There are many different networking libraries out there, but the only one coming to my mind now is RakNet. If you want to do it more low-level (perhaps for learning) you might want to check out WinSock if you're on Windows.

bump

I started to write some code for weapons and firing them when I realized the structure of the game code was a bit weird. I store an array of players in my Game class, I store an array of enemies in my AIManager class but I didn't know where to store the projectiles. I wanted to store the projectiles in Game first, but I can't "put it there" because Game includes Projectile.h and Projectile.h would then have to include Game.h to be able to call its methods, right? Now I wonder how a good way to structure all of the game code would be. It's a very broad term I know and there are probably very many different ways to go about it.

Say I have stored my projectiles somewhere and then I want to detonate it and deal damage to everyone around it, then I need access to all players and enemies and perhaps doodads to check the distance and calculate damage. But how do I access it? What's a general good advice? I thought of sending a pointer to the array of objects to be possible victims but then again I stored all objects in different arrays depending on what kind of object, and in different places and I then I took a break.

What are some general ways to structure this whole mess? I want to have some kind of decoupling of the responsibilities. For example the renderer class is separate from everything. I would like the objects to handle themselves like the projectile would do the exploding itself and doing damage in its own method or something similar.

I suppose the question is kind of unclear and I'm sorry for that, but I don't really know how to put it in a different way. I'm very thankful for any input I may receive!


EDIT: I was thinking of a system where every object handled everything themselves, collision detection and response, updating health points, animations and other possible events. I was looking at the SC2 map editor and it seems kind of complex but incredibly powerful and flexible. Are they doing something close to this?

Right now the code is kind of like containers of players, projectiles, enemies and the Game performs the calculations and updates, I suppose it would generally be a better idea to leave this to the individual objects considering they do different things in their updates. But then I imagine everything would be like a huge array of objects that are just looped through and have their Update method called, more or less. What are you thoughts on this?

I love the C++ Win32 API. Straight forward and intuitive as well.

Yeah I was considering multiple references to large objects from multiple nodes. But my idea was to loop through objects in the nodes and send to the render queue for rendering, but if I have multiple entries either I will have to have some flag to set when sent to rendering, which seems like a bad way to go. So then I'm thinking that placing it at a higher level in the tree would be a better idea, but I was hoping to avoid the (in almost all cases) unnecessary walk through the tree (upwards).


Well I suppose storing objects in appropriate tree levels would solve the problem pretty well though. But I'm still wondering if someone has a solution to the fact that objects' spans will sometimes span outside of the nodes' bounds. Could it be a good way to go about doing this if I'm using some bigger view frustum for culling? It seems like a crappy hack though. Any ideas?

Hi!

I was thinking I would store everything in my world in a quad tree and I thought I had it all solved and settled. So I thought I was going to store the terrain patches in (not the lowest) level of the quad tree and the objects, both static and dynamic, in the lowest levels/leaves. Also, I thought the rule that every item would only be a child of 1 quad tree node would make it easier to do things in the code.

Then it hit me that how do I decide in what node will the object be in? Well, the only reasonable solution would be in the node which the position of this object is in. But then I thought of bigger objects, and also smaller. If I was going to use the quad tree for visual culling some objects might be culled though the item actually intersects the view frustum and hence the object will pop up when I turn around or move.

Another idea I was having that perhaps (?) I might get a performance boost (a small one) if I store adjacent nodes in each lowest level-node for collision detection, for I've planned to do collision detection against objects in the object's node and also those around it to avoid errors if close to the edge. But then if some objects might be huge (castles and stuff) they might overlap with one of the adjacent nodes but not being checked for collision against. This might be solved with bigger lowest level-nodes or having to chop up big objects to fit in one node.

I wonder what are the general solutions to this? I thought I had it all planned but now I'm hesitating on how to do this.

I thought it was possible to loop through parent nodes in the quad tree for collision detection so the big items could be stored there, but I want to avoid this.

No point in not continuing with C++ as it's a very powerful and straight-forward language.

LOL, anyone that calls C++ straight forward, doesn't know C++ that well.

I'm sorry you have trouble with C++ but that doesn't mean everyone have any trouble with it. I'm kind of curious about what's not straight forward, mind giving me some examples?

I don't have trouble with C++, it is simply not an intuitive nor clean language.  All it takes is about 8 seconds looking at the STL libraries to see the inherit complexity in C++.

One easier way is to look at the language spec sizes.  The initial language spec was 3 times the size of the C language spec and on top of that WAS a super set of C.  This is completely ignoring the ongoing iterations of the language up to C++0x which is a horrifically byzantine language ( the working draft you can read here ).

Even among C++ developers, I do not think there is a good C++ developer alive that wouldn't in fact agree that the language is anything BUT straight forward.

Also, you do yourself a disservice assuming making assumptions about my ability with a language.  Simply because something is complicated does not mean people can't master it.  I learned the English language extremely well, but after encountering their/there/they're I don't think many people alive would call it a straight forward language.

I never said you didn't master it, but you find it complicated. I don't, and I also find it very intuitive. The problem here is that you have decided the language is universally complex and unintuitive, though apparently not everyone agrees. Personally I think all managed languages are crap and I dislike them all, because of the fact that they're managed languages. Note that I'm not saying that everyone who likes them are bad programmers.

"Also, you do yourself a disservice assuming making assumptions about my ability with a language." Says the guy who just said I'm don't know C++ that well. You even assume people that say they find it intuitive are just liars, stupid or incompetent in C++. The irony is hilarious.

Good luck whatever language(s) you use and I'll go back to use the one I find easy to use (despite what you say).

I so love being paraphrased... incorrectly.

I never once said C++ users are bad programmers.  I never once called you (nor anyone else) a liar, stupid or incompetent.

I did, and do, state that your comments regarding the complexity of C++ are wrong, especially given the forum in which you expressed them.  One person's ease at intuiting a complex situation does not change the complexity.  An idiot savant ( no... not insulting you ) can calculate high order mathematics problems, but that does not alter their overall complexity.  I did however imply that good C++ programmers would agree that C++ is a complex language, especially when compared against other languages as this thread is.

Your outright dismissal of managed languages for their being managed is telling however.

I give up. Trying to talk to someone who first states one thing, then denies it, is useless. By saying that every good C++ programmer would agree C++ isn't straight-forward, intuitive, complex etc also implies that anyone who says it is, is therefore not a good C++ programmer. I thought that was obvious but no problem, I just explained it.

Judging if something is complex or not is based on how you perceive it.

Also, my "outright dismissal of managed languages" is because there's little/no possibility to optimize performance by minimizing cache misses, depending on the exact situation. And instead of passing pointers around sometimes it's required to use for-loops and call functions to "cast" between different variable types.

No point in not continuing with C++ as it's a very powerful and straight-forward language.

LOL, anyone that calls C++ straight forward, doesn't know C++ that well.

I'm sorry you have trouble with C++ but that doesn't mean everyone have any trouble with it. I'm kind of curious about what's not straight forward, mind giving me some examples?

I don't have trouble with C++, it is simply not an intuitive nor clean language.  All it takes is about 8 seconds looking at the STL libraries to see the inherit complexity in C++.

One easier way is to look at the language spec sizes.  The initial language spec was 3 times the size of the C language spec and on top of that WAS a super set of C.  This is completely ignoring the ongoing iterations of the language up to C++0x which is a horrifically byzantine language ( the working draft you can read here ).

Even among C++ developers, I do not think there is a good C++ developer alive that wouldn't in fact agree that the language is anything BUT straight forward.

Also, you do yourself a disservice assuming making assumptions about my ability with a language.  Simply because something is complicated does not mean people can't master it.  I learned the English language extremely well, but after encountering their/there/they're I don't think many people alive would call it a straight forward language.

I never said you didn't master it, but you find it complicated. I don't, and I also find it very intuitive. The problem here is that you have decided the language is universally complex and unintuitive, though apparently not everyone agrees. Personally I think all managed languages are crap and I dislike them all, because of the fact that they're managed languages. Note that I'm not saying that everyone who likes them are bad programmers.

"Also, you do yourself a disservice assuming making assumptions about my ability with a language." Says the guy who just said I'm don't know C++ that well. You even assume people that say they find it intuitive are just liars, stupid or incompetent in C++. The irony is hilarious.

Good luck whatever language(s) you use and I'll go back to use the one I find easy to use (despite what you say).

No point in not continuing with C++ as it's a very powerful and straight-forward language.

LOL, anyone that calls C++ straight forward, doesn't know C++ that well.

I'm sorry you have trouble with C++ but that doesn't mean everyone have any trouble with it. I'm kind of curious about what's not straight forward, mind giving me some examples?

No point in not continuing with C++ as it's a very powerful and straight-forward language.

The device is initialized and the clear and present functions work and I also call Begin and End before and after the the renderTriangle function. I suspect I've missed something obvious but I can't come up with what that would be. I've initialized the vertexbuffer and filled it with the data for a single triangle, set the FVF, matrices (I've tried both having the camera at 0,0,-10 and 0,0,10 because I got tired and didn't bother thinking about from which way I should see the triangle because of culling) and I render it but nothing shows on screen.

public void initializeTriangle()
		{
			testVertices = new float[9];
			vb = new VertexBuffer(device, sizeof(float) * 9, Usage.WriteOnly, VertexFormat.Position, Pool.Managed);

			testVertices[0] = 1.0f;
			testVertices[1] = testVertices[2] = 0.0f;
			testVertices[3] = -1.0f;
			testVertices[4] = testVertices[5] = 0.0f;
			testVertices[6] = testVertices[8] = 0.0f;
			testVertices[7] = 1.0f;

			Matrix view = Matrix.LookAtLH(new Vector3(0.0f, 0.0f, 10.0f), new Vector3(0.0f, 0.0f, 0.0f), new Vector3(0.0f, 1.0f, 0.0f));
			Matrix projection = Matrix.PerspectiveFovLH(2.0f, 1.0f, 1.0f, 100.0f);
			Matrix world = Matrix.Identity;

			device.SetTransform(TransformState.Projection, projection);
			device.SetTransform(TransformState.View, view);
			device.SetTransform(TransformState.World, world);

			device.VertexFormat = VertexFormat.Position;

			DataStream stream = vb.Lock(0, 0, LockFlags.Discard);
			for(int i = 0; i < 9; ++i)
				stream.Write(BitConverter.GetBytes(testVertices[i]), 0, sizeof(float));
			vb.Unlock();		}

public void renderTriangle()
		{
			Result res = device.SetStreamSource(0, vb, 0, sizeof(float) * 3);
			res  = device.DrawPrimitives(PrimitiveType.TriangleList, 0, 1);
		}

Is what you're trying to do anything like this?: http://laserbrainstu...-optimizations/

No, the problem is how the Object class will relate to the Mesh class. I have some requirements I can't seem to fulfill without feeling it's a cheap hack.

- Some objects will logically be treated as a single object though consisting of several meshes/submeshes (like a house with windows and walls etc). So this could be satisfied with an Object class related to a Mesh class in turn consisting of several Submeshes.

- Some other (like humanoids) are supposed to be destructible, as in limbs detached and then treated as individual objects. If I had a Mesh class consisting of a number of Submeshes this could be solved by having each child object of the humanoid connected to a submesh each. But then if it's destroyed how is this handled with the mesh? Would I create a new Mesh instance with a single subset, the submesh it's connected to? And it would also require each child object of the whole humanoid object (the limbs) to be of a special kind to be connected to Submeshes instead of Meshes as in the other cases.

I've only come up with 2 solutions I don't like, which are that every Submesh of every Mesh (as they are created) are really their own Mesh so there would be no Submeshes at all, but this would produce the problem with having an object consisting of several Meshes/Submeshes. The other is that a Mesh consists of a number of Submeshes and if a destructible object with several parts would then create more and more instances of Meshes with a single Submesh (which comes from another Mesh consisting of all related Submeshes) when detached from each other.

How is this generally handled? Is there even a general solution? What are your opinions?