the junk yard

Post your comments, ideas and suggestions about a new Z sequel here.

Moderator: Brad

DaMarkov
Major
Major
Posts: 180
Joined: 2018-12-20, 16:17
Are you a spam bot?: No
Contact:

Re: the junk yard

Post by DaMarkov » 2019-10-24, 00:24

wanzer wrote:
2019-10-23, 02:31
DaMarkov wrote:
2019-10-06, 15:48
I have a few general questions about this project.
Sorry, if this was mentioned somewhere on the previous pages.

1) Do you plan to release these assets (models, textures, animation) on some repository?
2) Do you plan to reimplement Z with 3D graphics or would you like to add additional features which would make it incompatible with classic Z?
and by repository you mean a way of downloading the game?
I haven't figured that part out yet
I guess ill have to place it on some file sharing website, maybe I can ask "The zone" to harbor it

if its about making the game open for development
id love to get a helping hand especially with
robot design and animations
level designing
doodads
and people that have a understanding of GODOT
That's what I meant. You could setup a project on github/sourceforge/something similar to upload the models/textures.
Maybe that's also a good way to find more people who would like to help with some assets.
wanzer wrote:
2019-10-23, 02:31
it will not be compatible with the original z
I intend to add a part that is a plain 3D version of the original game and add a part with new features
they will be both in the same program but still separated as a set of campaigns
so that both the people that just want the old game and the ppl that want to see something new will have something to play with
Sounds great! I had the idea that one could use the zod engine, but get rid of the renderer and all assets.
And write a completely new renderer with your assets. For the 3D version of the original game that should be possible. For adding new stuff this approach might be too complicated.
But that way, one wouldn't need to reinvent the entire wheel from scratch, i.e. one could use the network stack, server code, pathfinding, music, sounds, unit behavior.
User avatar
wanzer
Sergeant
Sergeant
Posts: 64
Joined: 2017-10-04, 05:27
Are you a spam bot?: No

Re: the junk yard

Post by wanzer » 2019-10-24, 09:32

DaMarkov wrote:
2019-10-24, 00:24
Sounds great! I had the idea that one could use the zod engine, but get rid of the renderer and all assets.
And write a completely new renderer with your assets. For the 3D version of the original game that should be possible. For adding new stuff this approach might be too complicated.
But that way, one wouldn't need to reinvent the entire wheel from scratch, i.e. one could use the network stack, server code, pathfinding, music, sounds, unit behavior.
can it be done to have a renderer with a way to read bones player?
pref from blender

reading obj files is easy but for making the robots ill need bones

oh and in the original tile based Z game the units shoot in a odd angle to hit a guns on top of the forts
since the game is flat it treats it like a ground based unit

in 3D this odd angle will be gone
but this will introduce a pitching axis to the gun

btw path finding isnt a problem
unit behaviour .... well its nice f we can write one for each unit having its own personality
general AI .... here we can also make a few, one having more arbitrary approach while a other is really calculated

btw i just been browsing github and i got lost in there
ill need some help x.x
DaMarkov
Major
Major
Posts: 180
Joined: 2018-12-20, 16:17
Are you a spam bot?: No
Contact:

Re: the junk yard

Post by DaMarkov » 2019-10-24, 17:14

wanzer wrote:
2019-10-24, 09:32
DaMarkov wrote:
2019-10-24, 00:24
Sounds great! I had the idea that one could use the zod engine, but get rid of the renderer and all assets.
And write a completely new renderer with your assets. For the 3D version of the original game that should be possible. For adding new stuff this approach might be too complicated.
But that way, one wouldn't need to reinvent the entire wheel from scratch, i.e. one could use the network stack, server code, pathfinding, music, sounds, unit behavior.
can it be done to have a renderer with a way to read bones player?
pref from blender

reading obj files is easy but for making the robots ill need bones
Should be possible. The blender file format is well known. There surely are some open source loaders for that file format.
Years ago I wrote some code for skeletal animations, but if your are using more fancy techniques (interpolation/weights), maybe it's better to use a fully fleshed out game engine.
wanzer wrote:
2019-10-24, 09:32
oh and in the original tile based Z game the units shoot in a odd angle to hit a guns on top of the forts
since the game is flat it treats it like a ground based unit

