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
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 14th Dec 2009 03:04
Yes i do see some difference. As most everyone has said, I like the second one. The textures are better (i'm not sure if the house texture is different. it might be the lighting)

New Site! Check it out \/
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Dec 2009 11:22
@Caleb and everyone that looked at the farm pictures and gave a response
Thanks!

@No Time
I've added another folder to the mediafire website under 3d_models called terrain. In there is a function to create the terrain as a matrix, setting it to the proper size and position; and the folder also contains the terrain texture.

The only parameters necessary to supply are the matrix number to use, and the image number to use for the texture. Everything else is computed and the texture is automatically loaded. I added the ability to size and position the matrix with an idea for later expansion. I think I'll add code later that allows a model terrain to be used by choice if a matrix is not desired.

For now, the function can simply be put in one's code and called supplying the matrix number and the image number.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 15th Dec 2009 02:53
@Latch
Did you mean to include:

in your function or did you intend the user to include that after the function call?

Also, by positioning the house at 0,-75,0 the terrain covers some windows and come up through the floor. Is that the intent? Seems that it looks better with the house at 0,0,0....

Otherwise, it works great and I'll get started on mapping the nodes for pathfinding.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 15th Dec 2009 04:58 Edited at: 18th Dec 2009 11:45
Quote: "Did you mean to include:
+ Code Snippet
Position matrix mat,xpos#,ypos#,zpos#
in your function or did you intend the user to include that after the function call?"

OOOPS! There's a missing line in the function!

[EDIT]
I have posted an entirely new version in the terrain folder. I was missing the position matrix code in the function. Since the matrix is repositioned, getting ground height requires not only the x and z position of the current object or camera to be checked, but also the offset of the matrix position has to be subtracted from that position in order for the ground height to be accurate.

There's example code included with the function that positions the camera accordingly.

For our intents and purposes call the function like this:

mat=1 (or wahtever matrix number)
img=1 (or whatever image number)

create_terrain(mat,img,0.0,0.0,0.0,0.0,0.0)

I've also corrected a couple of the data statements. There were 2 values set to 40 and they needed to read 40.0 . A strange quirk in DBC, if you read data into a float variable and it doesn't have a decimal sign, it will assign the value as zero.


[OLD EDIT for information only]
I just realized something, if a FLOAT is being read from data statements and the values in the data statments doesn't have a decimal, then the value is read back as 0.

for example:



Enjoy your day.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 18th Dec 2009 11:54 Edited at: 18th Dec 2009 11:56
A couple of trees

I've created two different trees: a barren pine tree and a leafless oak type tree. Here's a couple of screen shots with the scenes over-saturated with the respective tree:

Pine Tree:


and Oak Tree:


I'll post the models to the repository in a few days probably. I want to start building the outside environment up a bit with obstacles, the shed/storage area, trees and stuff. These trees have somewhat of a higher polygon count than I wanted. The pine is around 449 and the oak is 1551. I'm trying to think of how to reduce the oak at least but I really have grown attached to it's character...

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 18th Dec 2009 19:49 Edited at: 18th Dec 2009 19:55
@Latch
Why do you position the house and matrix at -75? Is that so the house model is centered in the world?

Those tress look great! Did you write code to create them or use a modeling program?

@All
I created a folder called Movement in the repository. The dba is what I've one so far for the creature movement. Make sure the folder "Waypoints" is in the same directory as the dba. It contains two paths created in the waypoint editing program. The creatures will choose one of the two paths and move from start to end. (To change the number of creatures edit line 504). The path ends on a 40x40 grid of nodes used for A* pathfinding. I'm using plains to show the moveable(green) and non-moveable(red) nodes (To not use objects add "start" to the rem on line 660). The house model is loaded but hidden so you can see the movement more clearly (to unhide edit line 587).
Creatures will use A* to find path to goal node (reduced creature speed while in the house). The goal nodes are placed at the entrances to the zone "rooms". One in the same room as the player the creature will switch to line of sight (LOS) movement and move toward player until they reach at which time the enemy is "killed" and will respawn and start over again.
One thing I haven't done is that if enemy is in LOS mode and player goes to a different zone, the enemy should switch back to A* mode.
Note: Two things that will cause an error right now:
1. If player exits the node area OR
2. Player goes on some red nodes
because these areas are not defined as zone and A* will lock-up or error. In the game, the player can't enter red nodes because they are walls and outside the node area will be defined as zone 999 which means the player is outside.

It works but there is a noticeable pause when the player moves from zone to zone because of A* calculating new paths for each enemy. Another thing is that the A* movement, which giving the shortest distance from node to node, doesn't always look realistic and may not be the shortest distance "as the crow fly's". In the picture below the red line shows the path as the creature enters the house and move to zone 5. You see that it hugs the wall and that the green path is a shorter path but doesn't correspond to nodes.

I'm thinking about using waypoints in the house and some other search function. The picture below show a possible placement of waypoints. I'm looking at using Bredth First Search (BFS) or Depth First Search (DFS) to find a path from start waypoint to goal waypoint.

I don't know for sure that it will be quicker but I'm going to give it a shot unless you have any other thoughts.

[EDIT]
I don't know how to insert the image in the message to I've attached them to this post and the next.

Attachments

Login to view attachments
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 18th Dec 2009 19:52
Here is a picture of the proposed waypoint system.

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 18th Dec 2009 22:06
@NTTC
The house is at 0,0,0 . I've already set up the static collision on the house so I don't want to move it. The positions of everything are based on the original placeholder terrain and house that I posted months ago so you didn't have to change your nodes. The only different is the house has a foundation so you can't see underneath it, and the terrain has to be lowered 75 units so it doesn't go above windows and doesn't appear inside of the house. The object terrain center was at 0,0,0 but using a matrix, the lower left corner of a matrix is at 0,0,0 so the matrix has to be shifted to -2000,-75,-2000 so that the land is centered and below the windows.

It may seem like a big space between the bottom of the door and the terrain - the house needs some steps at the front of the door - I have yet to make them. The latest version of the create terrain function should include the proper offsets and the proper setup of the terrain including the camera movement offsets. Another 'glitch', if you will, with using the built in matrices is that the ground is calculated from 0,0,0 no matter where the matrix is located - therefore to get the proper heights, the x and z for the calculation have to be offset to the position of the matrix.

If you had a 1000x1000 3d unit matrix and shifted it so that 0,0,0 was at it's center, you'd position it at -500,0,-500 . Now if you wanted to get the ground height of the world position 0,0,0 on the matrix, you would get the value relative to the matrix's local coordinates at it's upper right corner (1000,0,1000). In order to get the value you really wanted based on the world 3d position, you have to offset that position by the position of the matrix. The offset are:

world3dx-matrix position x(mat), world3dz-matrix position z(mat)

And once you have the height, the offset for y is the opposite:
heighty + matrix position y(mat)

Quote: "Those tress look great! Did you write code to create them or use a modeling program?"

Thanks and Blender.

@Digger412
Could you model a couple of different boulders? Low-polygon please. You should be able to do with less than 50 polygons and no more than 100. (I should talk huh? with a 1551 polycount tree!)

Also, take a look at your oil drum. See if you can lower the poly-count a bit. It doesn't really have to be more than a cylinder with maybe a lip for a lid on the top an bottum. If you can build the texture in a painting program and include some text on it like KEROSENE or WATER or OIL or SAND or whatever. Ideally it looks perhaps metallic/wheathered, beaten. The texture should take care of dents and stuff or details. Try and keep the texture small too 256x256 or less. I know that's difficult because sometimes a low sized texture just doesn't look as good as a larger one.

Also, how about a some wooden crates. Individual ones, and complete models of stacked ones. Text stamped on the side of crate makes it a little more interesting visually.

Enjoy your day.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 23rd Dec 2009 21:59 Edited at: 23rd Dec 2009 23:22
@Latch - I reworked the barrels, they have 92 poly's now. In 3DC, they look good, but when I loaded them into DBP they had one little face that looked odd, like it wasn't textured correctly. It appeared that the rest of the barrel textured okay but in that one little face there was the entire texture, scrunched up. I haven't a clue why it's doing that, they look fine in 3DC...As for the text, I couldn't get it to texture correctly, it would slip up under the lip of the barrel and some of it would show up at the top.

I have 8 barrels total, with 4 textures. I used each texture on 2 barrels, using a Cylindrical wrap and a Spherical wrap. So, BarrelCylR1.X means that it's using a Cylindrical wrap and the Rust1.jpg texture. I'll upload them to MediaFire, but I don't know what to do about that one funky face. They're under 3D Models>Misc. Objects>Barrels.zip

EDIT: Got the crate model made, just need to texture it now..
EDIT2: Got the crate model textured, it's in the same directory as the barrels...it turned out okay, I think. I ended up using "DANGER! CAUSTIC MATERIALS" as a warning label.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 24th Dec 2009 17:22
Quote: "but I don't know what to do about that one funky face"

I see what you mean by the funky face on the barrel, not sure why that is but I'm really a beginner when it comes to UV wrapping.

How do you load the textured crate model into DBC? You have four different textures that need to go on the barrel but I only know how to apply one texture in DBC.



Whenever I've UV mapped an object I had to unwrap the model, UV mapped the different textures and then save the UV as one jpg. But again, I'm a newbie at modeling.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 24th Dec 2009 19:35
To load the models, all you should need to do is ensure that the textures used on the model are in the same folder/directory as the model, then just call "load object "crate.x",num". You should also be able to do the same for the barrel. You shouldn't need to use "Texture object num,num2".
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 24th Dec 2009 19:57 Edited at: 24th Dec 2009 20:11
Still no luck.

Quote: "In 3DC, they look good, but when I loaded them into DBP they had one little face that looked odd, like it wasn't textured correctly."


Can it be that it works differently for DBC? I thought the images had to be in bmp format to be used as a texture in an x model?

[Edit]
That's what it was. Once I converted the jpg to bmp and edited the .x file in notepad to change the filenames to bmp, it now loads with the textures in place.

Looks good!
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 24th Dec 2009 21:44
@NTTC - I'm sure that my use of DBP was the reason. I'll try to remember to use .bmp from now on, though. Thanks for the compliment, as novice as I am =P
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 24th Dec 2009 23:55
@NTTC
Holidays upon us... not much time to do much right now. But, looking at your code:

1. Don't put the house at 0,-75,0 . Leave it at 0,0,0 . The terrain is the only thing adjusted.

2. At first glance, the movement handling looks a little clunky - but I haven't had time to go over it in detail.

If Astar is to be used, the positioning of the enemy should be handled similarly to the external waypoints. After all, Astar actually create a series of waypoints along a path.

Ideally, the same array use is applied. I can't elaborate at the momoment

3. There will be an interlude where the creature is trying to get into the window. Once it has crossed this threshold, then that's when the zone stuff should start. It is possible to dump the A star altogether as long as the zones are still accounted for. Upon crossing the threshold, the creature will look at which zone it is in and which zone the player is in. There will have to be the closest or best entrance to the current players zone recorded, and the creature can move directly there along another way point path, or slide along the wall using collision until it reaches the entrance. Or, just have the creatures go towards any entrance in the general direction of where the player is in the house. The walls are open enough for the creature to find it's way around.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 25th Dec 2009 03:03
Quote: "1. Don't put the house at 0,-75,0 . Leave it at 0,0,0 . The terrain is the only thing adjusted"

Fixed that, I misunderstood your original post.

Quote: "It is possible to dump the A star altogether as long as the zones are still accounted "

I'm going to abandon the A* and go with waypoints and paths inside the house. A* might be overkill for this project and unless I can find some way to spread out the processing (see my recent post), the path calculations slow down the game too much. Instead, I'll hardcode the paths and use an array which will lookup the enemy zone and player zone an return a path number. I'll set up zones outside the windows and use a special flag to denote the window waypoints. Not sure how we want to handle the windows but with the flag the enemy can try to break in the window, play a special animation to have the enemy climb through the window, etc.

This method should be much faster, just going to take some time to create all the paths. Of course we'll still need the enemy to be able to navigate around dynamic objects like tables, chair, etc.

I'll get to work on this next week but for now:

Happy Holidays!!! @ ALL
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 29th Dec 2009 00:31
@No Time To Code
Thanks for the Good Cheer! And it sound like a good plan. Part of the making of this project is to try stuff out and find what works and what doesn't work. If A* doesn't work, then we know and it sets up a precedent for a future similar project. Are you sure the delay is due to the A* path finding? As it is running now, the delay, seems a lot longer than the 16 ms that you tested with 20 to 50 enemies searching their paths all at once. And I think you have only 3 in the current example. Is there something else that is occuring in the transition from waypoint to A* ? Are you checking the player's position in between each iteration or allowing movement of the player between each enemies repositioning? Something is happening, and it baffles me that there is what seems like a whole second or so delay before the enemies switch to pathfinding. What about those test from before? What has changed?

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 29th Dec 2009 17:53
Quote: "Are you sure the delay is due to the A* path finding?"

I'll have to go back a compare the codes. In both cases the enemies A* ran in a loop so there shouldn't have been any checking of player position or player movement. In the first example the loop ran for all enemies within the function since A* was the only form of movement. In the most recent example the enemy movement loop runs within the main loop and only calls the A* function for those enemies that are currently using A* (some enemies might be using outdoor waypoints or LOS movement).

If I was going to stay with the A* I would want to rewrite the function to work with the approx 20-25 waypoints instead of the current grid of 1600 nodes (40x40). Beside being faster it would allow for more realistic movement as I mentioned in a previous post.

I think the method I'm using now will work well. Just have to set up some more zones outside the windows and do some more testing. Basically I've set up some waypoints in the house and at the windows. I've defined the paths to go from any zone to any other zone and hardcoded them as data statements which are read into an array. Anytime an enemy or player moves, it checks what zone each object is in. If there are in the same zone the enemy will use LOS movement. Otherwise it looks up the appropriate path from the array. ie path#=zonearray(enemyzone,playerzone).

When I'm done do you want me to post it here or on Mediafire?
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 2nd Jan 2010 16:38
Quote: "I think the method I'm using now will work well. Just have to set up some more zones outside the windows and do some more testing. Basically I've set up some waypoints in the house and at the windows. I've defined the paths to go from any zone to any other zone and hardcoded them as data statements which are read into an array. Anytime an enemy or player moves, it checks what zone each object is in. If there are in the same zone the enemy will use LOS movement. Otherwise it looks up the appropriate path from the array. ie path#=zonearray(enemyzone,playerzone).
"


Sounds good.

Quote: "When I'm done do you want me to post it here or on Mediafire?"

MediaFire is fine. Thank you.

Is there anything you need from me in general. At present I've been trying to redesign the alien again... I started not liking it and the texturing needs a bit of work. If you need a general husk for sizing or positioning testing, I can probably get you that.

I haven't had a chance to reduce the polys on the big tree. I was messing around with a method to do it and got it down from 1551 to 675 but lost the file.

@Digger412
Your models look pretty good. I like the design of the oil drum, but the texturing needs a little work. The crate is pretty high poly. I think it's possible to get it down to 12 polygons and use clever texturing to get the overlapping boards effect without actually having to build those boards in the final model.

I was messing around with the free version of 3D canvas so I could get an idea of the tools you are using. The free version doesn't have all of the same functionality as 3d canvas pro but I noticed that it exports to POVray. A texturing trick for games is to render a photo-realistic view of your model at a high polycount and use the rendered image to texture a lower polycount model. I hope you don't think I'm picking apart your contributions. I really think it's great that you keep plugging away and trying and actually producing. That's a great asset for a team project. And I'm no modeling genius - but I know a couple of tricks here and there they may be helpful and am recently getting a handle on some texturing techniques.

Enjoy your day.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 2nd Jan 2010 19:08 Edited at: 2nd Jan 2010 19:53
@Latch - For the barrel, is it the texture itself or how it was applied? I'll work on that one funky face, I don't know why it looks like that though. As for the POVray, I think I understand what you're saying. I've never messed with it before, but that's why I'm here, to learn. I think I'll try to UV map the crate too, so there's only 1 texture. I'll see what I can do.

I don't see it as you picking apart what I create. I see it as critiquing, and I'm happy to know what could be improved. I know that I'm an extremely novice modeler, and any advice I can get that will help me become better is greatly appreciated.

EDIT: I found a neat little function in 3DC, the snapshot function, and I took a 2 pics of the crate, a side and a top. I cropped them so that they were the size of the crate, then reapplied them to just a plain cube. The effect is...underwhelming. It looks good if you're just looking straight at it, but if it's at an angle then the entire illusion is destroyed. I'll attach a pic.

Attachments

Login to view attachments
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 3rd Jan 2010 19:19
@Latch
Quote: "Is there anything you need from me in general. At present I've been trying to redesign the alien again... I started not liking it and the texturing needs a bit of work. If you need a general husk for sizing or positioning testing, I can probably get you that."

A husk would be more interesting to look at but basic shapes are fine for what I'm doing now.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 6th Jan 2010 00:45 Edited at: 6th Jan 2010 00:46
@NTTC
Ok, there is a headless, footless husk in the repository. I like the basic form of the alien. My intention was to have it lanky and strange looking with limbs that are just a little too long, but it ended up being a little too sleek with some angles in the chest I don't like. I dunno. The arms I like best, but overall, it doesn't look very scary.

Try it out in game (or in demo rather!) . The sizing isn't to scale. Try different scales and tell me what you think looks about right.

@Digger412
Quote: "For the barrel, is it the texture itself or how it was applied?"

I think it's the texture itself. It looks a bit like the flesh from the old FPS DOOM as opposed to rust. For the cube, you've got the idea with the snap shot and then rapplying the texture, one of the problems are the textures themselves. They sort of look like picture frames and tables tops. Very clean, smooth polished wood surfaces as opposed to boards nailed together to form a crate. I'm sure you could probably find a texture that looks a little more weathered and realistic. I have a good crate texture, but I'd rather see what you could come up with.

Even with your current textures, if you can figure out how to apply or create normal maps (for bumps and grooves), manage the specularity for reflections and highlights, also the diffuse and ambient for the color and lighting of the surface itself, and render the texture with these settings, you may be able to get so beat up realistic looking wood. I'll do a quick render in blender with normal settings jacked up to give an example. Nothing fancy, just to give you an idea of how the texture can be changed.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 6th Jan 2010 02:31
@Latch
Quote: "Ok, there is a headless, footless husk in the repository"

That's just what I wanted for Christmas!

Looks good scaled to 350x and colored alien green. My pathfinding is working pretty well. I should be able to post by the end of the week. Right now it's working when the player is in the house, tried up to 40 enemies with no delay. I have to add code to handle when the player exits the house. I'm thinking that for any enemies still in the house, they will navigate out of the nearest exit to the player. The only thing is how to handle once they get out, how to navigate around the outside of the house (the player may be on the opposite side if the house) or around other objects (trees, crates, etc.). I assume your sliding collision code will handle that.

I'm also going to play around with how to handle the boarded up windows. I'm thinking of making each board a limb of an object and it may take 7-8 boards to cover a window. When the enemy collides with the object, change the movement mode to a "break window mode". Then use a timer to remove one board (hide limb) every x seconds. When all boards are removed, set collision off for that object and switch enemy back to movement mode. What do you think?

@Digger
Quote: "I'm sure you could probably find a texture that looks a little more weathered and realistic."


Here are a couple of websites with good, royalty free textures:
http://www.imageafter.com/index.php
http://www.cgtextures.com/
http://mayang.com/textures/
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 6th Jan 2010 03:44
@Digger412
I'm including an attachment that shows what variations with lighting and bump mapping can do to alter textures. I used Blender for this example, but I imagine there are similar controls in 3d Canvas.

For the crate, I just took one of the wood panel textures you used with the writing on it, I textured a plane in blender, I pumped up the normal bump mapping, and I colored the specular dark brown. I then rendered the plane, and took the render picture to use as the texture on the cube. To me, although a bit dark, the wood looks much more substantial and bumpy and weathered instead of the bright pine color. I didn't put a lot of effort into it, but the results are quite a bit different than the original texture.

For the oil drum, I did something similar except that I baked the texture instead of rendering the entire object. Baking a texture is like rendering in that it will capture the normal mapping, area lighting and any reflections and recreate a texture with all of those elements. In Blender, at least, baking isn't as good as a full render. It's close, but I dont't think it uses the full rendering capabilities. At any rate, I've included a picture of barrels side by side using the same texture. 1 texture is unaltered, the other is baked with normal bumps so the surface looks a little bit more 3d. Though I still think this particular rust texture is colored like meat or flesh.

Enjoy your day.

Attachments

Login to view attachments
heartbone
21
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 9th Jan 2010 13:54
I just spent two years of my life at the university transitioning from software engineer to a high school math teacher, and what do I find when I come back?

Latch, sir you are a master teacher.
Simply wonderful.
Good luck with this project.

I'm unique, just like everybody else.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 9th Jan 2010 23:08
@Latch - I made another wood texture, it look much more beat up now. I found an awesome little program called xNormal, and it can make normal maps from 4 views of a photo texture (light above, below, to the left, and to the right). When I tried to use the normal map, though, I saw no difference on just a plain box textured with a snapshot of a side of the crate. I don't know if I did something wrong or what. Anyways, I haven't had time to work on (or figure out) the specular mapping, or work on a new texture for the barrel. I'll try to get that done soon.

I've uploaded the new crate with textures to MediaFire (DarkPro's>3D Models>Misc. Objects>Crate2.zip). I made two big textures and cropped it in certain places so it only uses 2 textures instead of many, and the wood pattern isn't nearly as consistent.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Jan 2010 14:48
@heartbone
Quote: " just spent two years of my life at the university transitioning from software engineer to a high school math teacher, and what do I find when I come back?

