Modding

View previous topic View next topic Go down

Modding

Post by Slaihne on Tue May 17, 2011 2:53 pm

If anyone has any thoughts on a modding API type thing please let me know here. I've a few thoughts on this myself and i'll stick them down when i get some time.
avatar
Slaihne

Posts : 264
Join date : 2011-03-17
Age : 49

View user profile

Back to top Go down

Re: Modding

Post by S33m3 on Wed May 18, 2011 3:02 am

Hello !!

I see that you are advancing really well with your engine ! Smile
I'm also doing a lot of background work, trying to have a clean code base before going further on.

I switch to a "pluggable/modable" architecture for my engine using MEF (http://msdn.microsoft.com/en-us/library/dd460648.aspx).

What's really interessting is that now, just be dropping a DLL in the plugging directory, the program take it into account and run the engine with it ! Giving the possibility to Add/remove/modify ingame logic !

What's nice it's that it is interface based.

I'm writting my flooding algo inside this kind of plugging, and it is really working nicely !

Here is the current interface I'm using (Subject to LOT of changes)

Code:

    public interface IWorldPlugin
    {
        string PluginName { get; }
        string PluginVersion { get; }

        void Initialize(TerraWorld world);
        void Update(ref GameTime TimeSpend);
        void EntityBlockReplaced(ref Location3<int> cubeCoordinates, ref TerraCube newCube);
    }
Initialize behing called at the pluggin initialization and giving a "Tool class" to the plugging (TerraWorld)
TerraWorld give the possibility to have acces to the blocks in memory, doing modification on them, ....

Update is called once per frame before drawing.

EntityBlockReplaced is a callback event raised when the user do a block modification in the world (new block placed, or block removed).

Now what would be reaaaaalllllyyyy nice, is to discuss a generic plugging Interfaces (could have different interface depending on what we want access to), and to base our plugging/mod on this interface !

At the end it should give the possibilty to use a plugin developped for your engine with my engine without any change ! Smile

I don't know where you want to go with the modding things.

S33m3

Posts : 54
Join date : 2011-03-23

View user profile

Back to top Go down

Re: Modding

Post by Slaihne on Mon May 23, 2011 1:52 pm

Interface's seems to be the way to go with this.

I'd want to give access to the block / light buffer at various points of its life cycle; Prior to terrain generation and after terrain generation spring to mind immediately, with an option to totally disable my terrain generation. This would allow the terrain to be completely in the hands of the modder. Also, the modder could optionally maintain seperate data structures themselves to govern terrain generation and also mechanics they have implemented within the game. Say for instance they wanted to mark each and every block with the builder of the block and this wasn't already contained in my data structure, then they could add that 'overlaid' and pick up on it at later points, say the event that occurs when a player tries to dig a block.

Also, an entry point prior to and after both save and load of a chunk with the ability to disable the built in save / load mechanism so that area can be totally implemented by the modder.

I'll have to sit down and think of when these events should occur to give maximum benefit to a modder. If anyone out there has any ideas on this then add them here please.

It'd be great if we could do a matching interface S33m3, but the only problem i would forsee is that out internal data structures will be radically different. I seem to be the only person working on one of these engines who has a unified block buffer. Everyone else seems to have individual chunks holding the blocks, which is a huge difference.
avatar
Slaihne

Posts : 264
Join date : 2011-03-17
Age : 49

View user profile

Back to top Go down

Re: Modding

Post by S33m3 on Mon May 23, 2011 2:22 pm

Hello,

You are not the only one, I work also with a "Big" table. No matter the way the data are handle at a lower level, the interface should (But it's maybe not the fastest way to handle this type of things) onle give acces to fonction like : Terrain.SetBlock(worldX, worldY, worldZ, Block) or Terrain.GetBlock(worldX, WorldY, worldZ).

It needs to be well though, but from my first experiment with a flexible pluggin architecture, it's "doable".

Also I work a LOT with delegates now !

Storing inside cube "profile" the delegate seems to offer great extensibilty.

Let's take an sample with on of my cube profile :
Code:

private static TerraCubeProfile WaterSea()
        {
            TerraCubeProfile profile = new TerraCubeProfile();
            profile.Type = CubeType.WaterSea;
            profile.Tex_Top = 21;
            profile.Tex_Bottom = 21;
            profile.Tex_Front = 21;
            profile.Tex_Back = 21;
            profile.Tex_Left = 21;
            profile.Tex_Right = 21;
            profile.IsBlockingLight = false;
            profile.IsPickable = false;
            profile.IsSolidToEntity = false;
            profile.IsBlockingWater = true;
            profile.IsFlooding = true;
            profile.FloodingPropagationPower = int.MaxValue;

            //Apply default delegate for cube face generation !
            profile.CanGenerateCubeFace = CubeFactory.FaceGenerationCheck;
            profile.CreateCubeMesh = CubeFactory.GenCubeFace;

            return profile;
        }

// Now the default implementation for the FaceGenerationCheck :

        //Default Face Generation Checks !
        public static bool FaceGenerationCheck(ref TerraCube cube, ref Location3<int> cubePosiInWorld, CubeFace cubeFace, ref TerraCube neightboorFaceCube)
        {
            //By default I don't need to trace the cubeFace of my cube if the face neightboor cube is blocking light ! (Not see-through)
            if (CubeFactory.CubesProfile[(int)neightboorFaceCube.Type].IsBlockingLight) return false;

            //Else draw the face
            return true;
        }


Now in my Water plugging, I have decided to implement the plugging own way to replace the default behaviour :
So in the plugging we have :

Code:

//In the plugging constructor I overide the default facecheck implementation :
CubeFactory.CubesProfile[(int)CubeType.WaterSea].CanGenerateCubeFace = PluginFaceGenerationCheck;

public bool PluginFaceGenerationCheck(ref TerraCube cube, ref Location3<int> cubePosiInWorld, CubeFace cubeFace, ref TerraCube neightboorFaceCube)
        {
            if (cubeFace != CubeFace.Bottom && cubeFace != CubeFace.Top) //Never display a bottom Water face !
            {
                if ((!CubeFactory.CubesProfile[(int)neightboorFaceCube.Type].IsBlockingLight && !CubeFactory.CubesProfile[(int)neightboorFaceCube.Type].IsFlooding))
                {
                    return true;
                }
            }
            if (cubeFace == CubeFace.Top)
            {
                if (cubePosiInWorld.Y == TerraWorld.SeaLevel || neightboorFaceCube.Type == CubeType.Air)
                {
                    return true;
                }
            }
            return false;
}

The big advantage of the delegate, is that you can also use their multicast capability.
Meaning that this is also correct :
CubeFactory.CubesProfile[(int)CubeType.WaterSea].CanGenerateCubeFace += PluginFaceGenerationCheck;
This time instead of replacing the default behaviours, the default behaviours is called first, then after the plugging fonction is called.

I'm still doing experiment with this system. And should soon be able to show it worling with the first "Liquid" plugging for my engine. (Placing the DLL inside a directory will make the ocean to make waves, liquid to propagates, ...)

S33m3

Posts : 54
Join date : 2011-03-23

View user profile

Back to top Go down

Re: Modding

Post by Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum