Jump to content

  • Log In with Google      Sign In   
  • Create Account


Waterlimon

Member Since 28 May 2011
Offline Last Active Today, 01:39 AM

#5181893 simple crafting system

Posted by Waterlimon on Yesterday, 09:20 AM

I have always disliked crafting system where you supposedly have to discover a recipe to use it (=look it up on the wiki because theres no logic to the crafting ingredients required to make something)

 

So I personally would prefer a very transparent crafting system. Basically an ingame list of all craftable items, structured logically. And highlight items you might want to craft (relevant to current situation), AND items you can craft or almost can craft (you have the ingredients in inventory).




#5177172 Collision detection against curves or other complex shapes and bitmaps.

Posted by Waterlimon on 31 August 2014 - 04:07 AM

You would either represent it as a collection of simple collision primitives (circles, boxes etc.) that are scaled and rotated to approximate it well, or you would approximate it as an arbitrary polygon (which the physics engine could triangulate or just do physics based on the polygon edges or whatever works the best)

 

Check some 2D physics engine and see what features it has.




#5175848 MMO Gap issue

Posted by Waterlimon on 24 August 2014 - 12:14 PM

Progress is measured by how close you get to a goal (which may be infinitely far away but whatever)

 

Change the goal over time so newcomers will not be pursuing the same goal as the veterans.

 

This can be implemented as starting a new world every once in a while (or expanding the world and putting new players in the new regions), but you could come up with something that works in a single world/place. Like a new branch of magic to pursue that is slightly better than the old one when people start getting too good at the old one.

 

It might make the game remain interesting for longer for the older players too as they have to keep 'adapting'. Or it might just annoy them when their work becomes less and less worthy if they cling to it.




#5173327 Is it possible that I just simply lack the required intelligence?

Posted by Waterlimon on 13 August 2014 - 07:07 AM

Also, when you find mistakes in your code, think if theres anything you can change in the way you code stuff to avoid similar mistakes in the future.
The whole point of many language features and coding practises is to prevention bugs and keep everything simple, so focus on that.


#5169512 What happened to Rastertek?

Posted by Waterlimon on 27 July 2014 - 09:29 AM

http://web.archive.org/web/20140625035927/http://rastertek.com/

 

seems to have the tutorials there, dont know if you can download the files though.




#5168563 Rotating camera with mouse

Posted by Waterlimon on 22 July 2014 - 10:00 PM

m_horizontalAngle+= mouseSpeed*float(width/2-dx);
m_verticalAngle+=mouseSpeed*float(height/2-dy);

Since you are adding to the angle, you should be adding 0 when the mouse doesnt move. However, if the mouse doesnt move (dx=dy=0), you end up adding mouseSpeed*float(width/2) horizontally and same for vertical.

 

If you want to move the camera when the mouse moves, remove the width/2 and height/2 parts and it might work like you intended it to.

 

If you want to move the camera whenever the mouse is not at the center of the screen, pass in the mouse position relative to the center of the screen (mouse.x-width/2, mouse.y-height/2) instead of the delta position.




#5168004 [Depth buffer] From linear -> non-linear depth values

Posted by Waterlimon on 20 July 2014 - 02:58 PM

You should be able to just do the inverse operations in the exact reverse order to do that (+ becomes -, / becomes * and apply operations in reverse order)




#5167408 2D rotated rectangle collision detection

Posted by Waterlimon on 17 July 2014 - 08:50 AM

I think the tool to use here is the Separating Axis Theorem (SAT). If there is a plane/line that separates two objects, they dont intersect.

 

Basically, you would take all the planes (/lines) that bound your rectangle (based on the faces of the rectangle),

 

Then, for each of those, you check if the other box is completely on the 'outside' side of the plane (you can do this by checking each vertex separately).

 

If the above is true for even a single plane/line, there is no intersection.

 

 

This works for any convex shape. It wont get you the point of intersection though, but you didnt need that. Google for an optimal way to implement it, the above was just a vague description of how it works (might not even be exactly correct).