Latch, sir you are a master teacher.
Simply wonderful.
Good luck with this project. "

Thank you for the compliment and the good luck wish! Do you still dable in DBC? Perhaps you'd like to help out on 1 or two things.

@Digger412
Great! I'll take a look at that. Yikes, I'm falling behind. I still have to make stairs for the house and the second structure.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 12th Jan 2010 02:53
@All
I've posted some movement code to the repository. Download the contents of "Movement" as and it contains sub folders which are required to run. Enemies spawn and pick a random path toward the house (waypoints in outside paths are shown as plains). Once at the house it uses a series of waypoints (inside waypoints shown as purple spheres) and zones 1-13 (There is a png of the zones and waypoints in the Images folder). Using the players zone and enemy's zone, it looks up the appropriate path number (hard coded as data statements) and moves enemy along that path until it reaches the same zone as the player. At that point it switches over to LOS movement. If the player moves to a new zone, it looks up a new path for the enemy. If the player goes outside the house the enemy with move to an outside zone (zones 8-13) and then switch to LOS. I've added boards to the windows and set collision on. I'm using Latch's feeler object technique to test for collision with a boarded up window. If collision, enemy will "remove" one board every few seconds until it can pass through the window. This seems to work pretty well for up to 10 enemies. Once I go above that the program slows down due to the collision checks. Without checking for collision on the windows I've tested the pathfinding for up to 40 enemies with no slowdown. You can remove the collision by changing rem to remstart at line 456 and uncommenting lines 482 and 483. Occasionally the enemy gets caught in a 'death spiral' at 0,0,0 and the program will eventually error out with an array out of bounds error. I haven't figured out the cause of this bug yet. It will occur regardless of collision on or off.

