Results 1 to 7 of 7

Thread: Move to adress in 3d grid.

  1. #1
    Member BluePrintRandom's Avatar
    Join Date
    Jul 2008
    Location
    NoCal Usa
    Posts
    18,205

    Move to adress in 3d grid.

    so each packet when it hits a switch, looks to see which direction to go, based on the directions availible in the switch

    I did this kinda a goofy way and hope someone can help me perfect it

    give packet adress -> send packet into grid -> packet makes it to destination

    this is kinda working but not quite.
    Attached Files Attached Files
    Break it and remake it - Wrectified
    If you cut off a head, the hydra grows back two.
    "headless upbge"



  2. #2
    what are you making with this?



  3. #3
    Hey BPR, your scripts are looking a lot more readable these days but I still think it's a good idea to give meaningful names to the text files rather than gamelogicsimple.py, just makes it easier to understand which text blocks are doing what.

    I like the effect, it could be used to make an interesting background or title screen with some more interesting particles.

    If you're moving things in a grid you probably don't need to use collisions, you can just work with co-ordinates.
    Say your start point is [0, 0, 0] then you want to move to [0, 1, 0] you can move the object a little at a time until it reaches where it's supposed to be going.

    I use a python class for grid movement, which is given a start point and an end point and it lerps between them using a timer. The great thing about this is that you can pick up the class, get the state of the timer, start and end points and store it for a saved game. Loading is easy, just feed back the points and the timer progress and it will continue from where it left off.

    Code:
    import mathutils
    
    
    class MoveMe(object):
        def __init__(self, game_object, start, end, speed, timer=0.0):
            self.game_object = game_object
            self.start = start
            self.end = end
            self.speed = speed
            self.timer = timer
            self.done = False
            
        def update(self):        
            self.game_object.worldPosition = self.start.lerp(self.end, self.timer)        
            self.timer += self.speed
            
            if self.timer >= 1.0:
                self.done = True
    
    
    def move_an_object(cont):
        
        own = cont.owner
        if "mover" not in own:
            start_point = mathutils.Vector(0.0, 1.0, 0.0)
            end_point = mathutils.Vector(0.0, 2.0, 0.0)
            
            own["mover"] = MoveMe(own, start_point, end_point, 0.002)
        else:
            if not own["mover"].done:
                own["mover"].update()
    A similar class can be used for rotations and other transformations so your game objects can be recorded in position, saved and then reloaded next time you pick up the game.
    I use grid based movement for most of my games.



  4. #4
    Member BluePrintRandom's Avatar
    Join Date
    Jul 2008
    Location
    NoCal Usa
    Posts
    18,205
    I already know how to lerp, the idea was to simulate electronics that send data packets routed by each cube, and each cube will eventually be a devkce that can recieve these packets and operate on them

    1 packet = a digital electronic burst of data
    in this case of the sim each packet passes properties.

    the idea is to simulate voxelized electronics

    in the end, each cube will need to know all the cubes connected to it,



    edit: maybe some form of 3d astar?
    Last edited by BluePrintRandom; 16-Jul-17 at 14:34.
    Break it and remake it - Wrectified
    If you cut off a head, the hydra grows back two.
    "headless upbge"



  5. #5
    Moderator Monster's Avatar
    Join Date
    Jan 2006
    Location
    Germany
    Posts
    13,651
    A* works on a graph (nodes with edges). It considers the weight of the edges.


    The location of the nodes does not matter (it does not even need a location). The position within an n-dimensional space matters in some specialized solutions e.g. when you do not know the edge weights but calculate them on the flight.

    Such attributes also matter when you generate a search graph from a 3D -World. The path-searching does not need that.



  6. #6
    Yes, with A* the graph doesn't have to be space based even. You can do A* on behavior or colors or anything that has connections, hierarchy and cost.



  7. #7
    Member sdfgeoff's Avatar
    Join Date
    May 2010
    Location
    Kalpana One
    Posts
    5,071
    I would advise abstracting your data away from 3D space entirely. Even if it is "voxelized electronics" it can be represented fully in python as nodes, packets and links (ie a graph). This will give you a HUGE performance boost, and will mean you can test it without needing BGE.
    "Someone applied a roof texture to that wall" - martinsh

    Website: www.sdfgeoff.space



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •