Zenkai Knights

That is for sure. Unity was created for creating games in the first place.

i am currently writing a obj tool to split meshes in obj file into separate files.  unity treats separate meshes in obj as 1 mesh together.


i am using windom style of animation for the game.  well, not entirely.  its modified to be improved.   1 thing is animation can be reused by mechs.  though its going to be fully possible to write a tool to convert windom animations into working with my game. by using windom system of animation it makes it easier to create mechs by swapping parts out.

It makes sense. A lot of games using this method to make modding easier. Combined with the separate files for the parts of an unit it will help a lot in the later developments.

Modding might be little bit more restrictive compared to windom. this is cause i have plans for a mix and match system that will be able to work with the setup of the mech files. though the mix and matching will be able to be done externally though too. ingame would make things easier. this would also mean all mechs will be able to change colors just like in silver knights so custom color scheme will be a thing.

So a kind of everything or nothing concept for modding. I guess that is still manageable for the programmers. I wish Windom XP had custom coloring, while I had no problems with the preconfigured sets sometimes I wanted to make them have something different just for reference lol. I can mod the colors but that is clientside only, non of my friends could see it if we play online unless I send my files.

No programming knowledge needed.  everything is built in.


not much has been done in programming it so far. i have though wrote 1 tool for unity to duplicate children to help build the base.


i am busy with other stuff plus unity 2018.1 is going to be released very soon.

Unity is sure frequently updating the engine.

i guess i will just start it in latest version and upgrade it to latest unity version.

first step is get model loading implemented from the parts.
then its animations.

I'll wait for your logs about the developing. All those ideas sounds good enough for a Steam Greenlit when the game sees an alpha release.

well, its been a month i got no work done. except for some design confirmations.

decided to go with a custom model format that can easily be converted from and to obj. it will be based off obj basically a binary version of obj. why?, cause binary is faster to load and i can skip the need to convert from text to the format needed in memory.

there will also be a base file for all mechs this. this file constructs the base part of the mech aka body, waist, arms and legs. extra parts like wings and other stuff will be handled by another file. the base file will be required by all mechs and will have a consistant size.

That is a good idea. Less load here means you can put extra load there if needed.

start work on the obm converter.

next files after are:
obp - which is equivelant to hod files for my game.  considered going with hod for the name but the file is designed differently.  obp means Object placement. used to snap shot poses and helps build animation.  also helps place where objects are. created using unity.

evt - animation events. created in external tool

ani - standard animation file.  built from obp and evt. design to load from within a packaged file.  created in external tool

anp - animation package. stores animation files in 1 package. created in same tool as ani.

anr - animation registry tells where to get the animations. simple file only saves package name and animation ID within package.  all mechs have 1 of these.


still unsure of how i am going to handle extra parts and hitbox data.

The easiest way, though I don't know if that's possible in 3D games, is to tell the engine to register every pixel or point as hitbox which is different than 0. 2D texture based games tend to do this for a little extra load on the processing.

not possibly with 3d games.

i am thinking only 1 hurt box for the mech and 1 hit box for melee attack collision. this should work cause looking at windom and extreme vs gameplay you mostly attacking the center of the mech.

That's true. And honestly I never checked if one could shot through between the legs or wings for example to see if there is a hitbox.

Endymion wrote:That's true. And honestly I never checked if one could shot through between the legs or wings for example to see if there is a hitbox.

maybe i should test this out. see what happens.


tested and shooting between the legs produces a collision.  the hit box might be extended below the waist or there is 2 hit boxes one for upper and one for lower.


ok, from the more test i done. it looks like windom uses 2 spheres for the mechs hit testing. 1 for legs and 1 for top. both are used in terrain collision.

The fact some of the mech's part can move through the map's objects prove that.

i am probably going to with this setup plus some improvements on it. like adding IK footing.

Perfectly good for this type of game. As you said, every single weapons and attacks aim for the very same place, namely the center of the mech.

obm converter is nearly done. only thing missing is converting obm back to obj files which i will do later. its not necessary for continued development. might port a version of this to unity easy to port since its in same language as unity.

obp is next which has to be done in unity.

After the game's release the tools could be merged into it. So you has both the editing tools and the game together like the Cube 1-2 engine.

obp script is done for unity. just need to test load a model with base.obp and the 4 obm files (Legs,Arms, body, and head). i am designing things so i can add a Mix & Match Customization System later on or atleast use it later for a future game.

reuseable animations is still going to be a thing for ZK.

If the model's bone similar, the same animation will work. Compared to UT2004 the mechs are somehow more complex and if it have additional body parts like wings those will require a new set of animations.

unity has animation layers where you can add animations together.
i could have it where legs are one layer and top is another. then any additional parts are in layers for them.

It sounds more complex but also more usable at the same time as one can use layers instead of a whole mesh.