That being said, I'm going to try to rework this with some 'real' pathfinding. Latch mentioned earlier in this thread that we should be able to develop some techniques that could be used in future projects. I don't want to ever have to hardcode all those paths again! I got a new book on AI in games and wanted to give the pathfinding another crack. For one thing I want to reduce the number of waypoints required. As you can see, I have two waypoints near every door. My thinking was that it would allow for more natural movement. So if the enemy was in the corner of zone 7 and needed to move to zone 1, rather than drag itself along the wall (sideways?) trying to get to the next waypoint, it would move straight toward the waypoint in zone 7 then to the waypoint in zone 1. I'm going to redo the waypoints using one waypoint in the doorway. Hopefully:

1. Latch's collision system will allow for more natural movement through sliding collision
2. We can come up with such a system
3. Worst case, the player never sees the unnatural movement because they are in a different room

As far as pathfinding, I've written some code for the Best First Search algorithm which seems to work well. I'm going to try to incorporate it into the movement code in lieu of hardcoded paths. I may need to clear out an array between pathfinding calls. Is it quicker to



or

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 13th Jan 2010 02:10 Edited at: 13th Jan 2010 02:13
Quote: "I've posted some movement code to the repository. Download the contents of "Movement" as and it contains sub folders which are required to run. Enemies spawn and pick a random path toward the house (waypoints in outside paths are shown as plains). Once at the house it uses a series of waypoints (inside waypoints shown as purple spheres) and zones 1-13 (There is a png of the zones and waypoints in the Images folder). Using the players zone and enemy's zone, it looks up the appropriate path number (hard coded as data statements) and moves enemy along that path until it reaches the same zone as the player."

