Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / DarkPro's - What do you think?

Author
Message
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 26th Nov 2009 05:05
I use an AMD rough equivalent of a pentium 4 - A 1.5 ghz 32 bit single core processor running windows 98 for DBC. Because of Windows 98, DBC flies and I've never had any problems with it generally.

Quote: "
What would you suggest using instead? I can't use plains because the spheres actually rotate to align the path objects."

Possibly use hidden plains. Use Object Screen X() and OBject Screen y() to draw boxes and lines between the plains. That way you don't need to manage rotations - just the positions of the plains. You then just draw lines between them so you can see the paths.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 26th Nov 2009 05:41 Edited at: 26th Nov 2009 05:42
@Digger


@Latch
Here are my results. I tried at 8000x600x16 and 1024x768x16 and got the same results. No change in FPS when using LOS:
Setting FPS Actual FPS
0 =============> 64
40 =============> 30
60 =============> 40

Quote: "Possibly use hidden plains. Use Object Screen X() and OBject Screen y() to draw boxes and lines between the plains. That way you don't need to manage rotations - just the positions of the plains. You then just draw lines between them so you can see the paths."

The only thing is, the line segments (box objects)connecting the paths use the waypoint rotation to properly connect to the waypoints. If I was only concerned with the XZ axis I wouldn't need them but when waypoints are at different Y positions, the waypoint angles are used to properly angle the line segments up or down to link the waypoints. I will give it some thought to see if I can do something different. It could be quite a performance hit with a hundred paths, even with my i7. - Sorry Digger
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 26th Nov 2009 06:02
@NTTC - Wow, it must have already came in!

Quote: "I tried at 8000x600x16 and 1024x768x16 and got the same results."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 26th Nov 2009 08:01
Quote: "I will give it some thought to see if I can do something different. It could be quite a performance hit with a hundred paths, even with my i7"


What I had originally designed was a function that took an overhead 2d snap shot of the 3d scene. From there I'd use the snapshot as a map and just draw in 2d on top of it all of the waypoints. The waypoints are converted from x,y to x,z with any necessary scaling based on the size of the bitmap. That's one way. It's very quick and one can draw on the 2d map much like a paint program.

But here's a quick knock up of using plains and lines in 3d that may be able to be applied to the waypoint editor you've built. I grabbed a bit of the code out of my 2d version and just adapted it to 3d. You can only create 1 path as it is an example. Use the RIGHT mouse click to add plains.



Enjoy your day.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 26th Nov 2009 22:06 Edited at: 26th Nov 2009 22:34
Originally I was thinking this project wouldn't require the need of a level editor, and spending time on development for a level editor would take away from completing the game itself. But, as there are two editors at work already - the static collision environment editor and the waypoint editor, I'm starting to wonder...

Anyway, like a design document, the project evolves as it needs to; and it has evolved for us to have to create tools to create what we need. I actually am glad we didn't start with the creation of an editor because two things are happening:
1. We are designing the game
2. We are indirectly creating a custom editor for the next game that has tools we specifically know we need.

@No Time to Code
Triangle math Shooting:
Quote: "...It seems somewhat accurate within this well defined environment. I don't think it will work (in its current state) if the target was moved behind or to the side of the gun. I'll be glad to go with your version. One thing I was thinking about, how will either one of our methods work if the creature is at some odd angle to the gun? So, if the creature is directly facing the gun it shouldn't be too hard to relate the XYZ coord of the hit to a part of the creatures body. Might also work well if the creatures back is to the gun. But how do you place the damage if the creature is at a 48 degree angle to the gun? How do you know what body part is has hit?"

Using the projected object oriented to the gun is the way I think we'll go. This will allow us to use already prebuilt DBC commands without having to use additonal maths. Whatever angle the gun is pointing, the object will move along that path to the distance of impact with the creature. Since it's just a distance check, the projection will just be to the finish point. We'll have to test performance using box collision vs poylgon collision when there are mutiple creatures running around.