in 3D this odd angle will be gone
but this will introduce a pitching axis to the gun
Ah ok, that changes things. Then it wouldn't be backwards compatible with the zod engine.
wanzer wrote:
2019-10-24, 09:32
btw path finding isnt a problem
unit behaviour .... well its nice f we can write one for each unit having its own personality
general AI .... here we can also make a few, one having more arbitrary approach while a other is really calculated
Are you sure about this? In Zed online pathfinding is currently the biggest issue. I mean I really appreciate what freaknigh has done with the zod engine.
But I problem I am having is that if a player selects 10 units and sends them to one point the server has to run the pathfinding algorithm 10 times.
With more players this gets even worse. Pathfinding in Zed for a medium sized map, usually takes around 10 to 30ms, but sometimes it takes up to 80ms.
Freaknigh starts a new thread for every pathfinding operation, so at least all cores are used, but it's still slow.
So just a gentle warning some things that are no a problem right now, could become one later on.

General unit behavior is also soo much work. Freaknigh used 5000 lines of code for general unit behavior.
So this is code that is used by all objects in game. And there are some many edge cases to be considered. I would have never written that on my own.
Like calculating missile trajectories, calculating in which direction a unit should dodge. There are 10 different types of waypoints, i.e. units move differently depending on the type of the next waypoint.
And some waypoints even have different states they can be in. There is some much (hard to test) code ...
wanzer wrote:
2019-10-24, 09:32
btw i just been browsing github and i got lost in there
ill need some help x.x
github uses git, if you are not used to git, maybe that's too much work to learn just for uploading assets.
You could create a sourceforge project, there you can upload folder just via drag and drop. Maybe that's useful for you.


Using an additional axis for the guns sounds really interesting to me. Right now I am not sure if I think it's good or bad.
Without the additional axis the distance a unit can fire is very clear to the player (as long a the camera a directly above) and it's also easy to draw some kind of radius to show the firing distance to the player.
With an additional axis this gets much more complicated, but would also make high ground very powerful.
User avatar
wanzer
Sergeant
Sergeant
Posts: 64
Joined: 2017-10-04, 05:27
Are you a spam bot?: No

Re: the junk yard

Post by wanzer » 2019-10-24, 21:57

DaMarkov wrote:
2019-10-24, 17:14
Should be possible. The blender file format is well known. There surely are some open source loaders for that file format.
Years ago I wrote some code for skeletal animations, but if your are using more fancy techniques (interpolation/weights), maybe it's better to use a fully fleshed out game engine.
no they are robots they don't use skin and weight
DaMarkov wrote:
2019-10-24, 17:14
Are you sure about this? In Zed online pathfinding is currently the biggest issue. I mean I really appreciate what freaknigh has done with the zod engine.
But I problem I am having is that if a player selects 10 units and sends them to one point the server has to run the pathfinding algorithm 10 times.
With more players this gets even worse. Pathfinding in Zed for a medium sized map, usually takes around 10 to 30ms, but sometimes it takes up to 80ms.
Freaknigh starts a new thread for every pathfinding operation, so at least all cores are used, but it's still slow.
So just a gentle warning some things that are no a problem right now, could become one later on.
the map needs meta data
that's done by cutting up the map into smaller segments (in the background)
example
the roads are the main network for navigation
therefor the whole tile map needs a array containing the most nearby road joints and direction per tile, so when a unit stands on it, it wont need to do a path finding, it just asks the tile it stands on where the road is
same goes for the point where you send them to , that point asks the tile what the nearest road is
from there you can use the road network to plot out a route
in case the road route is longer then twice the distance between the unit and its target location … then you fall back on a pathfinding on a smaller scale