#5166834 How to avoid "stacks of doom" in 4X?

Posted by Waterlimon on 14 July 2014 - 03:45 PM

The usual solution seems to be area of effect based weapons.

Ineffective against single targets but can be very effective against larger groups.

Try to come up with a similar mechanism maybe.


#5160559 problem with my reflection idea

Posted by Waterlimon on 14 June 2014 - 05:31 PM

Yeah you usually do mirrors by rendering the scene from the mirrors perspective.

 

Think of the mirror as a plane.

 

Now, to render whatever the mirror should see, simply REFLECT MIRROR the real camera to the other side of the mirror and render (render only the area of screen covered by mirror) on top of the real scene. The mirrored camera should not render anything behind the mirror plane (so you only render the part of scene on one side of the mirror, the side that can actually be reflected off of it)

 

Idk how to do that in unity tho.




#5159735 2d Physics of Rope

Posted by Waterlimon on 11 June 2014 - 05:35 AM

I dont know, ive never implemented anything like it.

 

I guess you could throw away the concept of edges entirely and only have vertices, but the vertices dont need to be points, they could also be lines.

 

So all you would need to change is to make collisions be against a line instead of a point, and modify them constraints such that they try to match up the endpoints of the lines instead of the centers.




#5159704 2d Physics of Rope

Posted by Waterlimon on 11 June 2014 - 02:12 AM

One way to do it at least is to treat each vertex as a small mass.

 

You then do collisions to those vertices individually.

 

Then you have some constraints which attempt to keep the rope in a rope like form (keep adjacent points at a set distance apart basically). Youll likely need a proper integrator to avoid the rope exploding all the time too...

 

 

I guess you could also test collisions against the edges for more accuracy, but testing only the points is probably sufficient in most cases if they are not too sparsely spaced.




#5157602 Terrain LOD tessellation cracks

Posted by Waterlimon on 02 June 2014 - 12:54 PM

You need to either modify the higher LoD chunk to have the edge vertices align with the lower LoD vertices of the adjacent chunk (someone used different index buffers to do this, such that the correct indices for the cracks not to appear can be used depending on the LoD levels of the adjacent chunks) or you need to use some kind of 'skirts' (between the chunks, connecting the two chunks together)

 

There are lots of resources online since this is a somewhat common problem so you should be able to find something using google.




#5155995 What am I forgetting to optimize?

Posted by Waterlimon on 26 May 2014 - 06:12 AM

Profile all of dat code and youll find out.

 

Could it have something to do with the camera angle relative to the ground? Do you have LoD for everything?




#5155439 Best way to store collision detection BBs

Posted by Waterlimon on 23 May 2014 - 08:17 AM

It doesnt really need to be a text file if you can just separate the bounding box definition code to its own source/header file, or wherever that information can be hidden without getting on the way.

 

How is your game structured? The example you posted has some magic numbers (which should probably be defined elsewhere, maybe not in a separate text file but elsewhere in the codebase), doesnt have any vector class or bounding box class to make the operations neater, and the check against a single object in the scene has been hardcoded.

 

-Make a Vector class to represent positions, so you dont have to do everything 3 times once for each dimension.

-Make a bounding box class to represent bounding boxes for the same reason

(So you can do if (nuclearBunkerBB.contains(player.position)) to check if the player is in the box)

-Try to abstract the collision code such that all objects are treated equal if possible. Most objects probably behave pretty much the same regarding collision, so you can have a vector<Collider> which you loop over to check for collisions. If you need object specific collision responses, you can give each Collider a callback function or something similiar which allows you to implement these custom behaviors.

-Define the magic numbers and such so that the logic isnt filled with them. This is somewhere where you define what a nuclearbunker is, or what a player is. These definitions can be loaded from disk, or they can be defined in code (Eg you could do something like have a vector of object types, each one identified by some enum, and each object type tells its dimensions and any other relevant information)






PARTNERS