As far as hitting specific body parts, rather than just an area on the creature, as Digger412 suggested we could have several objects that represent different body parts; or we could just use the area of impact relative to the creatures position and x,y,and z size to determine what was hit. If the hit was above a certain y value relative to the creature's height, then it's a head shot. The creature's y angle relative to the gun's y angle will determine front back or side damage and the relative position will determine arm or leg hits. The method will have to be played with, and we may not even want to differentiate between different body parts except maybe when it comes to head shots (how grusome!) . We may only use other hit positions to turn the creature or make it fall in a certain direction - or just record damage.

Where we're at
This is generally where the project is right now. The completed items are more so "the way we will do things" or the methods we are going to use to build the game engine. The code has been worked out, it's a matter of cleaning it up and making it consistant and managed in libraries.
= done
= in the works
= undetermined or not even started

* House model
* Terrain except the texturing needs work
* Interior pathfinding system
* Interior wall and floor collision method
* Bullet collision with walls
* Bullet collision with creatures

Music
* Creature Model(s)
* Terrain Height Finding Depends on a couple of different things. I've created an algorithm that uses the dot product to return specific heights for any terrain. But there has to be ways to negate this influence when the player is in the house.
* General Movement Depends on the influence of the terrain and world physics. It can be simplified to not worry about these things, but we still need terrain height, and creature player physical interaction.

* Menus
* Sound effects
* Player Model
* Player Animations
* Creature Animations
* Environment Physics
* Shed (storage area of weapons/ammo)
* Additional environment details/models
* Weapons
* Planks for boarding up the windows
* Boarding up the windows code
* Creatures tearing down the boards
* Creatures climbing into house and switching from waypoints to player pathfinding

down the road:
Lighting
Special effects (blood, broken objects, exploding anything, fire)
Health - Damage control
Level Management

way down the road in the next county
multiplayer

Enjoy your day.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 28th Nov 2009 09:21
EPIC EPIPHANY: I knew that staying up until 2:20 AM or so had it's benefits...My most major problem with modeling in 3DC is using the condolidate/soften/smooth/.etc operations because it creates seams. When I was looking for the weld operation I needed, I found the "Solidify" operation...It'll automatically fill in every seam created by the other operations. Now, back to work on a certain model that may be used here...Depends on what the creatures are.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 28th Nov 2009 17:07
@Latch
Quote: "But here's a quick knock up of using plains and lines in 3d that may be able to be applied to the waypoint editor you've built"

I will start working on incorporating your plains/lines method into the waypoint editor. I didn't know that you could use the LINE command in 3D. I will still need to have collision on the plains because it's used to select an existing waypoint to move or delete. Depending on the performance when there are a lot of waypoints, I may have to selectively apply collision (ie. User chooses which path they want to edit and only use collision on those waypoints). I'll set it up for 100 paths but I wasn't thinking we would need that many. I was thinking 20-25 would be sufficient. That would allow 4-5 paths for each compass direction. I'm going to have the paths numbered but it still may be confusing to work too many paths on the screen.

Quote: "Using the projected object oriented to the gun is the way I think we'll go. "

Sounds good!

@Digger
Quote: "Now, back to work on a certain model that may be used here...Depends on what the creatures are. "

What model(s) are you working on? I know Latch posted a prototype creature some time ago. I'm not sure if we were going with that one on not. If not, feel free to design the creature model.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 28th Nov 2009 21:44 Edited at: 28th Nov 2009 22:04
Quote: " Depending on the performance when there are a lot of waypoints, I may have to selectively apply collision (ie. User chooses which path they want to edit and only use collision on those waypoints)."

Here's a variation that allows repositioning without using collision. Again it uses the screen x and y position to select the object (like when drawing the line):



Quote: " I'll set it up for 100 paths but I wasn't thinking we would need that many. I was thinking 20-25 would be sufficient."

I suggested 100 or more to eliminate predictability. Multiple paths could have the same starting points or even follow the same lines until a point and the branch off in different directions so the player can't easily train the gun on where they think the creature will go. 5 paths from the compass directions might be pretty easy to predict after tplaying the game a couple of times.

How about this, in the editor allow up to 100 paths (or more), but just let the user create less than that if they want. If you want to use the editor for more than this game, try and plan how it could be universally adaptable to any environment: a racing game for example, a military game where sentries are patrolling specific paths - inside a building or outside, a space sim where maybe ships fly along specific trade routes, etc.

The focus isn't so much on how pretty the editor is, it's more on can it create the necessary waypoints and can those waypoints be easily used in a game?

Quote: "I'm going to have the paths numbered but it still may be confusing to work too many paths on the screen."

Perhaps, only the current path being edited is the only one visible at any given time, and/or you can choose the visibility of any or all paths at any given time. The other thing is, you can hide the 3d objects and still have the line drawn. Each line/path could be a different color - I can imagine total mayhem with a lot of paths! So I understand your concerns.

Whatever you decide to do, in the end all we need is the data for the waypoints to be readable in game.

I was even thinking that the waypoints could all be randomly generated.

From each edge of the terrain, choose a random starting point. Increase the opposite direction by a certain set amount, for example if the starting point is from the north (z=terrain edge, x=rnd(width)), decrease the z value by some set amount, and add a random value to the x . The ending point is a window position that is also chosen randomly ahead of time. The set amount of increase for one of the directions could be determined by the distance to a window and a certain number of divisions. Maybe there are always 20 divisions (or waypoints in a path) so if the distance to a window from an edge was 2000 units, then the set increment for that particular path would always be 100 units.

Because of the random path generation, a creature might bump into an obstacle in it's path. We could add some collision where it turns 90 degrees, walks a certain distance then tries to resume getting to the next waypoint - or path find around the obstacle to the next waypoint. Or maybe this: In the waypoint editor, there is an option to randomly draw the path by selecting the starting point, the ending point and a random variance. In the above example, the X direction was what would be set to a random variance. This way, the computer quickly creates the path and the user can accept it the way it is or change it. The user can then edit it as they want; moving waypoints as necessary.

Anyway, those are just some ideas.

[EDIT]
When using lines to connect the waypoints, there is a performance hit when a lot of lines are drawn on the screen at once. An alternative to both using lines or using additional objects, besides altering the meshes with memblocks, is to change the color of the planes in sequence to their position on the path showing the direction of the path flow - like a string of christmas lights. This is just another idea off of the top of my head and I haven't tested it.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 28th Nov 2009 22:08
Quote: "Here's a variation that allows repositioning without using collision. Again it uses the screen x and y position to select the object (like when drawing the line)"

I'll try your new version when I get home tonight.

You suggested a lot of good ideas. I'm learning that as you create these games, how many "sub-projects" come up such as editors and how they can take on a life of their own!

The random generation is an interesting idea. I think you would need to have the outside objects placed (rocks, haystacks, other buildings, etc.) to ensure that a waypoint isn't placed in an unreachable location.....

I'll start working on incorporating some of your suggestions into a new editor.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 28th Nov 2009 22:19
Here's a little rough draft of a spaceship model, I don't really have enough skill to take it much further. If the creature are aliens, this could be used in the intro or something, idk. I made it using boolean operations, they make modeling much easier! It totals at about 1400 poly's, though..

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 29th Nov 2009 01:29
@Digger412
I'll have to take a look at that. Thanks.

@No Time
Something dawned on me after I mentioned the memblocks. By using the triangle object in DBC, you don't have to know anything about memblocks and you can position the vertices where you want. With that in mind, I changed the line code drawing between waypoints to stretching triangles between them. The following example is pretty fast and I've added hundreds of triangles with no real performance loss.

The cube represents the last waypoint entered. The red triangles point along the path from start to end. The base of the triangle is the position of the last waypoint, the point of the triangle points to the next waypoint. Use the right mouse click to add waypoints:



Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 1st Dec 2009 03:59
@Latch
I should be getting my new PC tomorrow so I'll be offline for a few days getting things set up. I wanted to post what I've done so far on the waypoint editor. The attached .dba uses the media from my previous zip file. Changes in this version include:
Uses plains textured with the path number
If you select a plain with the move tool it will connect the waypoints in that path using your LINE method.
Select path using mousewheel

I was able to remove about 100 lines of code not having to worry about rotating objects!