also when a set of units are selected and send on a path you only need to calculate 1 path and per corner have a set of grouping points for units to navigate to without all ending on the same spot
if units you select are all to far apart you first need to make a junction and from there a single path
DaMarkov wrote:
2019-10-24, 17:14
General unit behavior is also soo much work. Freaknigh used 5000 lines of code for general unit behavior.
So this is code that is used by all objects in game. And there are some many edge cases to be considered. I would have never written that on my own.
Like calculating missile trajectories, calculating in which direction a unit should dodge. There are 10 different types of waypoints, i.e. units move differently depending on the type of the next waypoint.
And some waypoints even have different states they can be in. There is some much (hard to test) code ...
allot of code is likely used to define the units animations (2d is eeeeeeekss)
with this 3D approach it will het allot simpler
and the development tool *godot* handles allot by plug and play
DaMarkov wrote:
2019-10-24, 17:14
github uses git, if you are not used to git, maybe that's too much work to learn just for uploading assets.
You could create a sourceforge project, there you can upload folder just via drag and drop. Maybe that's useful for you.
ill look into that
DaMarkov wrote:
2019-10-24, 17:14
Using an additional axis for the guns sounds really interesting to me. Right now I am not sure if I think it's good or bad.
Without the additional axis the distance a unit can fire is very clear to the player (as long a the camera a directly above) and it's also easy to draw some kind of radius to show the firing distance to the player.
With an additional axis this gets much more complicated, but would also make high ground very powerful.
the added axes is only for targeting stuff on top of forts XD
i do want to have the forts with mounted guns on top

however
the range id like to keep 2D
so no spherical range
User avatar
wanzer
Sergeant
Sergeant
Posts: 64
Joined: 2017-10-04, 05:27
Are you a spam bot?: No

Re: the junk yard

Post by wanzer » 2019-10-24, 22:08

ok path finding

see it like this

you are in the woods you have no idea where to go to BUT

behold

there is a roadsign
a very very very big roadsign
it contains a path from your location to every possible location you might need to go to

this is meta data

since the map isn't likely to change during game play

you can hide the data underneath the visible map in lists

the player wont see it
they wont need to
DaMarkov
Major
Major
Posts: 180
Joined: 2018-12-20, 16:17
Are you a spam bot?: No
Contact:

Re: the junk yard

Post by DaMarkov » 2019-10-25, 16:02

wanzer wrote:
2019-10-24, 22:08
ok path finding

see it like this

you are in the woods you have no idea where to go to BUT

behold

there is a roadsign
a very very very big roadsign
it contains a path from your location to every possible location you might need to go to

this is meta data

since the map isn't likely to change during game play

you can hide the data underneath the visible map in lists

the player wont see it
they wont need to
Sure, normal Dijkstra or A* algorithm does the job.
For Z its a bit more complicated since some units can move through rocks others can't.
The most annoying special case are robots (which is also incorrectly handled in the zod engine). Robots that can't go through rock can pick up grenades and then go through rocks.

I thought about having some kind of cache or to do some precomputation to accelerate the calculation since most player commands are just move unit from spawn point (at factory) to the front line.
I don't think it's really worthwhile but at some point I should do some estimate how much RAM it would cost to precompute some of the pathfinding data.
User avatar
wanzer
Sergeant
Sergeant
Posts: 64
Joined: 2017-10-04, 05:27
Are you a spam bot?: No

Re: the junk yard

Post by wanzer » 2019-10-28, 20:33

DaMarkov wrote:
2019-10-25, 16:02
Sure, normal Dijkstra or A* algorithm does the job.
For Z its a bit more complicated since some units can move through rocks others can't.
The most annoying special case are robots (which is also incorrectly handled in the zod engine). Robots that can't go through rock can pick up grenades and then go through rocks.

I thought about having some kind of cache or to do some precomputation to accelerate the calculation since most player commands are just move unit from spawn point (at factory) to the front line.
I don't think it's really worthwhile but at some point I should do some estimate how much RAM it would cost to precompute some of the pathfinding data.
well here is a opportunity to flash it out ^^
XD I know monstertask
DaMarkov
Major
Major
Posts: 180
Joined: 2018-12-20, 16:17
Are you a spam bot?: No
Contact:

Re: the junk yard

Post by DaMarkov » 2019-10-29, 10:27

wanzer wrote:
2019-10-28, 20:33
DaMarkov wrote:
2019-10-25, 16:02
Sure, normal Dijkstra or A* algorithm does the job.
For Z its a bit more complicated since some units can move through rocks others can't.
The most annoying special case are robots (which is also incorrectly handled in the zod engine). Robots that can't go through rock can pick up grenades and then go through rocks.

I thought about having some kind of cache or to do some precomputation to accelerate the calculation since most player commands are just move unit from spawn point (at factory) to the front line.
I don't think it's really worthwhile but at some point I should do some estimate how much RAM it would cost to precompute some of the pathfinding data.
well here is a opportunity to flash it out ^^
XD I know monstertask
monstertask indeed. Good luck!
I could newer start such a huge project on my own.