Though I realize the inclusion of plains and spheres are to mark and show the paths and the waypoints, inclusion of them will skew your testing results. The presence of additional objects will effect performace.

Quote: "That being said, I'm going to try to rework this with some 'real' pathfinding. Latch mentioned earlier in this thread that we should be able to develop some techniques that could be used in future projects. I don't want to ever have to hardcode all those paths again!"

For the outside, the point of the waypoint paths is to have the monsters move along unpredictable lines. A path could start on one side of the house but end up completely on the other side.

A simple way to handle the creature movement on the outside would be for the monster to spawn on the edge of the scene somewhere and just make a straight run to the closest window of the house. I envisioned the use of outside waypoints to actually give some control as to where the monster may go, tricking the player so that the monster's movement and direction are not predictable. We could go either way, though I prefer the latter.

Quote: "My thinking was that it would allow for more natural movement. So if the enemy was in the corner of zone 7 and needed to move to zone 1, rather than drag itself along the wall (sideways?)"

Whatever happens on the opposide of a wall generally won't be visible to the first person perspective of the player. So the monster dragging itself along the wall won't be seen. But the collision should take care of that.

In regards to the movement in general, the code should be reduced - to one function if possible. The movement of the creature will have to be integrated with the collision checks, the players movement, and the weapon firing/usage. If the creature control code is too spread out in terms of multiple functions/subroutines it will be hard to integrate.

If the entire creature movement engine can be encapsulated into a single function or routine perhaps under the heading AI, then the game can be built more modularly. Try not to include the board tearing part, or any combat. The goal is to move the creatures to the entrances of the windows, then through the windows, then track the player inside the house or any structure. Start thinking about upstairs and downstairs as well.

Does it then become necessary for you to have the house collision setup and on in order to proceed? Or can the creature code be written so that it makes no difference? What elements are necessary in order to do path finding? Is it enough to just point the creature towards the player and try and move in that direction, and if the creature collides with something to just change it's direction temporaily and move it a bit? I guess mapping the openings between walls becomes important so the creature isn't just smashing it's face against the opposite side of the wall to where the player is. So it seems pathfinding is important, or hard-coded way points are important. If the monster can get into the same room with the player, then it's just point and move basically.

As far as tearing boards, I can see that as being the same code for attacking a player. At a certain proximatey to a board or player, the creature attacks. The boards would have health, so to speak, and after a certain number of attacks, it "dies". I imagine the boards as a single object with several limbs so the boards could be animated flying off into space as they are attacked and then the limb hidden. The entire object would be contained in an object collision box so as to reduce the collision checks. The other option is to not have any collision on the boards and just a check for the creature's distance, and whether or not the creature has attacked.

Anyway, the goal of your movement engine should be to be as modularized as possible, to only account for outside regular movement, outside movement when the player is outside, an entering interlude (transitional code from outside to inside), tracking the player inside, and following the player outside from inside if the player leaves.

What do you need from me to bring this to fruition?