I commented out line 585 `gosub _test_fps. This sub puts down about 1500 waypoints. On my PC I get 6fps when the plains are textured and 14fps when untextured. As I may have mentioned in the past, my PC sucks so I'd like to see what fps others get.

Quote: "The red triangles point along the path from start to end."

I could use your triangle method but you still need to show the waypoints so the user can move or delete them if desired.

@Digger
The spaceship looks good. Maybe you can work on some models for the outside environment (i.e. haystacks, fences, low brick walls, rocks, etc.)

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 3rd Dec 2009 09:10 Edited at: 3rd Dec 2009 09:25
Quote: "I commented out line 585 `gosub _test_fps. This sub puts down about 1500 waypoints. On my PC I get 6fps when the plains are textured and 14fps when untextured"

I get about the same. 7 and 10 .

The sheer number of objects is driving down the performance. I tried it again hiding all but 2 of the paths and the fps jumped up to about 57. So you can probably manage performance by allowing hiding and showing of different paths.

And there doesn't have to be 100 paths in game. Make 10 or 20 and save it to the array and try loading it up in game. All we need are the paths. The editor seems to work. Now let's make some paths with it. Perhaps we could make 5 at a time and just keep adding them if we need them. Save multiple arrays of a small number of paths, then just combine them in game. If the editor is working, let's use it.

I've mapped the collision for the house. It's complete except for the roof. I don't know if I'll do that. I was think of having the aliens jump and land on the roof - but probably not. Speaking of which, I do want the aliens to jump up onto the upper porch. I was thinking there would be a few specific waypoints for just this purpose. Any ideas?

I've also been working on the alien model again. The first model had around 7000 faces. TOO MANY POLYGONS! I've been trying to scale it down and keep it looking halfway decent. I looked at the alien mutant model from the darkmatter example that came with my version of DBC; that's almost 900 polygons - which seems like a decent amount; even though it looks blocky, the texturing is quite good. I'm no modeler! And definately have a lot of troubles with texturing. At any rate, for the model itself I would have to give it about 1 to 2 more weeks work.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 3rd Dec 2009 16:36
Quote: "I commented out line 585 `gosub _test_fps. This sub puts down about 1500 waypoints"


I just loaded DBC on the new PC last night. When I run this now I get 40fps with textured objects!

Quote: "Now let's make some paths with it. Perhaps we could make 5 at a time and just keep adding them if we need them. Save multiple arrays of a small number of paths, then just combine them in game. If the editor is working, let's use it."


Sounds good. To save myself some work, I'm not going to let the user load multiple files back into the editor. Just one file at a time if you need to make edits. But the waypoint loading routine in the game will use data from multiple files when placing the waypoints. I'll put together a sub/function to do this.

Quote: "Speaking of which, I do want the aliens to jump up onto the upper porch. I was thinking there would be a few specific waypoints for just this purpose. Any ideas?"


That sounds good but only if it doesn't add to much complexity to the coding. It seems like it's just you, digger and myself working on this and we've got a lot to accomplish. I'd rather get the game done sooner and add in any more advanced features later. But if you think it's an easy do or adds substantially to the game play, lets do it.

I'm looking forward to seeing the finished house. The last pics you posted looked great.

Quote: "I'm no modeler!"

That's not my strong point either, especially with organic models.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 3rd Dec 2009 20:14
Quote: "I'm looking forward to seeing the finished house. The last pics you posted looked great."

Thanks! I think we may still need a media repository however.

@all
Here's a couple of screenies of the alien in progress. This first one is a 3 quarters view showing the torso and arm. Basically, I should just be able to duplicate the arm and the upper body would be more than halfway done. It's turning out a little better than I expected! It's not subsurfaced (subdivided faces to increase smoothness), I'm just using vertex normals instead of face normals for that smooth look. At this stage, it's 357 faces though. Another arm will bring it up to 500. I'm aiming at a total poly count of 800, but it looks like it may be 1000. I might have to rebuild the torso... but I don't want it to be big blocks...

attchment

Enjoy your day.

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 3rd Dec 2009 20:17
And now the arm in action...

Enjoy your day.

Attachments

Login to view attachments
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 3rd Dec 2009 23:24
Nice alien Latch.
I'm working on some more music for this now.

"With games, we create these elaborate worlds in our minds, and the computer is there to do the bookkeeping." - Will Wright
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 3rd Dec 2009 23:43 Edited at: 4th Dec 2009 03:34
@Latch - Very nice alien. As for the media repository, I've created an account on MediaFire that we could upload stuff to. The username is 'DBClassic'. If anyone on the team wants to use this, they can email me at the account I made for this, zmail412@yahoo.com, then I'll email the password to you.