I am interested in the assets you make though. If you have models and texture for all buildings and units I might write and renderer for the zod engine just as an experiment if I get a month with a lot of free time.
I would like to see how the game translates to 3D.
User avatar
wanzer
Sergeant
Sergeant
Posts: 64
Joined: 2017-10-04, 05:27
Are you a spam bot?: No

Re: the junk yard

Post by wanzer » 2019-11-01, 16:52

DaMarkov wrote:
2019-10-29, 10:27
I am interested in the assets you make though. If you have models and texture for all buildings and units I might write and renderer for the zod engine just as an experiment if I get a month with a lot of free time.
I would like to see how the game translates to 3D.
I see

do you have a email address?


aside from all the programming used to bypass cpu loads
sometimes its just a matter of timing

the frame rate is what 30 frames per second?

you think anyone would notice a unit slacking for 4 or 7 frames?
the moments you give a order you can spread the load over several frames

hell I even do it with unit spots another unit
no one will notice a unit being idle for 0.02 seconds


btw a set of things you might want to know before you convert 2D to 3D

guns on top of the fort are positioned pretty high
object manufactured inside the fort have to drive a ramp up or the fort stands on a hill making the guns on top even higher
you need a formula to convert the mouse position into a horizontal and vertical rotation that respects the camera angles and lense
you need to make a formula that converts these 2 rotations back to a point on your screen
land and water wont just be tiles alone anymore , there will be a added hight difference between land and water
you want the selection bracket to scale along with the selected model
DaMarkov
Major
Major
Posts: 180
Joined: 2018-12-20, 16:17
Are you a spam bot?: No
Contact:

Re: the junk yard

Post by DaMarkov » 2019-11-02, 11:33

wanzer wrote:
2019-11-01, 16:52
DaMarkov wrote:
2019-10-29, 10:27
I am interested in the assets you make though. If you have models and texture for all buildings and units I might write and renderer for the zod engine just as an experiment if I get a month with a lot of free time.
I would like to see how the game translates to 3D.
aside from all the programming used to bypass cpu loads
sometimes its just a matter of timing

the frame rate is what 30 frames per second?
I think Z DOS ran at 30 or 25 fps. I didn't test it, but it feels like it.
Small tip: If you render the cursor as part of the HUD you should target a higher frame rate.
ZED Online becomes unplayable when the frame rate falls below 50 fps.
If you want descend user experience at 30 fps you should use the windows cursor or look into hardware cursor.
wanzer wrote:
2019-11-01, 16:52
you think anyone would notice a unit slacking for 4 or 7 frames?
the moments you give a order you can spread the load over several frames
In ZED Online the delay is 2 frames = 80ms, which seems fine. It feels instant to me and no one has so far complained.
With playing online this becomes a bit more problematic. With a connection of 150ms RTT (ping) the delay is noticeable but the game is playable.
With a RTT of 200ms the game is playable but the delay is annoying.
wanzer wrote:
2019-11-01, 16:52
hell I even do it with unit spots another unit
no one will notice a unit being idle for 0.02 seconds
I completely agree :-)

wanzer wrote:
2019-11-01, 16:52
guns on top of the fort are positioned pretty high
object manufactured inside the fort have to drive a ramp up or the fort stands on a hill making the guns on top even higher
you need a formula to convert the mouse position into a horizontal and vertical rotation that respects the camera angles and lense
you need to make a formula that converts these 2 rotations back to a point on your screen
land and water wont just be tiles alone anymore , there will be a added hight difference between land and water
you want the selection bracket to scale along with the selected model
So the map format is then fairly similar apart from the fact that I guess you will have a height map.
User avatar
wanzer
Sergeant
Sergeant
Posts: 64
Joined: 2017-10-04, 05:27
Are you a spam bot?: No

Re: the junk yard

Post by wanzer » 2019-11-02, 16:33

DaMarkov wrote:
2019-11-02, 11:33
So the map format is then fairly similar apart from the fact that I guess you will have a height map.
no XD

what rotation will a unit get when its navigating to something?
the 2D animations angle the unit in one of the 8 directions closest matching the target direction
will it be the same ?
or do you give the units a stepless rotation?

turret movement in the old game is also divided into 8 directions