Oh, and it should be faster to Undim then Dim rather than loop through the values and set them to 0. I think Undim just releases the memory (doesn't destroy it or overwrite it) and Dim chooses new available memory and wipes it clean.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 13th Jan 2010 04:38 Edited at: 13th Jan 2010 05:18
Quote: "Though I realize the inclusion of plains and spheres are to mark and show the paths and the waypoints, inclusion of them will skew your testing results. The presence of additional objects will effect performance."

The manual talks about being able to use 65,000 object but I'm starting to realize that 100 objects can bring the game to a crawl.

Quote: "For the outside, the point of the waypoint paths is to have the monsters move along unpredictable lines. A path could start on one side of the house but end up completely on the other side."

The waypoints in the example are very simple to get the enemy to the house ASAP. They can be constructed to be more unpredictable in the final build.

Quote: "In regards to the movement in general, the code should be reduced - to one function if possible"

I'll try to limit to one function/sub when I start trying to incorporate the best first search(bfs) pathfinding. Should the sub just figure out what type of movement to use and return new x,z coordinates and let some other sub figure out what to do if the new coord cause the enemy to reach the goal, collide with something, etc?

Quote: "Does it then become necessary for you to have the house collision setup and on in order to proceed? Or can the creature code be written so that it makes no difference?"

I don't think I'll need collision at this time. The pathfinding should, for the most part, not bring the enemy in collision with the house. There may be a little "cut through" but that can be handled by collision later.

Quote: " I imagine the boards as a single object with several limbs so the boards could be animated flying off into space as they are attacked and then the limb hidden. The entire object would be contained in an object collision box so as to reduce the collision checks."

That's how I set up these boards. Just doing it for fun to see what it looked like.

Quote: "Anyway, the goal of your movement engine should be to be as modularized as possible, to only account for outside regular movement, outside movement when the player is outside, an entering interlude (transitional code from outside to inside), tracking the player inside, and following the player outside from inside if the player leaves."

The outside waypoint system and LOS are done. It's the inside pathfinding and transitioning from state to state (especially as the player moves from inside to out) that I'm trying to get a grip on.

Quote: "What do you need from me to bring this to fruition?"

Nothing at this point. Just my one question above about what data the AI function should return and I'll go back and give it another shot!

[edit]
Actually there is one thing, given the basic elements of movement we discussed, could you give me an example of the type of program flow your talking about?
Example:

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 13th Jan 2010 17:10
Quote: "Nothing at this point. Just my one question above about what data the AI function should return and I'll go back and give it another shot!"

Well, this can be tricky. I'll have to put the events in a tentative list to get an idea of the flow:



After my list, it would seem that the AI function, per se, doesn't really return anything but rather calculates and moves the creature on the spot. Looking at the list, the thing to avoid is sending each creature a specific function one at a time as that would really slow things down. The idea would be to loop through all of the creatures at once in a single function or sub and in the midst of checking the creature for interior,exterior or collision, jump to the proper subroutines to handle this. If the player movement and the creature movement both have to access the same routines (like combat or physics for example) then they have to be global - meaning they would have to be subroutines.

The pathfinding could be in a function if it calculated all of the creatures at once. The problem would be when other triggers (like bumping into the player) occur and the program has to jump to code to deal with that. It can't do that from inside the function unless the subroutines are also contained within the function - or each creature calls pathfinding one at a time (which could really hinder performance as the function is called multiple times) and then the other triggers are tested based on what the creatures' next move would be.

Can the pathfinding be done without being in a function or a sub but rather code in a loop? The reason I'm trying to move the pathfinding out of a function or it's own subroutine is because those jumps back and forth take away performance in the long run. It's faster to run straight code than to jump, run code, and come back.

So the layout of the code might look like:



The reason I have other subroutines to call is because other parts of the program would use them (like the player) whereas pathfinding is only being used by the creature so there's no reason to have it as an extra function or subroutine but rather as code that's part of the ai loop of creatures.

In the main outline at the top of the post, in the design of the creature ai, you can just leave spaces/rems for the collision and the combat subroutines. Your ai should be able to function without these and be able to move your creatures around. Later, simply by adding the appropriate gosub, your code should be able to handle the additional routines without a hickup or any rewrite.

Quote: "...transitioning from state to state (especially as the player moves from inside to out) that I'm trying to get a grip on."


Hmmmm... Maybe we should eliminate the player going outside. That may simplify things. That would eliminate how to keep the player from just running around outside all day and eliminate the coding needed to keep the player within the bounds of the scene. Of course another option would be to solely use pathfinding for everything so the monsters always try to find a path to the player from anywhere on the board. Though that might mean all of the creatures crowd around 1 window trying to get at the player! So maybe not! But it might be a good idea to eliminate the going outside part altogether.

Or perhaps there are dedicated creatures to pursue the player outside. The other creatures keep getting into the house. Once in the house the "break in" creatures path-find or track to the player, but if the player leaves, they stay where they are if they are inside, and keep breaking in if they are outside.

On the outside, may be there are 3 or 4 patrol creatures that are wandering around the exterior of the house and run after the player if they leave. I kinda like that idea. That way there no cross over needed for the different states of interior or exterior in terms of pursuing the player. There is actually dedicated ai for each and dedicated creatures for each.

The level increases and game progression will be determined by killing the break in creatures. The roving creates are always constant. So if one gets killed it is automatically respawed and starts making it's way to attack. They would need a waypoint path also for their wandering or just a couple of patrol locations to move back and forth between, or they could randomly scramble around until the player is outside.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 14th Jan 2010 01:47 Edited at: 14th Jan 2010 04:55
Quote: "Can the pathfinding be done without being in a function or a sub but rather code in a loop? "

I believe I understand your outline. I'll try to rework the code to that format.

Quote: "Hmmmm... Maybe we should eliminate the player going outside. That may simplify things. "

That would make it easier but let me take another crack at it. Although we will need to explain/handle the player not being able to go outside the bounds of the world. I like the idea that once the enemy is in the house it wont go back outside after the player.

Quote: "That way there no cross over needed for the different states of interior or exterior in terms of pursuing the player. There is actually dedicated ai for each and dedicated creatures for each. "

The creatures who are on their way to enter the house would have to react to the player being outside otherwise they might just walk right past the player. Maybe have those creatures spawn at random location and move in a straight to a window. The outside enemies use the waypoint system to patrol a route. Both enemy types switch to LOS if player is outside and back to their previous state when player reenters the house. It is still going to involve enemies types having multiple states but I'll give it a shot. I can see where having UDT would come in handy....

[edit]
@Latch
Darkedit allows UDT syntax. Any thoughts or experience with using it?
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Jan 2010 19:10 Edited at: 14th Jan 2010 19:11
Quote: "@Latch
Darkedit allows UDT syntax. Any thoughts or experience with using it?"

Here's the thing with DarkEdit structures (User Defined Types) - the preprocessor breaks them into multidimensional arrays before sending the code to the interpretor (DB.exe) . While it is pleasing to the eye to see the type definition, it's not really an existing structure, per se, and error checking/bug fixing stands to be a little bit more of a challenge.

I'm not saying the preprocessor does anything wrong, but if there is a glitch or a bug or a special circumstance where the arrays it creates are a little off, finding a problem with the code could be a nightmare.

My personal opinion is to just use arrays instead of the preprocessor TYPE definition that you are aware of how you created/defined them, know their names, and can specifically track down errors related to them.

I can't really think of an advantage of using the preprocessed UDT in this case except for the naming convention and the dot operator. And if there were multiple people writing code or reviewing code on different editors, there could be real problems. I think it's best to stick to the design and syntax of DBC as it stands - that way it's more consistently translatable.

Quote: "That would make it easier but let me take another crack at it. Although we will need to explain/handle the player not being able to go outside the bounds of the world. I like the idea that once the enemy is in the house it wont go back outside after the player."

Ok.

Quote: "The creatures who are on their way to enter the house would have to react to the player being outside otherwise they might just walk right past the player."

You're right! Didn't think of that!

Quote: "Maybe have those creatures spawn at random location and move in a straight to a window. The outside enemies use the waypoint system to patrol a route."

Hmmmm... the player's strategy could then be to step outside and back inside to make the creatures respawn far away, over and over, so we might want to avoid this.

So maybe back to original plan with some modification:

1. most creatures will follow predetermined paths to different windows chosen at random.

2. there will be a couple of patrol creatures whose only purpose is to give chase outside.

3. any creatures outside will switch to pursue and attack mode storing their last waypoint in the process.

4. after the player reenters the house (the creatures can't come in through the door) all creatures return to their paths and the next waypoint

5. The testing of the player or creature for inside or outside can be determined with y collision. The height placement for the interior is a static collision test straight down. If we are using a matrix for the terrain, there will be no collision straight down. If we are inside the house, there will be static collision straight down. Bounds checking is probably faster though.



Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 14th Jan 2010 19:48
Quote: "My personal opinion is to just use arrays instead of the preprocessor TYPE definition that you are aware of how you created/defined them, know their names, and can specifically track down errors related to them."

OK. Like enemystate(enemy), enemyhealth(enemy), enemytype(enemy), etc. That's better than a multidimension array like enemydata(enemy,3) and having to remember that enemydata(enemy,2)is the enemies health.

Quote: "So maybe back to original plan with some modification: "

This sounds good!

Quote: "4. after the player reenters the house (the creatures can't come in through the door) all creatures return to their paths and the next waypoint"

Didn't realize that the door was not an option. Just have to delete a couple of waypoints. NP

Quote: "Bounds checking is probably faster though"

I am currently using a function which check bounds to determine what zone the player/enemy is in. Your previous post talked about not calling a function during the enemies loop but I don't know any way around this. I'm going to do the anemy AI/Movement in a loop but we need to know what zone the enemy is in at any given time and if the player's zone has changed anytime the player moves.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Jan 2010 20:12
Quote: "OK. Like enemystate(enemy), enemyhealth(enemy), enemytype(enemy), etc. That's better than a multidimension array like enemydata(enemy,3) and having to remember that enemydata(enemy,2)is the enemies health."

I meant that in the source, you would be looking at TYPE commands, but in the background it would be a series of multidimensional arrays which would make tracking down errors a bit harder (you wouldn't be seeing the multidimensional arrays you'd be seeing TYPE code). I prefer to use multidimensional arrays when possible in general instead of a series of individual ones - but in terms of naming, the individual ones are more clear. That preference is up to the programmer.

Quote: "Didn't realize that the door was not an option. Just have to delete a couple of waypoints. NP"

Yeah, since we decided back in the day that going outside was an option, it doesn't make sense to make the game unnecessarily harder by not being able to leave the house by having enemies blocking the door. It's not written in stone though. I'm still not entirely sold on going outside at all, but it's an interesting variation on the Nazi zombie theme.

Quote: "Your previous post talked about not calling a function during the enemies loop but I don't know any way around this."

This is what I meant:



is faster than



The straight code version (no function call) avoids eating the time it takes to jump to the function location in memory, process the result, and return it to a variable. If you can't avoid using a function, so be it. If you can sahve time off here and there, that's good, but let's get it to work first so do whatever you need to do. We'll optimize later if we need to. But keep it in the back of your head as you are coding!

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 14th Jan 2010 21:57
Quote: "I'm still not entirely sold on going outside at all, but it's an interesting variation on the Nazi zombie theme"

With so much left to do and given the fact that keeping the player in the house it would greatly simplify the AI it's something to consider. But I've got some direction now so I'll see what I can come up with!
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 15th Jan 2010 17:57
Quote: "With so much left to do and given the fact that keeping the player in the house it would greatly simplify the AI it's something to consider. But I've got some direction now so I'll see what I can come up with! "

Yes. Keep on track with the original plan unless there is an impassable obstacle. That's how it should be. I'm letting too many alternatives creep into my brain. That's a project killer! Ok I'm focused now.

Enjoy your day.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 16th Jan 2010 01:36
@NTTC
I started working on the environment again. Originally the house and the terrain were just place holders, now they are actually going to be used for the game. Here's the thing, I am thinking of creating the entire scene as one object. That means the house, the trees, anything stationary including the terrain, as one object. That should reduce some of the indexing time of individual objects and it makes the collision testing more consistent.

I know we've been over using a matrix as a terrain and it seems like it's just easier. There's a way to use polygon collision for the environment that's not as clunky as the feeler object demo I posted on the forums and earlier in this thread. Though my initial tests are indicating it's a little slower than static collision boxes, it will eliminate the need to set up a static environment (all that work I did building the static environment designer not used! ugh) . It means all the entities in the game will not have any collision set. But there will be a single invisible entity that will be used to test against the environment, the player, and getting shot.

As I was figuring out dimensions for the environment to add things, I started to think that it would be nice to have the terrain light mapped with shadows from the trees and such, and building the environment as a whole would help to that end. Also it would eliminate having to switch between different collision tests. My intention was to use static collision testing between the environment and the entities and then have box or polygon collision testing for the bullets or player/creature interaction. The use of static collision testing was also intended to return the point of collision with the environment, but it doesn't really work that way.

Anyway, how much trouble would it be if the design switched from using a matrix back to using an object? Most of this is theory in terms of performance. There's no real way to test the performance difference without actually doing it.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 16th Jan 2010 04:49
Quote: "Anyway, how much trouble would it be if the design switched from using a matrix back to using an object?"

I don't think it's going to effect what I'm doing. The only change I can think of is the way I set the y position for the player/enemies.

As long as your not changing the dimension of the house, I say go for it!
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 20th Jan 2010 22:56 Edited at: 20th Jan 2010 22:59
The house will stay the same. Now I forgot why I wanted to switch the rest of the collision...

Just a note: I chopped the polygons down on the big tree from 1551 to about 790 and saved the results (instead of losing the file!). It still looks ok. I think it's tough to make low polygon organics.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 23rd Jan 2010 04:04
@All
I've posted some new movement code to the repository. It's three files in the Movement folder. Hopefully you still have the folders from the previous code (Images, Models, Waypoints). The files should copied to the following folders:

FILE FOLDER
movement_engine1-6 ==========> root folder
lookupmatrix.ary ============> Waypoints>Indoor
bfswpts1.txt=================> Waypoints>Indoor
patrol1-2.txt================> Waypoints>Outdoor (this should be the only file in this folder)

The Best First Search (bfs) algorithm works and I began incorporating it into the movement loop but I decided that it was overkill for this project. With only seven zones (the 2nd floor should only add a few more zones) it seemed like a lot of calls to the function and DIM'ing and UNDIM'ing of arrays. But I also swore in a previous post that I would not handkey routes again. So, in a separate piece of code I used bfs to construct paths between all nodes and save the data to a lookup table. Depending on what zone the player and enemy are in, the movement code will look up the correct start and goal nodes and use the appropriate path from the lookuptable.

There are two types of enemies in the game, patrol and attack. They will exhibit different behaviors depending on whether the player is inside or outside the house.
Player Inside:
Attack enemy will spawn in one of a few areas (I've defined four areas in the attached code). It will then move toward a predefined node at a window. Once it reaches that node it will follow a path to the players zone. Once in the players zone it will switch to LOS. If player then leaves the zone the enemy will switch back to pathfinding until back in the same zone as player.
Patrol enemies will spawn and follow a patrol route composed of waypoints (two routes in attached code). It will loop around those waypoints.

Player Outside
Any attack enemies in the house will stop moving. Any attack enemies on their way to the house will switch to LOS. Patrol enemies will switch to LOS if player within 250 units. If player reenters the house the patrol enemy will resume patrol. The attack enemy will continue to the previously selected window node.

It works pretty well, I've tried for 20 enemies (can change variable maxenemies on line 489. The only function calls within the enemy loop are to the _which_zone function.

Some things I will continue to work on:
1. As perviously decided, we don't want the inside enemies to leave the house but it doesn't look good to have them just standing there. If the player has a gun the enemies would be sitting ducks to be shot through the windows. Two things I'm thinking about are a) Let the enemies move randomly through the house b) Remove the enemy from the house and have them respawn outside.

2. When an attack enemy is in LOS (because the player is outside) when the player returns to the house the enemy will move toward the predefined node at the window. Right now that might mean the enemy moves through the house to get to that node because there is no collision yet. While this may be solved when collision is implemented it would be more realistic to move the enemy to the closest window to their location.

3. Incorporating the second floor into the movement system.

Let me know what you think.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 27th Jan 2010 23:01
@NTTC
I've been focusing on learning to texture 3d objects lately and have been playing around with the alien a lot. I can't say that I'm pleased with the results but I'm still plodding on . Hopefully I'll have something done with that and the outside scene within the next couple of weeks - also life is making it hard to work consistently - but this project is still very much alive.

Quote: "1. As previously decided, we don't want the inside enemies to leave the house but it doesn't look good to have them just standing there. If the player has a gun the enemies would be sitting ducks to be shot through the windows. Two things I'm thinking about are a) Let the enemies move randomly through the house b) Remove the enemy from the house and have them respawn outside."


Hmmm hadn't thought about the sitting duck thing. The only problem with the respawn thing is the player could leave and come back to clear the enemies out and give themselves a break. Instead of roaming, the enemy could perhaps duck down low so they couldn't be seen through the windows or shot at.

Because of the height of the windows relative to the ground outside, I was thinking of making the enemies tall enough to reach the windows, but when they walk, they walk crouched down. So there could be a nother set of anim frames that put the enemy even lower than their normal walk, like a squatting kind of idle, or even being on all fours like an animal.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 28th Jan 2010 01:28
Quote: "Instead of roaming, the enemy could perhaps duck down low so they couldn't be seen through the windows or shot at. "

That sounds good, not much additional coding required.

Have you got a chance to look at/run the code I posted? If you think it's good I'll go ahead and get started with movement on the second floor.
pictionaryjr
15
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 29th Jan 2010 23:57
How long till you guys think you'll have a working demo?



You think it. We create it.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 2nd Feb 2010 02:46
Quote: "How long till you guys think you'll have a working demo?"

I don't know if there is a specific definition of what's considered "demo ready". To me it means something you can play for maybe a full level although it may not have all the bells and whistles yet. If so, that seems a long way off. If you read my post on the previous page it details what I've done for movement/AI. The objects are mostly placeholders. Latch is working on designing/lightmapping the environment and some kind of collision routine. I'm not sure if Digger is still on board but he was working on some models.

Anyway, I'd like to hear Latch and Diggers thoughts but for me, I couldn't even hazard a guess when a demo might be ready to post.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 2nd Feb 2010 04:29
Yes I'm still on board, but AP World History has had me tied in knots. I'm sorry that I haven't been active lately, but I have been keeping current on this thread. I haven't made any progress on a texture for the barrels, I can get a good pattern but I can't attain acceptable colors. As for the crate, I like the textures on it but I haven't figured out how to use bump maps, specular, etc. to make a low poly version. I may be able to shave off some faces by leaving the bottom just square, however. I would try organic modeling if i was more experienced, but I'm still a novice. I hope to be able to work on what I have this weekend.
pictionaryjr
15
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 2nd Feb 2010 05:57
a demo to me wouldn't even be a complete level lol. and was just asking for like a guesstimation (spelling prolly wrong lol). i knew yall wouldn't have one for a while, but was seeing if yall had kinda set yourselfs a deadline. and sorry i hadn't read up on the posts that had been put out.

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 2nd Feb 2010 10:54 Edited at: 2nd Feb 2010 11:00
@pictionaryjr
Here's a recap of a time line calculation I whipped up a few months ago. Some things have changed but the ideas still hold true. With NTTC's apparent success with the path finding and waypoint system, stage 1 may be nearing completion. However, I have redesigned the environment and the main alien several times. The collision system is basically done - though I haven't posted anything... Time is hard to find to work on this consistently, but baby step by bay step it is coming - so we are about 2 months behind from my prediction based on stage 1 completeness. Here's the lowdown from October or early November:



@NTTC
Exceptional! Your code seems to work fantastically! It ran at about 102 fps with 20 enemies. Each enemy is about 1000 polys so your code must be running very quickly. I like how the enemies find the doorways and follow the player through the house! I could see it being very frantic in game.

The patrol aliens didn't seem to respond until I was almost on top of them, though. Other than that, this is starting to look like a completable project. I must say that I hadn't looked at the terrain for a while with the house on it and such. With everything, it seems to look pretty good - It's good to get an idea of the size of the aliens. I'm glad you put those in instead of just place holder spheres or cubes. But alas... I've remade the alien again. This time I'm actually satisfied with it. It's about 200 polygons less also.

Anyway, good work on the tracking system. It seems to work very well. As far as the environment, with everything that's going on around here, it's probably another couple of weeks out. Hopefully, I'll have some time after this week to just work straight on some stuff. Is there anything that you need from me to help you take the next step? I can re-prioritize to complete the task.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 2nd Feb 2010 18:25
@Digger

I'm a novice at modeling as well. I don't think you need to do many organic models like Latch's alien or trees. I think if you can get the specular/bump maps down, you can stay focused on producing some boxes, crates, barrels, table, chairs and maybe take a shot at some weapons (axe, bat, handgun, etc.). If you want a break from modeling take a look at the design document to see what coding task still need to be completed.

@Latch
Quote: "Anyway, good work on the tracking system. It seems to work very well."

Thanks! After a couple of false starts, I was happy to finally get it working.

Quote: "The patrol aliens didn't seem to respond until I was almost on top of them, though."

That's a range check on line 132. It's set to 200 units so I can change it to 500 maybe and see how it looks. I'll hold off on setting up all the spawn zones and patrol routes until the landscape is complete.

Until then I'll work on two additional parts of the movement system. I do have a question on how you think your collision systems will handle these two things.:

Quote: "1. When an attack enemy is in LOS (because the player is outside) when the player returns to the house the enemy will move toward the predefined node at the window. Right now that might mean the enemy moves through the house to get to that node because there is no collision yet. While this may be solved when collision is implemented it would be more realistic to move the enemy to the closest window to their location. "

How will your collison system handle an attack enemy trying to get to a waypoint on the other side of the house using LOS? If the answer is "Not well" I will look at having the enemy try to enter the house from the closest waypoint (window) to their location. It may slow things down a bit because I might have to use a distance check. Even if your collision can move the enemy around the outside of the house well, I may still give it a shot since it's more realistic to have the enmy try to enter the house close to where the player entered the house.

Quote: "2. Incorporating the second floor into the movement system. "

To pathfind from the first to second floor will involve moving from a waypoint at the base of the stairs to a waypoint at the top of the stairs. Will your collision naturally handle the increase in y as the enemy moves from one point to another?
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 2nd Feb 2010 22:32
Quote: "How will your collison system handle an attack enemy trying to get to a waypoint on the other side of the house using LOS? If the answer is "Not well" I will look at having the enemy try to enter the house from the closest waypoint (window) to their location. It may slow things down a bit because I might have to use a distance check. Even if your collision can move the enemy around the outside of the house well, I may still give it a shot since it's more realistic to have the enmy try to enter the house close to where the player entered the house."


The collision as it stands would eventually find the aliens way around the house. But it's possible that if the waypoint was 180 degrees in front of the alien, then it might shift back and forth without an LOS scan 90 degrees to either side of the house it is at.

While it makes logical sense that the alien should then climb in through the closest window, it sets up another "cheat" for the player. The player can step out of the house until the aliens pool around certain windows. The player can then enter the house and just blast the aliens from the particular window, or run back outside and blast them in the back. It gives the player too much control over how the aliens move to windows.

An alternative may be to have 2 static waypoints that are on either side of the house 90 degrees left and right from the door. These permanent waypoints are juxtaposed far enough from the house so that the aliens move outward from the house towards one of these points (randomly selected) and then resume their hunt for their original last waypoint. So basically, it disperses the aliens in chase to outward positions and then they resume their hunt for the windows. The points have to be relative to the door and far enough away from the house not to obstruct the aliens.

My original collision test involves the alien turning 90 degrees away, walking, and then trying to move to a waypoint. If it collides, it does the same thing over and over until it gets to where it wants to go. This works great for things like trees or boxes or small things. So maybe for something big like the house, the alien turns 90 degrees and projects a collision test some distance ahead of it (maybe half the length of the house) and if there is no hit, it proceeds in that direction until it reaches that distance and then tries to resume it's waypoint search.

Quote: "To pathfind from the first to second floor will involve moving from a waypoint at the base of the stairs to a waypoint at the top of the stairs. Will your collision naturally handle the increase in y as the enemy moves from one point to another? "

Yes. It's a downward collision test for height - like in the castle exe I posted previously.

Enjoy your day.
pictionaryjr
15
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 3rd Feb 2010 00:14
haha lesson learned. Guess this is why i should read up on the thread before i post lol

Login to post a reply

Server time is: 2024-04-18 05:02:05
Your offset time is: 2024-04-18 05:02:05