Sign in to follow this  
khawk

Posting a screenshot? Add it to the Gallery for a chance to be the Image of the Day

Recommended Posts

khawk    2925

Have you noticed the Image of the Day box on pages across GameDev.net?

We're featuring one screenshot per day out of the GameDev.net Gallery as the Image of the Day. Submit an interesting screenshot to the Gallery, work in progress, or your recently announced game and it could be featured across the site as the IOTD.

Go to the gallery to submit your images at https://www.gamedev.net/gallery.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Similar Content

    • By Luigi Lescarini
      Hi,
      i’m trying to build an effective AI for the Buraco card game (2 and 4 players).
      I want to avoid the heuristic approach : i’m not an expert of the game and for the last games i’ve developed this way i obtained mediocre results with that path.
      I know the montecarlo tree search algorithm, i’ve used it for a checkers game with discrete result but I’m really confused by the recent success of other Machine Learning options.
      For example i found this answer in stack overflow that really puzzles me, it says :
      "So again: build a bot which can play against itself. One common basis is a function Q(S,a) which assigns to any game state and possible action of the player a value -- this is called Q-learning. And this function is often implemented as a neural network ... although I would think it does not need to be that sophisticated here.”
      I’m very new to Machine Learning (this should be Reinforcement Learning, right?) and i only know a little of Q-learning but it sounds like a great idea: i take my bot, making play against itself and then it learns from its results… the problem is that i have no idea how to start! (and neither if this approach could be good or not).
      Could you help me to get the right direction?
      Is the Q-learning strategy a good one for my domain?
      Is the Montecarlo still the best option for me?
      Would it work well in a 4 players game like Buraco (2 opponents and 1 team mate)?
      Is there any other method that i’m ignoring?
      PS: My goal is to develop an enjoyable AI for a casual application, i can even consider the possibility to make the AI cheating for example by looking at the players hands or deck.  Even with this, ehm, permission i would not be able to build a good heuristic, i think
      Thank you guys for your help!
    • By hyyou
      I encapsulated Physics and Graphics with ECS successfully.
      Here is a simplified version :-
      Physics Rigid Body = Physic_MassAndInertia + Physic_Transform + Physic_Shape Graphic Polygon Body = Graphic_Transform + Graphic_Mesh I usually set their transform via :-
      findService<Service_PhysicTransform>()->setPosition(physicEntity,somePos); findService<Service_GraphicTransform>()->setPosition(graphicEntity,somePos); It works so nice, and there is no problem in practice, because I always know its "type" (physic/graphic).  
      However, I notice that Physic_Transform and Graphic_Transfrom are very similar and duplicate.
      For the sake of good practice and maintainability, I consider to group them into Generic_Transform.
      findService<Service_Transform>()->setPosition(anyEntity,somePos); //cool However, there is a little difficulty.  The physic transformation is quite complex for a child inside a compound body.
      Assume that a physic body B is a child of a compound body C.   In this case, B's transformation component currently has no meaning (by design).
      If I want to set the child transformation setTransformation(B,(x,y,45deg)), my current physic engine will not set the B's transformation directly - it will set C's transformation that make B's position match (x,y,45deg).

      Thus, it is not so practical to group them, except I code it like (ugly and worse performance):-
      class Service_Transform{ public: void setPosition(Entity B,Vec2 pos){ bool checkIsPhysic = .... //check if B is physic if(checkIsPhysic){//physic Entity compound = .... //find C ComponentPtr<Transform> cCompound = compound.get<Transform>(); cCompound->pos=pos*someValue; //calculate some transformation for C }else{//graphic ComponentPtr<Transform> cTransform=B.get<Transform>(); cTransform->pos=pos; } } } Should I group them  into 1 type of component?  
      I probably should not group them because its meaning and related implementation are very different, but I feel guilty ... I may miss something.
      Advice about other things are also appreciated.  Thanks.
      Edit: Hmm... I start to think that grouping component is OK, but I should still use 2 function (from different service/system).
      Edit2: fix some code (pointed out by 0r0d, thank)
    • By Outliner
      Consider how one makes terrain using marching cubes. By having a grid of floats we can represent a continuous field that marching cubes will interpolate and turn into a nice smooth isosurface for the player to walk around on. This is easy and excellent for creating mountains and valleys and so on, but what if we want more variety in our game? A game is not normally made of just grass and sky. Maybe some places should be sand, or water, or road. How could that be worked into the mesh that we're getting from marching cubes?
      The obvious approach seems to be to have multiple fields, so each point on the grid has a certain level of sand, soil, rock, water, and so on. Then we modify the marching cubes algorithm to look for transitions between materials, so it puts a surface between areas of mostly one material and areas that are mostly other materials. We'd also want to keep track of when these surfaces touch the air, because that's the only time when we'd actually want to triangulate and render the surfaces.
      Suddenly the delightfully simple marching cubes algorithm is looking a lot less obvious. Has anything like this ever been done? Does anyone have any tips? Is this the right approach?
      Edit: Embarrassing mistake! I didn't think of phrasing the problem as "multiple materials" until I went to post this question, but now that I have I see there are plentiful google results for marching cubes with multiple materials. I'm still interested in any tips and advice, but now I have other resources to help with this problem.
      From the Google results, this paper looks especially interesting: Automatic 3D Mesh Generation for A Domain with Multiple Materials
    • By Outliner
      I have a few key features that I want for my game's terrain mesh, but putting it all together into an terrain editor is becoming a headache. I need some advice from someone more experienced than myself. Perhaps there is some design pattern or object-oriented trickery to add some abstraction and turn this mess into something manageable.
      I am creating my terrain mesh as a problem of dynamic constrained triangulation. I start with a regular triangulation of a 2D plane into equilateral triangles, and then as I draw the game's map the existing edges and vertices are automatically removed to make room for the edges and vertices I'm drawing, and naturally the reverse happens when I erase. There are fairly simple algorithms for inserting individual vertices and edges into a triangulated plane. Using a half-edge data structure to represent the triangulation makes it quite manageable.
      Unfortunately there are a few additional important features. For one, a game map should be an infinite plane in all directions. The obvious solution to this is to break up the mesh into regular pieces, each one separately triangulated but sharing common points along their edges so that the multiple meshes fit together seamlessly in the game. The user should be able to draw map features across the boundaries of the map pieces seamlessly, without needing to care where one map piece begins and another one ends. An ordinary half-edge data structure doesn't have anything to deal with that and it would be nice if I could manage that complexity so it doesn't seriously affect my triangulation algorithms.
      Perhaps I'm asking for trouble, but I also want the terrain mesh to be able to change while the game is playing. I'm not so greedy as to try to implement animated terrain, but I would at least like to be able to remove a designated region of the map and substitute an alternative map of the same shape. We might think of it as having a hole in the map that can be filled by any one of several appropriately shaped meshes. Once we've got these meshes it will be trivial to pop them in and out during the game, but again it's another complication of the editor. Keeping the boundaries of the designated regions aligned with the rest of the map and allowing new edges to be drawn across that boundary is making the editor too complicated for comfort.
      What are the appropriate abstractions to use for this kind of situation? These seem like relatively simple features, but my design is turning into a tangled mess. What am I doing wrong? An ordinary half-edge structure doesn't seem to be the right tool for this job, but what would be the right tool?
  • Popular Now