the selecting units by clicking them or dragging a rectangle also needs attention
when you click a unit you use a ray tracer ,this ray is a line with 2 3D vector points, one on the camera location and another somewhere in the distance
that point needs to be calculated, for that you need the camera direction angles,camera fov angles, the camera resolution and the mouse coordinates

when you make a selection rectangle, you need to convert all the unit 3D locations to a 2D coordinate

and then there is the cameras range of view
in the old 2D game you can only scroll to the edges
in 3D you can do the same ofc but the view will still extend the playable area, so the level needs to be allot bigger then just the battlefield it self

I can go on and on of all the details that a 3D differs from 2D
DaMarkov
Major
Major
Posts: 180
Joined: 2018-12-20, 16:17
Are you a spam bot?: No
Contact:

Re: the junk yard

Post by DaMarkov » 2019-11-02, 17:38

wanzer wrote:
2019-11-02, 16:33
DaMarkov wrote:
2019-11-02, 11:33
So the map format is then fairly similar apart from the fact that I guess you will have a height map.
no XD

what rotation will a unit get when its navigating to something?
the 2D animations angle the unit in one of the 8 directions closest matching the target direction
will it be the same ?
or do you give the units a stepless rotation?

turret movement in the old game is also divided into 8 directions
The zod engine actually uses 360 degrees. (only integer values).
But that shouldn't impact the map file format anyway.
wanzer wrote:
2019-11-02, 16:33
the selecting units by clicking them or dragging a rectangle also needs attention
when you click a unit you use a ray tracer ,this ray is a line with 2 3D vector points, one on the camera location and another somewhere in the distance
that point needs to be calculated, for that you need the camera direction angles,camera fov angles, the camera resolution and the mouse coordinates

when you make a selection rectangle, you need to convert all the unit 3D locations to a 2D coordinate

and then there is the cameras range of view
in the old 2D game you can only scroll to the edges
in 3D you can do the same ofc but the view will still extend the playable area, so the level needs to be allot bigger then just the battlefield it self

I can go on and on of all the details that a 3D differs from 2D
I would recommend to do it the other way around. Convert the 2D selection rectangle into a 3D frustum and do the collision check in 3D. Should be faster ...
I mean, sure, the are a lot of optical differences. But these are all superficial. I am more concerned with changes to the map file format, communication protocol between client&server.
And the actual code the server has to run.
User avatar
wanzer
Sergeant
Sergeant
Posts: 64
Joined: 2017-10-04, 05:27
Are you a spam bot?: No

Re: the junk yard

Post by wanzer » 2019-11-18, 20:14

ok I made a GitHub project
still figuring out how it all works
right now the project is set to private
User avatar
wanzer
Sergeant
Sergeant
Posts: 64
Joined: 2017-10-04, 05:27
Are you a spam bot?: No

Re: the junk yard

Post by wanzer » 2020-01-16, 17:58

ok the GitHub experience for me sucks donkeybaws
I now went into programming it self
I figured when I need the artsy stuff ill be continuing working on that

my first goal now is to
setup
a map script(navigation) << first version will return a list with only the end location, later on it will get more detailed
a group of flags
a group of factories
couple the flags to the factories

2 groups of units
and 2 (AI) placed on a list of controllers (controller and not just AI cause its open to AI AND user input script) that will do the next thing
check the closest flag to its units << first it will do a basic distance check, later on it will have to add the map script
and send a msg to the units where to go to

the units will then ask the map script how to move
when a unit is within X distance of a flag it will change to its color and attached factories along with it
the game script will do a annual unit distance check, if 2 units from different colors get to close to each other these units will be send a msg, if both are within shooting range they will start to fire
when unit hp < 1 then unit dies

the factories that are captured
first it will just produce 1 type of unit, later on ill change it to a random unit from a list, and later on ill make an equation for it

there a number of small things ill need to add
like what flag is covered by a unit, units that die must send a msg to the AI they no longer cover the flag they are meant to cap etc
so the ai can send another unit to it
units must have a *busy* state so the AI doesn't send the unit to flag 1 and then sends the unit to flag 2 etc

once all this works, ill add a user input script to the controllers so I as a user can play as one of the colors
APC
Lieutenant
Lieutenant
Posts: 74
Joined: 2008-11-07, 16:18
Location: SLOVAKIA

Re: the junk yard

Post by APC » 2020-02-05, 16:44

Your goals would take me the rest of my life because of my slow pace of programming and testing :)
Post Reply