EDIT: Made a hay bale...I have 2 versions, the second has another layer of smoothing that the first version doesn't, and I don't know which one looks best...It's kinda hard to see that it spirals, but it does if you look at the verts and edges. Both have 528 polys, which is way too much for just a haybale...I don't have any more time to work on it tonight, though. 3DC can use quads, so in 3DC it only has 270 faces or so....Anyways, I'm no modeler so I'm happy that I can even do this xP.

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th Dec 2009 21:20
Quote: "Both have 528 polys, which is way too much for just a haybale...I don't have any more time to work on it tonight, though. 3DC can use quads, so in 3DC it only has 270 faces or so....Anyways, I'm no modeler so I'm happy that I can even do this xP."

I would agree, the polygon count is a bit high for a bale of hay! But, you are practicing your modeling and you can only get better with practice. And your help is very much apprecited. I've been messing around with your shotgun model a bit. It's pretty well designed and it shouldn't take much to lower the polygon count.

Oh, and Digger412, before you give out a password for the media website to anyone, have them post here first before they email you so you know (or at least it's more likely) that it's who they say they are. I know this isn't a top secret project, but I would rather keep the final media and anything of the like within the team. I've got to create an email for this project so I'll let you know when I'm ready to email you for the password.

@Obese87
Quote: "Nice alien Latch.
I'm working on some more music for this now."

Thanks, and looking forward to hearing what you come up with.

Enjoy your day.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th Dec 2009 23:34 Edited at: 7th Dec 2009 23:38
Updated alien screeny. This is a rendered version, with specular, bump mapping, etc. and etc.

Enjoy your day.

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th Dec 2009 23:44
And this alien is more likely how it will look in game. I still need to add feet! The polygon count is at 974 without feet. The head and neck added about 100 polygons. Anybody got a low polygon head and neck that doesn't look like a cube?

Anyway, here's the probable in game alien look screeny:

Enjoy your day.

Attachments

Login to view attachments
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 8th Dec 2009 06:19
@Latch - I'll work on the haybale more when I have some free time. Thanks for the compliment on the shotgun, too. As for the media site, I was thinking something along those lines...too bad that Apollo doesn't have a PM system..Also, very very nice alien model...I'll have to revamp my ship to match it's awesomeness =P
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 8th Dec 2009 13:57
That alien looks great! It makes me think of something that would dig itself under the ground in sandy areas, and when their prey nears, they jump out.

TheComet


Make the paths of your enemies easier with WaypointPro!
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 8th Dec 2009 14:09
I thought of the movie "Tremors" when I first saw it..I wonder if it should be able to burrow...that'd bring a new dimension to gameplay: watch where you're stepping!
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 8th Dec 2009 19:50
I've started to work on a movement system incorporating some of the existing code and ideas we've been discussing.
Function to load waypoint file(s) into the game
Enemies will randomly pick a path and move along the waypoints.
When they reach the end of the path, they will be at the house and switch over to A* pathfinding
When they reach the same zone "room" as the player they will move in a straight line toward the player using something like this:


Some things to think about:
If the player goes outside and the enemy is outside, we will have to switch enemy to A* or straight line movement
If enemy is using straight line movement, we will have to use some kind of collision (sliding?) to go around objects
When the final house model is done and the outside environment is complete (rocks, hay bales, fences, etc) I can map nodes for the entire terrain so A* can be used inside and out.
If we wanted to have a dynamic environment (i.e. haystacks and other obstacles can be moved) then A*, in it's current form, wont work because the nodes are mapped as passible or impassible beforehand.

Let me know if you have any other ideas about how the movement system should work.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 9th Dec 2009 01:52
Quote: "When they reach the same zone "room" as the player they will move in a straight line toward the player using something like this:"

Here is some waypoint moving code that can be applied to enemies track to the player. Basically it makes the focused object make a smooth turn towards the destination while moving forward. This uses curveangle. The larger the speed value of curve angle, the wider or slower the turn. Instead of having enemies slide left or right, they can turn and move forward. This causes a bit of an arcing motion. Again, depending on the settings in curveangle, the arc can be minimal. In the following example, the red cones will move towrads the green cube. Move the green cube forward or backwards with the arrow keys and steer with the mouse. Moving backwards gives you a better visual of how the cones are responding. I have them set to move in a fairly wide arc for the sake of demonstration.

Change the 40 to something lower in this line
curyang#=curveangle(destyang#,curyang#,40)
in the _track_player rountine



Quote: "When the final house model is done and the outside environment is complete (rocks, hay bales, fences, etc) I can map nodes for the entire terrain so A* can be used inside and out."

I don't think A* will be necessary for outside. There will be collision set up for both static and dynamic objects. The tracking system displayed above can be used for waypoint movement as well so there can be a single routine that is called when the creatures have to track to a waypoint or the player. The difference will be the coordiantes they track to each iteration. Here is an example of using the same tracking method as above. It was originally designed as a test of collision for multiple objects. It uses a single collision object for speed that all of the cones share in turn. The green posts are obstacles that the cones will move around if the collide with them.

Using this collision method, I've gotten the polygon count past 25,000 with no real reduction in fps. To do this, change the cones to spheres try and keep as many in screen as possible:



Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 9th Dec 2009 02:17
I'll try out the code when I get home tonight.

Quote: "The tracking system displayed above can be used for waypoint movement as well so there can be a single routine that is called when the creatures have to track to a waypoint or the player."

I can probably use it for A* movement also, so the creature will realistically move from node to node.

I assume that each creature will use the feeler object method of determining ground height of terrain you created. I guess I'll see once I set it up but do you anticipate any performance issues having 20-30 creatures using this method? Not sure if I should assign each creature it's own feeler object or use one object and move it from creature to creature when it's their turn to move.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 9th Dec 2009 05:36
Quote: "I assume that each creature will use the feeler object method of determining ground height of terrain you created. I guess I'll see once I set it up but do you anticipate any performance issues having 20-30 creatures using this method? Not sure if I should assign each creature it's own feeler object or use one object and move it from creature to creature when it's their turn to move."

In the zombie demo above ( the one with the green posts as obstacles) I use a single feeler object and move it from object to object. I think this'll work for the collision checking for the monsters in 8 Hours 'til Dawn (yes, I'm using branding now to reinforce the product name!) because the creatures have to be in a loop anyway and depending on the situation, it's much faster to check object collision using object collision(this object, that object) than it is to use object collision(this object , 0).

However, the performance hit that comes out of using a feeler object with terrain is due to the loop that controls the height of the feeler object. That little bit of pause while the feeler object moves up and down to determine the height of the terrain is a little bit of a performance cost. In the castle example, I shot down a static collision test from the height of the object to the floor beneath it. This makes the loop time consitant and generally shorter to find the height. This same method might be able to be implemented on a terrain except it would be very difficult to set up the static collision environment on such an uneven surface.

Actually, I've blended a couple of textures together using Blender and tiled them on a 20x20 grid using the same heightmap that I built the terrain with. I used the completed texture on a DBC matrix and it actually looks pretty good. If you look real hard though, you still can see the boarders of the matrix cells - that's a very difficult problem to overcome with the built in matrices but, I think it'll be ok. I've used lee bamber's normal routine to try and hide the divisions with shadows. So, with a light control, normals, fog settings, and maybe some mist, I think it'll look pretty good and fairly detailed.

The advantage would be using the get ground height command to make things nice and easy. I'm still thinking about using the object terrain and instead of a feeler object for ground height, using dot product calculations - which is actually quite fast - though I've only tested it on a single object. I'd have to test it on multiple objects. But, I think we'll try the matrix first. That'll make things easier. I've tested it with a randomized matrix, now I just have to create one from the height map.

So with all that being said, this is how I imagine the collision will be handled:
1. The terrain will be a matrix for ground height use

2. The static objects on the terrain will be inside static collision boxes

2a. A static collision box test will be made between the current creature's position and the static environment

3. Dynamic objects will be encased in a rotating object collision box for speed. Not as accurate as polygon collision, but should suffice.

3a. All creature collision will be set to off when they are created.

3b. A feeler object of the creatures size will be encased in a rotating object collision box. A collision test between this object and the dynamic environment will be made. We'll have to decide whether to test the environment objects in a loop, or using object collision(this object,0).

4. The actual area of the house will have to be mapped out so that get ground height does not have to be implemented when the creatures or the player are inside of the house. Perhaps a collision check straight down with a feeler object? That might be slow. Probably a within bounds check. The only odd shaped area is the entrance way, otherwise it's just a big rectangle. The place holder house model you are working with is the same except for an opening between the room to the right of the stairs and the room directly behind the wall there (the middle room across from the door).

5. The inside and outside of the house will be tested for collision using static collision tests. This is the same as when the creatures are moving around outside so it's not an extra routine. The same rules apply also including dynamic objects.

5a. The player is subject to the same collision tests. The difference in movement will be direct input control.


No Time to Code, have you emailed Digger412 already about the media site? I still haven't set up the email I'll use for this project - hate to admit that I've been a bit lazy on that aspect. But I'll post the house there once IO get set up.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 9th Dec 2009 17:22
Quote: "But, I think we'll try the matrix first."

This will definitely make things easier!

Quote: "4. The actual area of the house will have to be mapped out so that get ground height does not have to be implemented when the creatures or the player are inside of the house. Perhaps a collision check straight down with a feeler object? That might be slow. Probably a within bounds check. The only odd shaped area is the entrance way, otherwise it's just a big rectangle. The place holder house model you are working with is the same except for an opening between the room to the right of the stairs and the room directly behind the wall there (the middle room across from the door)."

So, if the players xz position is within the bounds of the house, fix the y position at whatever height the floor is at? ie. y=10 if on the first floor and y=100 is on the second floor?

Quote: "No Time to Code, have you emailed Digger412 already about the media site?"

I emailed digger this morning.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 9th Dec 2009 20:30 Edited at: 9th Dec 2009 20:52
Quote: "So, if the players xz position is within the bounds of the house, fix the y position at whatever height the floor is at? ie. y=10 if on the first floor and y=100 is on the second floor?"

The only complication with that is the stairs so I think it will be collision testing like inside of the castle example. But, try a fixed height. Perhaps the stair area can also be a bound area and if that area is entered then collision testing with the ground (floor/stairs) can kick in. We'll have to see what works best.

So for now, don't worry about the collision. Just worry about getting the creatures to follow their paths and switch from method to method. You can use a randomized matrix for the terrain for now with a max height of about 40 or 50 to simulate the terrain.

@TheComet
Quote: "That alien looks great! It makes me think of something that would dig itself under the ground in sandy areas, and when their prey nears, they jump out."

Thanks!

Enjoy your day.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 9th Dec 2009 23:50 Edited at: 9th Dec 2009 23:52
@NTTC - Okay, I replied to your email. I didn't get a chance to check it this morning like I normally do (got up late for school >.<

To keep the media that is uploaded private, people need to click the 'make private' link after they've uploaded their file.

The only restriction Media Fire has on it as a free account is that the maximum uploadable file size is 200Mb. There is unlimited uploads, downloads, and storage capacity, though. Large files could be split up across different volumes in a folder.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 10th Dec 2009 16:46
Well, somehow the dba with my code for the movement engine got deleted.

I was laying down some paths on the waypoint editor and getting conformation the files were saved but when I looked in the folder, the files weren't there. I figured it had something to do with permission and Admin rights for Windows 7 so I was changing the permissions and somehow my dba with movement code got deleted. I have no idea why since I wasn't doing anything with the file at the time, it was just open. Checked the recycle bin and even used a file recovery utility but no sign of the file.

sigh.......

Well, I'm going to take a few days to get over my grief and I'll start working on it again.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 11th Dec 2009 01:08
Have you tried Recuva? I've never used it, but I have used Defraggler and CCleaner. Here's a link: http://www.piriform.com/download
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 11th Dec 2009 01:38
Quote: "Have you tried Recuva?"


Yup, thats the one I tried. Even on deep scan which took about an hour, it didn't find the file.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 11th Dec 2009 04:49
Hmm...have you looked at the full source dump?
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 11th Dec 2009 20:00
Quote: "Hmm...have you looked at the full source dump? "

What's that? Is it an option in Recuva?
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 11th Dec 2009 23:16
Whoops, that's DBP. I keep forgetting that this is DBC >.<..DBP has a FullSourceDump.DBA file in a TEMP directory. I remembered that it's DBC and looked and..no TEMP...so sorry..
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 11th Dec 2009 23:39
Actually I coded my way back to where I left off. It was easier the second time around

I'm going to buy a second hard drive this weekend and get in the habit of frequent backups!

Function to load waypoint file(s) into the game
Enemies will randomly pick a path and move along the waypoints.
When they reach the end of the path, they will be at the house and switch over to A* pathfinding
When they reach the same zone "room" as the player they will move in a straight line toward the player
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 11th Dec 2009 23:41 Edited at: 11th Dec 2009 23:43
@NTTC
There should be a source dump in root/dbTemp . It will be named workfile.tmp . But I suppose it depends on the permissions whether or not DBC was able to write to that folder. Also, check where your default save directory is in darkedit. There should be a file labeled Darkedit.tmp . This will be the source of the last file that you ran or compiled from darkedit.

If not for this time, it should be useful info for next time.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 12th Dec 2009 00:03 Edited at: 12th Dec 2009 00:04
@Latch
Thanks. I'll check those locations when I get home tonight. I did try a search of the C: using the filename and nothing was found. What bothers me most is I don't know how it happened so I'm not sure how to avoid a
Quote: "next time"
......
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 13th Dec 2009 00:12
@Digger412

I emailed you about the password.

4893

Enjoy your day.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 13th Dec 2009 00:27
@all
Take a look at these two screen shots of the farm area. They are slightly different. Tell me which one you think looks better for whatever reason:

Picture 1


Picture 2


Enjoy your day.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 13th Dec 2009 07:18
@Latch - I've received you email, thanks.

I've always been bad at spot the differences lol.

It looks like the second one has brighter lighting, and the base is smaller. I like the darker lighting of the first, I'm still undecided on the base though. Well, the lighting may just be my computer, though..
pictionaryjr
15
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 13th Dec 2009 07:34
im not part of this group but just saying the second one because the textures appear to be better. or at least on the ground
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 13th Dec 2009 14:40
Quote: "I've always been bad at spot the differences lol."


I had a hard time seeing the differences as well but I give the nod to the second one. I think the second one has better lighting and, I agree with pictionaryjr, the ground texture looks better.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 13th Dec 2009 21:46
Quote: "im not part of this group but just saying the second one because the textures appear to be better. or at least on the ground"

That's fine! The more responses the better the idea I get of what I want to do. So hopefully, I'll get a few more opinions.

Enjoy your day.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 13th Dec 2009 23:13
@All - I created a folder on MediaFire called 'DarkPro's', any media uploaded to it will automatically be marked 'private', only viewable to someone who can log into the account. I've made a couple of subfolders in it, more can be added as needed.
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 13th Dec 2009 23:29 Edited at: 13th Dec 2009 23:31
Well if you want input from everyone. The second picture doesn't show up on my machine, but the first one looks way dark. should be brighter.


edit:

nvm it reloaded and showed the second one. They both look a little dark to me. Other then brightness, they look great. Good job!

New Site! Check it out \/
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 13th Dec 2009 23:38
@Latch
If you have a finished house model can you post it (either here or on Digger's MediFire account)? It doesn't need to be textured. I'm working on the movement system and would rather base everything on the finished model then have to redo it later.
Tnx
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Dec 2009 01:16 Edited at: 14th Dec 2009 01:19
@Caleb
Besides them being dark, do you see any differences between them and which picture looks better?

@NTTC
I created a new folder called house_model. Inside there should be the light mapped version of the house. When setting up in DarkBASIC, scale the object by 1000

scale object house,1000,1000,1000

Also, since the terrain will basically be the same size and shape as the place holder terrain, position it @ 0,-75,0 . If you create a 4000x4000 matrix, set the tiles @ 10x10 and position it at -2000,-75,-2000 .

The Y heights of the enemy and the player will be determined by the environment. The waypoints need not store this information or if it does, it does not need to be used in game. The height and the pivot of the characters may change so based on their stats and the ground or obstacle/house heights, that's how their Y position will be determined.

Enjoy your day.

Login to post a reply

Server time is: 2024-04-16 16:43:17
Your offset time is: 2024-04-16 16:43:17