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
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 9th Oct 2009 02:01 Edited at: 9th Oct 2009 02:16
Sorry have to dp, I'm just sending these ideas into orbit as I have them so feel free to trash them or make changes.

I would like some sort of decision making and prioritisation in the game. Maybe there is a power box outside and it occasionally cuts out killing the lights and making everything harder to see and more difficult (maybe there is something else important that also requires electricity). The purpose of this extra dilemma is that in-between rounds there wouldn't always be enough time to board up the holes and get to the power box to fix it, the player would have to decide which is more important.

Mini Games: Little tests of button bashing and timing are great for heightening the tension.
Boarding up could be a game where the hammer wobbles and you have to press a key when it is over the nail to get a proper hit, this could be a simple graphic or actual 3D if we are that good
Bolting and unbolting the door could be tapping two keys to move the heavy wooden bar.

TGC Forum - converting error messages into sarcasm since 2002.
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 9th Oct 2009 02:20
sorry 3p!
RE: Pathfinding
If we defined "rooms" it would make the pathfinding quicker. Making that flexible might be a bit difficult, maybe something that looked at the placement of the walls and how each side is accessed would flag up possible "doorways". I'll give it a shot

TGC Forum - converting error messages into sarcasm since 2002.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 9th Oct 2009 05:52 Edited at: 9th Oct 2009 05:54
@Obese87
Quote: "RE: Pathfinding
If we defined "rooms" it would make the pathfinding quicker"
.
Feel free to try and implement it, but No Time to Code is also taking on path finding since you admitted laziness. You two should work together if possible.

I'm glad you are going to try and return to coding some means of path finding, however your barrage of new ideas may be adding a little more confusion than intended. The decisions have been made if you have been following the thread. I'll list things here clearly to try and avoid any misunderstandings:

* The main thing is to keep the game simple so it can be completed
* The game will be a first person shooter, arcade style.
* There will be only one environment: A farm or homestead.
* There will be a house and a shed/barn. The shed/barn is a storage structure where weapons are kept.
* Getting new weapons or more ammo requires making a trip to the shed.
* There is no stock pile of wood for repairing windows/baricades. Moving and carrying the wood adds an unnecessary element of no fun and complications
* There is no boss
* There is an increasing number of enemies that are perhaps faster and more durable with each level.
* Level completion is determined by killing enemies
* The goal is to survive as long as possible

And here's a reminder of the tasks:

Caleb1994 - generic 3d environment movement and camera views
left team

Obese87 - path finding for aliens to player for interior of house

Brick Break
left team

Robert the Robot - way point system for creatures to attack house windows and attack player outside

No Time to Code - design document updates and path finding

TheComet - environment model design (pathfinding DLL on the back burner for next project)

DarkDragon
undetermined

Digger412 - helping out with weapon models or other simple models as time permits.

Latch - making a lot of noise

@TheComet
Your barn is looking pretty good, but I think the consensus was that there would be a house and a barn or shed that was for storage. The barn/shed is where the weapons would be kept.

The outside environment/terrain will be traversed, so there should be some detail to it - trees, barrells, fence, grass, dirt bushes, etc.

@All
Much of the progress would have been determined by a working or semi-working environment - but TheComet's computer blew-up before he had a chance to work on anything. That's why I posted the placeholder house and terrain so there was something to work with for the other tasks. This is not a shot at TheComet, but just a reminder that we all can and should find ways to move forward if we indeed want this project to be completed.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 12th Oct 2009 07:39
Update on pathfinding:
My idea to lay down object plains and check for collision to define the node as passable (0) or impassable (1) worked fine. This data can be saved in an array or text file.

I found that I can't work with the terrain Latch provided because my PC locks up when I load all the nodes and then try to move. I'm sure it just my PC because I've been having all sort of problems with it. There are times when my FPS goes down to single digits on various applications. Therefore, I've been working with Latch's barn model on a matrix instead. Seems to work better for me. This finished code should work regardless although great variations in height could be a problem since this pathfinding is in two dimensions.

So far I've got the pathfinding to work for one enemy to find the player at a fixed location. Next steps:
1 Allow multiple enemies to find player
2 Allow enemies to find moving player. Since this pathfinding relies on nodes, I'll have to have some way of relating the player position to a node. If there are sufficient nodes the player can step from node-to-node but a huge amount of nodes is going to slow down processing speed. Otherwise we have to somehow tie players position to the nearest node.

This will probably make more sense once you see the code, which I will try to post in the next couple of days.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 12th Oct 2009 12:28
@Not Time to Code
Quote: "I found that I can't work with the terrain Latch provided because my PC locks up when I load all the nodes and then try to move. I'm sure it just my PC because I've been having all sort of problems with it. "

hmmmm. Not sure why that would be unless you are changing the collision status of the house from off to on. Loading nodes just means loading arrays does it not? So that's not additional objects or anything. At any rate, the size of the terrain grid I provided in the previous post is really overkill. Try using the terrain I've attached here. Instead of 80 x 80 tiles (12800 polygons !) this one is 10 x 10 (200 polygons).

I'll keep in mind what TheComet has stressed in terms of keeping things low poly. And if what your experiencing is due to the native DBC collision, it would be good to hash that out now and we might have to jump into using Sparky's as has also been suggested. We'll have to wait on the code.

@TheComet
Keep working on what you are doing. Even though I write very strictly in terms of what should be done to keep everything on a specific track, your model should fit in nicely.

Enjoy your day.

Attachments

Login to view attachments
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 12th Oct 2009 17:39
I did change the collision on the house to ON because I was checking for collision with the nodes but I'm pretty sure I cut it off after I collected the data. The nodes are objects (plains) and the enemy navigates the path by moving from one node (object) to the next. Of course the nodes will be hidden but must still exist. The other option would be to save the XZ coordinates of the node objects and then delete them.
As I mentioned, my PC is having some problems so I pretty sure it's just me. As a matter of fact, sometimes when I'm typing a post on the forum, there is a lag between hitting the keys and the text showing up on the screen! I need a new PC
I'm just making a few tweaks and I will get the code posted. It should make more sense then. I'm sure the new model will make a big difference as well.
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 13th Oct 2009 01:31
@No Time To Code
Nice, can't wait to see what you've done. I think you should officially take the lead in pathfinding as you seem to know what you're doing and I'm only just learning this stuff.
As for the hills in the level we could alter the travel cost to include the difference in height. Are you using the vertices of the level as nodes? I think that's better than using tiles.

I've been reading about heuristics and there are many different ways to calculate them.
Have you tried running the A* with multiple entities on screen?

TGC Forum - converting error messages into sarcasm since 2002.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 13th Oct 2009 04:18
Quote: "Are you using the vertices of the level as nodes? I think that's better than using tiles."

Thats an interesting idea but I don't belive it would work with the A* method I'm using. The walls of the barn and any other impassible objects would have to fall along the verices. If not, you could have a vertices on each side of the wall as passible so there would be nothing to stop the enemy from moving through the wall. It might be possible but I wouldn't know how to do it.

Quote: "Have you tried running the A* with multiple entities on screen?"

Thats next on the list. Just want to make a couple of tweaks to what I've got so far then get team comment on viability of this method. I don't think multiple enemies will be to hard, just more processing time. I think the bigger challange will be assigning the player position to a node. If the player is not forced to move from node to node, I will have to find some way of relating the player position to the nearest node. Also need to handle updating pathfinding when the player changes position.
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 13th Oct 2009 04:32
Quote: "Are you using the vertices of the level as nodes?"

I was thinking about varying heights of the terrain, using the vertices would avoid having to calculate the height, but now I seem to remember you can get height from anywhere with a matrix. Sorry I'm out of practice with 3D.

I'm going to do some A* coding just to get practice and so I can be of more help and understand yours when you post it lol.

TGC Forum - converting error messages into sarcasm since 2002.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 13th Oct 2009 05:23
If anyone has anything they do need to be built, I'm finding myself with a bit of downtime between school and other things. Throw out an idea, I'll pick up on it as soon as possible. I may decide to work on an axe tomorrow, if time permits..Tuesday is always busiest for me =/
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 13th Oct 2009 06:29
OK, here what I've got so far. I've attached two files. I can't zip so the other file will be in the next post. You will also need Latch's house model.

1. walk_around(w nodes) - This is the program I used to create and save the node data. It places plains on the map and checks each plain for collision. If collision = 0 else 1. This will define the walls of the house.

2.pathfinding_matrix1-2 - Using the data from above, this does pathfinding from start node (enemy) to goal (player). You can use the default data or enter new coordinates. Note: There is no error checking that the nodes you enter are valid. If you enter a node that is off the map or is impassable (1=Wall) the program will probably lock up or crash. It will color nodes light blue that are being searched. The final path will be colored purple and it will move the enemy along the path. You can switch camera views at any time with "V". I couldn't really get the enemy-eye view right but I didn't want to spend to much time on it. If anyone can fix it, be my guest. Hit "G" to toggle ghosting the house so you can see better. It will show the time it took to find a path.

Both example use a matrix (my PC flips out with the terrain - see above post).
@Latch - the new terrain is better but my PC still has problems.

In the game the nodes would be hidden but if this causes a performance/gamplay problem see my earlier quote:

Quote: "Of course the nodes will be hidden but must still exist. The other option would be to save the XZ coordinates of the node objects and then delete them. "


Depending on your comments I'll start working on multiple enemies next.

Attachments

Login to view attachments
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 13th Oct 2009 06:30
Here is the other file...

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Oct 2009 01:26 Edited at: 14th Oct 2009 08:16
@No Time to Code
I have checked out both programs. Very nice. The first file to find the passable positions works well, the pathfinding in the second file also seems to work well.

The problems you mentioned with locking up when using the terrain object have to do with collision, I'm pretty sure. The method in my test post of the house on the terrain uses a feeler object that moves up and down until it collides or doesn't collide with the terrain and then returns that height to position the camera. I think the feeler object is also colliding with your plane nodes so it can create an "infinite search for height loop" as it bounces between the terrain and a plane. I was able to get the camera to leap out of the suspected loop and then the program ran, but at about 35 to 50 fps. This is good and bad for a couple of reasons:

1. I had only tested the getting ground height with a feeler object without having possible conflicting objects in the same path or position, therefore, I have found that I need to work on this method of getting ground height to make it realisitcally usable in a game. So, now I have some information on where to go with that.

2. Having a grid of individual nodes, especially with collision destroys way too much processing power to be used in real time. The plane/node check is good for the initial setup to get an array of the passable and impassable positions, but beyond that, an array of the nodes, as opposed to actual planes, makes more sense.

I realize in the second program the planes are also used as a visual representation so we can see the physical path, but I wanted to address that I do not think they should be used in game (even hidden) but for the demo it is an excellent visual aid.

I also wanted to caution you on your approach to single versus multiple enemy pathfinding. The method has to be generic enough that it can be applied in any situation no matter the number of objects or enemies.

This is how I see the basic game flow of movement:


So perhaps your path system has to be able to be integrted into an overall game movement function. If entities in the game use the same function, all movement can be similar in a similar physical world.

And here's more monkey wrenches to be thrown in the machinery (not really) . When the player moves, the final target position in the path finding may change, but perhaps not enough to warrant an entire recalculation of the A* . Is it possible to only check the last node or target square against the player's new position and see if it still leads back to the enemy's original path? The test would be if the players current grid square touches or leads back to the previously calculated enemy path. That way you could eliminate a lot of time and recalculation of paths if say the character is just dodging back and forth in a room or confined area.

This may go hand in hand with a distance check between the player and the enemy - if the distance has reduced then perhaps the whole path is recalculated so the enemy can find a shorter route. If the path has increased then check to see if the original path still touches the player's new position and only calculate from the previous target to the new target and add that onto the enemy's path.

This may mean setting up a path array for each enemy


@Digger412
We need a bunch of miscellaneous things around. Fences, barrels (steel and wood), trees, bushes, chairs (broken and intact), dressers, chests, individual planks (for boarding up windows) - you can build any of thes and or collect them from various sources. If you collect them, make sure you can prove that we can use them in terms of copyright and licensing.

Also we need good quality sound effects. Good quality means if they are looped that they don't have an obvious start and end spot, they don't contain hiss, they are small in terms of bytes but sound good, they are monophonic (will allow us to use 3d spacial positioning with the built in DBC commands). Things like:
wind
rain
creaking boards
footsteps - gound, wood, metal, stone etc
dogs barking
crickets
tumbling tin cans
night sounds
etc

You, know, general night time spooky stuff and atmospheric sounds.

Enjoy your day.
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 14th Oct 2009 02:11
Quote: "This may go hand in hand with a distance check between the player and the enemy - if the distance has reduced then perhaps the whole path is recalculated so the enemy can find a shorter route. If the path has increased then check to see if the original path still touches the player's new position and only calculate from the previous target to the new target and add that onto the enemy's path."

Yes that seems logical, I'd even go as far as to say, if the player is further away than the target node just follow the original path. It stands to reason that if the player got to where he is from the target node so can the AI; the player would have to circle the enemy very quickly to create a shorter possible route.
If the player comes closer then yes a new path is required.
This does make me cringe a little for long paths though, I don't know how long it will take to keep recalulating paths. We could end up with AI that appear to freeze when the player runs towards them, like they are scared haha.

TGC Forum - converting error messages into sarcasm since 2002.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 14th Oct 2009 04:03 Edited at: 14th Oct 2009 04:04
Quote: "I was able to get the camera to leap out of the suspected loop and then the program ran, but at about 35 to 50 fps. "

I noticed this too, The first attempt to move would lock up and then (usually) eventually the camera would jump forward and then it was pretty much OK after that.

Quote: "I realize in the second program the planes are also used as a visual representation so we can see the physical path, but I wanted to address that I do not think they should be used in game (even hidden) but for the demo it is an excellent visual aid. "

Looking a the code just now, I think it should be easy (famous last words) to store the x,z and y if need be, values of the nodes in an array and do away with the object plains.

Quote: "This may mean setting up a path array for each enemy"

Thats what I was thinking. Right now the path is stored in an array so I probably just need to add an extra dimension to that array and store each enemies path.

Quote: "And here's more monkey wrenches to be thrown in the machinery (not really) . When the player moves, the final target position in the path finding may change, but perhaps not enough to warrant an entire recalculation of the A* ."

I agree. You could check if dist between current player position and goal node < a certain value, dont recalculate the path.

Quote: "If the path has increased then check to see if the original path still touches the player's new position and only calculate from the previous target to the new target and add that onto the enemy's path."

This might be tricky (at least for me). Also, it's possible that although the distance between player and enemy may have incresaed adding a path onto the original path might no be the shortest route.
For example - E is Enemy P is Player 1 is Wall = is path.
With this initial position you may have the path indicated:


Then the player moves to this new position which is farther away


If you add on to the old path like this:

It's a longer path then recalculating which would give you this:


Another challange is to relate the players position to a node since they will probably not be standing directly on a node.

But for now my task are:
1. Use arrays to get rid of object plains.
2. Add ability to pathfind with multiple enemies
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Oct 2009 08:08 Edited at: 14th Oct 2009 08:09
Quote: "This might be tricky (at least for me). Also, it's possible that although the distance between player and enemy may have incresaed adding a path onto the original path might no be the shortest route.
For example - E is Enemy P is Player 1 is Wall = is path.
With this initial position you may have the path indicated:"

Line of sight may have to come into play as well then. Part of the goal is to limit the number of calculations. But moving through rooms around walls and openings and eventually furniture or other obstacles will most likely require a method of path finding.

Obese87 mentioned something a few posts back about rooms. Perhaps if the open space bound by walls and/or obstacles was known and saved as bounding areas, then path finding would be used to navigate the enemy into these areas (where the player is) and then a simple "point at player" tracking system could be used by the enemy once it is inside the zone. That should reduce the path finding to those monsters that are outside of the zone and reduce the path finding calculations to much fewer iterations.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 14th Oct 2009 23:16
Quote: "plane/node check is good for the initial setup to get an array of the passable and impassable positions, but beyond that, an array of the nodes, as opposed to actual planes, makes more sense."

I've done away with the object plains, just saved the XYZ position in an array with the node number, speeds things up a bit. With this done I'll try to use the terrain model instead of the matrix I've been using. Hopefully I won't have that "lock up" problem any longer.

Quote: "Perhaps if the open space bound by walls and/or obstacles was known and saved as bounding areas, then path finding would be used to navigate the enemy into these areas (where the player is) and then a simple "point at player" tracking system could be used by the enemy once it is inside the zone. "


You should be able to define these "zones" and then set the doorway as the goal node. Then pathfind to the goal and let some other form of movement take over. IF the room is empty the navigation would be simple but if there are obstacles, not sure how you want to handle that. I know pathfinding will take longer than a simple distance check but if there are many obstacles in the room, as long as the room is small, A* may still find the path pretty quickly.

Anyway, that's a bit down the road because I'm still wrestling with the multiple enemies code.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 15th Oct 2009 04:15 Edited at: 15th Oct 2009 05:28
Here's a sorta okay looking barrel...I tried to do it with only 9 sides on the cylinder, so that's why it's so...odd. I've placed the little texture I attempted to create in the same .zip folder, I think it's ~110 polys.

EDIT: Loaded it into DBPro, good thing is that the 9 sides aren't even noticeable, I may even back it down to 6-7...bad news, apparently DBPro triangulates everything, so it double the polygon amount, it said 230 when loaded...crud. I'll back it down to 5 if I can..3DC lets me use quadrilaterals instead of triangles, why can't DBPro work with quadrilaterals.

EDIT2: I've had a 5 sided fail...sticking with the 9.

Attachments

Login to view attachments
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 16th Oct 2009 00:16
@Latch
Is there anything else I can do as NTTC is getting on fine with the pathfinding? I don't mind if it's pathfinding related, I'm going to have to learn the ins and outs of it sometime anyway.
But yeah any other jobs that could be done while NTTC is working away?

TGC Forum - converting error messages into sarcasm since 2002.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 16th Oct 2009 01:16
@Obese87
There were three or maybe four main elements I was hoping to get done:
1. getting a general environment done so there was something to look at and at least give a frame work for some of the other space dependant things
2. get the monster's to walk around ioutside to specific areas that would eventually be the points of entry of the baricadable structure
3. get the monster's to track to the player inside of the structure
4. have a general movement method for all of the enitites including the player

With those done, that would probably be more than 50% of the game engine. The graphics can be improved over time and added. Placeholder objects could be used until then.

The actual combat aspect of the engine needs to be worked on. Since I see this as mostly being projectile based, Sparky's DLL seems to be the best option for shooting. But the only hesitation on this I have is
a) I see this whole project as a challenge to complete something in DBC with as little external (DLL) help as possible. That would take some real thought and optimization to pull off for a good looking, and good playing game.
c) The pathifinding may require collision detection in the end to keep enemies from moving through each other and other obstacles. Sparky's not great at object to object collisions because it only casts rays, and you have to manage a series of cast rays from multiple directions to try and compensate. Even though a DLL is fast, too many function calls could still slow things down, so a lot is still depending on the overall game movement/pathfinding method(s) that we decide on in the end.
c) As far as I know, the only people on this project that have used sparky's to any extent are TheComet and myself - though it's not hard to use or learn how to use.

You seem to be pretty creative. You mentioned music earlier on in the thread. Is that something you'd like to try? Or perhaps something a little meatier like some basic physics. Just a few equations (nothing too fancy) where if something gets hit by a certain force from a certain angle it will move and or tumble. We don't need anything as complicated or procesor hungry as ragdoll physics. Just something to make items or entities get pushed, fall, and maybe roll and bounce. There's never anything clear cut and easy about physics while trying to keep processing down to a minimum - and the physics would have to function as a general library so the "whole world" could use them without specialization (and without grinding the game to a halt speed wise).

Also, we need an interface. A menu system.
I. Main menu
a) start game
b) quit
c) setup options?
d) load game
II. In game menu - pause
a) quit to main
b) start over
c) adjust settings?
d) save game
e) return to game
III. Hud
a) points
b) ammo
c) equipped weapon

What would you like to work on? What do you think you'd be able to do?

@No Time to Code
Quote: "IF the room is empty the navigation would be simple but if there are obstacles, not sure how you want to handle that. I know pathfinding will take longer than a simple distance check but if there are many obstacles in the room, as long as the room is small, A* may still find the path pretty quickly"
.
We should account for a lot of this with the environment design. Obstacles in general should be limited to along walls or blocking whole sections so open zones can be built with that in mind. The occasional something in the middle of a room can possibly be handled with collision. If the enemy collides with a non enemy object, path find around it to the player. If an enemy collides with another enemy it can turn left or right 90 degrees, take a step, then resume it's tracking towards the player.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 16th Oct 2009 02:29 Edited at: 16th Oct 2009 02:45
Got pathfinding done for multiple enemies!
I'll post the code when I get home tonight.

Quote: "Perhaps if the open space bound by walls and/or obstacles was known and saved as bounding areas, then path finding would be used to navigate the enemy into these areas "


@Latch
After thinking about it, regardless of how we handle it when the enemy gets to the door of a room, your method should greatly reduce processor time. If the player is in a room, just pathfind to the node representing the doorway. This way if the player is just moving from one part of the room to the other we don't have to keep pathfinding for each move.

This gets us into an area where some of the code (as far as defining a "room" and node for a "doorway' is going to become more dependent on a particular model. I'm perfectly happy with Latch's model but if we are going to use a different one, I'd like to see it before we do a lot of work that will have to be redone later.
@Comet - Any progress on your models?

I'm now going to try to figure out how to handle pathfinding on a moving target. If we use the pathfinding to doorway node and line of sight from there it might not be an issue. But for times where the player is outside or in a hallway, we are probably going to need some way to pathfind to the moving player.

This A* depends on nodes and I assume the player won't be limited to just moving from node to node. I'll need some way to relate the players position to the nearest node. The node # and XYZ coordinates are stored in an array. Any suggestions are welcome......
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 16th Oct 2009 02:58
Quote: "But for times where the player is outside or in a hallway, we are probably going to need some way to pathfind to the moving player. "

Every area would be a zone. When a player and an enemy tracking to the player are in the same zone, it is considered open and the tracking would be line of sight. If the player is in a hallway or another room, an enemy outside of the zone has to path find to the entrance of the room or hallway. So each enemy and each zone would have to be flexibl to adjust to it's current zone, player, enemy status.

Quote: "Reminder, this A* depends on nodes and I assume the player won't be limited to just moving from node to node. I'll need some way to relate the players position to the nearest node. The node # and XYZ coordinates are stored in an array. Any suggestions are welcome...... "

A node is really just a grid suqare, no? It has position. All we need is the players x,z position to relate it to the nearest node.

node number=current x + (z* (full width of x squares))

I the x and z of a node are stored as their own values - node 0 = (0,0), node 1 = (1,0) etc., then we have to use a world offset for the true x and z 3d coordiates. If node 0 is located in world coordinates at 200,200 and is 10 units in size, then the boundaries of each node are (node.x * 10) +-5 + 200 , (node.z * 10) +-5 + 200 . That should be enough information to extract the closet node to the player.


maximum node.x width = 100
player position = 1000,478
node.x = ((1000 - 200) / 10)+-5
node.z = ((478 -200) / 10)+-5
node number = node.x + (node.z * maximum node.x width)
node number = 80 + (28 * 100)
node number = 2880

If I did everything about right, the closest node to the player is node 2880. This assumes though that each node's x and z are stored as it's own local grid in increments of 1 but the area each node covers is 10 units and it's initial offset is 200.

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 16th Oct 2009 03:15 Edited at: 16th Oct 2009 03:34
Quote: "This A* depends on nodes and I assume the player won't be limited to just moving from node to node. I'll need some way to relate the players position to the nearest node. The node # and XYZ coordinates are stored in an array. Any suggestions are welcome...... "


@Latch
You probably have the answer but don't tell me, I think I figured it out.

[edit]
Dam, you've got an answer already!

Yes, the nodes are positions saved an an array like:
node(1,0) is node 1 X position
node(1,1) is node 1 Y pos
node(1,2) is node 1 Z pos

The node numbers run like this:
1,2,3,4,5,6,7,8,9
10,11,12,13,14,15,16,17,18
19,20,21,22,23,24,25,26,27
etc

That being said I don't think we came to the same conclusion but I'll take a look at both when I get to my PC and see which method will work.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 16th Oct 2009 07:12
I've attached the code for A* with multiple enemies. You can change the default values under the _get_input sub.

@Latch
I think I figured out the node number based on player position. I didn't need to use the array as mentioned in my previous post.
Node X runs 1 to 26 and Node Z runs 1 to 31 so to calculate Node X and Node Z I used:

Attachments

Login to view attachments
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 16th Oct 2009 11:42
I'm out of this for I don't know how long... My work started last week again...

TheComet


Make the paths of your enemies easier with WaypointPro!
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 16th Oct 2009 19:06 Edited at: 16th Oct 2009 19:13
Quote: "I'm out of this for I don't know how long... My work started last week again.."

No problem comet, see you when you get some time out

@Latch
I wrote the beginnings of two tunes for the game, one is a bit 80's slasher esque, the other is much more sinister but maybe a little slow paced. My Dad has an awesome keyboard so next time I go over there I'll see if I can record some things to upload.

Other than that I'll have a go with the physics. This project is showing me that I am still quite noobish; I seem to have focused on a small area of coding and gotten good at it, but there's quite a lot that's still a mystery to me.
*types physics into google*

TGC Forum - converting error messages into sarcasm since 2002.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 16th Oct 2009 23:33
@TheComet
Oh no! You always have some very interesting ideas and input, and you seem to be a prolific game maker! When you have time, come on back, and in the background maybe you can still work on models you were planning. One of the goals is to make the best game we can, including how it looks, so if you finish a fantastic looking barn house, tractor, anything, we could probably still use it. And maybe you can polish up your path finding DLL and get it to where you feel it is complete. There's always the future and more projects to make.

@Obese87
Cool. For some rudimentary stuff, take a look at the small physics library I was putting together a while ago. I never really expanded on it, but it does a few basics. It may be a decent starting point, or maybe it's all you need. It doesn't account for angular velocity or any kind of rotations. Those I just faked with some random numbers.

@No Time to Code
That is awesome! It's very exciting to see the enemy to player tracking coming alive! I guess I'll work on the house. I am going to punch a hole in one of the walls. I noticed in your original node setting program that a node was registering a solid wall as a passable space. You may want to verify all of the node positions and make sure they do not register a solid wall as open.

Enjoy your day.
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 17th Oct 2009 00:13
Thanks everyone!

I'm sure you can all keep this project alive with Latch's input so I have something to look forward to when I have time to join again! Remember to keep the focus very small. The main goal is to get the main player movement and collision working right now. Latch made a good example a few posts earlier on, I think it would be good to build on that.

BTW, how's that enemy of yours coming along, Latch?

@ No Time to Code

Very impressive! Keep that up and our enemies will be unbeatable!

@ All modelling people

With clever texturing you can extremely decrease the poly count. I'll be back shortly with an example.

TheComet


Make the paths of your enemies easier with WaypointPro!
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 17th Oct 2009 00:48
Quote: "BTW, how's that enemy of yours coming along, Latch?"

The original polygon count is way to high so I've been trying to figure out how to reduce that. I also have to "re-seam" it so when a limb bends, there's not such an obvious gap at the joint. It'll take a lot of work - but I should have something in a few weeks or hopefully sooner, that doesn't look too bad. I don't have the time to work on it everyday and I'm very slow at modeling.

Enjoy your day.
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 17th Oct 2009 02:16
Quote: "I don't have the time to work on it everyday and I'm very slow at modeling."


Same here... I just can't keep my deadline with modelling, because I'm really slow at it.

Anyway, what I meant with "clever texturing" is something like this:



This wall has only 2 polygons. Everything in that game has a very low poly-count, but they textured it well, so you don't notice it any more. To achieve this effect, you need to be able to lightmap. Latch wrote an awesome example on how to lightmap with blender, but I don't quite understand how to lightmap complex objects like a horse. Can you direct me to some tutorial, because I can't see any decent ones on google anywhere... I just need to know how to lightmap a complex object with the textures already mapped, maybe even repeating textures. How do I do this?

TheComet


Make the paths of your enemies easier with WaypointPro!
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 17th Oct 2009 03:42
@Latch and Comet
Thanks, coming from you guys that means a lot.

@Comet
Sorry to lose you from the team.

Quote: "You may want to verify all of the node positions and make sure they do not register a solid wall as open."

I think I got it. Once you finalize the model I'll verify all nodes again.

My idea on defining rooms or zones would be something like:
If x>1000 and x<1500 and z<2000 and z>1500 then room = 1

Would using all these <> operators greatly slow things down?
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 17th Oct 2009 05:56
Quote: "My idea on defining rooms or zones would be something like:
If x>1000 and x<1500 and z<2000 and z>1500 then room = 1

Would using all these <> operators greatly slow things down? "

Don't worry about operators. We have to use them and DB's are generally pretty fast. It's really intensive math that can slow things down. Trig functions tend to be a bit slow but again I must say, DB handles trig functions pretty well.

A couple of pointers would be

1. Use ! (not the same as; not equal to) instead of <> (not equal to)

if a ! b then do something
is faster than
if a <> b then do something


2. With conditions that you are testing for true, you don't need an = . A condition is considered true if it is not zero

a=1
if a=1 then do something
can be reduced to
if a then do something

and is much faster

This can apply to any test for any value that is not zero

a=-5
if a ! 0 then do something
can be reduced to
if a then do something


3. Squared values, x^2, can be handled faster as x*x

4. Assign function returns to values instead of calling the function multiple times; and it's value is the same

x=object position x(obj)
a=x+5
b=x*t/(r-y)
c=x-(2*x)+(543-cos(34)+x)


If you only need the value once or it changes with each calculation, it's faster to call the function than assign it to a value

y=slope*object positon x(obj)+yintercept

Enjoy your day.
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 17th Oct 2009 06:42 Edited at: 17th Oct 2009 06:59
Good stuff to know. I saw in your walk_around.dba code you used | instead of OR. Is that faster as well?

[edit]
I just realized that because of the y pos of the model on my matrix (it's too low), I was thinking that some of the windows were doors. Looking at your original model on the terrain object I see you only have one door. Should the windows be considered as movable nodes? Let me know and I will fix the nodes. I'm still trying to get my PC to play nice with terrain as an object.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 17th Oct 2009 06:53
@Comet - I understand your idea of clever texturing, but a wall is different from something like a barrel. The player has to know that it's atleast somewhat circular shaped, so that shoots the polygon count to the moon when you think about it's latitudes.
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 17th Oct 2009 12:26
Quote: "The player has to know that it's atleast somewhat circular shaped, so that shoots the polygon count to the moon when you think about it's latitudes."


Good point, so I recommend making the absolute minimum requirements. In this case, a round object would be 5-sided. At maximum 8-sided. We ARE programming with DBC, so it is advised to keep everything at it's minimum. Right now, we need to focus on the game play. As soon as we have a playable game, we can start to increase the poly-count of bad-looking objects.

I do have a little bit of time to model on the week end. Shall I make the stairs 3D or texture a 3D looking texture onto a plain object so it looks like stairs, but it is actually just a straight plain on it's angle?

TheComet


Make the paths of your enemies easier with WaypointPro!
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 17th Oct 2009 14:31 Edited at: 18th Oct 2009 04:53
Quote: "I saw in your walk_around.dba code you used | instead of OR. Is that faster as well?"

I think you are refering to
if upkey() | downkey()

OR and | are different. OR compares two complete expressions and | is an operator as a binary 'OR' between two values to create an expression. In this case they should function at about the same speed.

OR evaluates the truth condition of both poritions on either side of it.
is it true that upkey() is preseed OR is it true that downkey() is pressed?

| compares the bits of two values and returns a result where any bits that are on in either of the values, are on in the final result. So if either upkey() or perhaps downkey() have a value of 1, then the result of
if upkey() | downkey() is 1 - and that means the condition is true.
which is a single expression with a single return value.

@all
I think we should consider abandoning using two structures and going outside. I see going outside as complicating the play and the design unecessarily. Once outside, why would there be incentive to return to the house? It would have to be so dangerous outside that the player wouldn't want to stay there in which case it makes designing the outside world more complicated.

The monsters still roam around outside and try to gain entry but a single structure and no going outside would eliminate having to modify the outside tracking code to the player. It would also help to reduce the visuals (poly counts and so forth) because things far off in the distance, or even relatively close, could be pictures on plains - they wouldn't be run up to by the player. The house could be expanded to allow a little more movement indoors and also allow different areas to move to. The weapons could be upstairs, much like TheComet was suggesting a wood pile would be, or in another area of the house (an expanded version).

It would mean some design changes and node recalculations, but that's going to happen anyways as we adjust game play and environment. What does anybody think?

Enjoy your day.
demons breath
20
Years of Service
User Offline
Joined: 4th Oct 2003
Location: Surrey, UK
Posted: 17th Oct 2009 16:16 Edited at: 17th Oct 2009 16:53
@Latch: wouldn't one way of reducing poly count be to only load models when you were within a certain range of them? If you still wanted to do the going outside thing, that is. It would make the game more complicated but it might make it more interesting, add a little variety to the gameplay mechanism. You could find ways to sort out the "objects suddenly appearing" issue - maybe just through some fog, which could add a sinister feel to the game anyway. I'm not sure how quick DarkBASIC is at loading and deleting objects and it might even slow the game down to be fair, especially if you're texturing and scaling objects in-game. If not though, all you'd need to do was make an array with the objects, their positions and their angle.

EDIT: You could also just introduce some kind of boundary which the player couldn't pass - it could be just a railing or something, maybe some sort of trench with zombies in. It might add difficulty though if the player went up to it because you'd have to explain how the zombies got in (climbing over the railing, stepping on each other to get accross the trenches, whatever) and that sort of thing, but there might be a better way of doing a similar idea...

"A West Texas girl, just like me"
-Bush
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 17th Oct 2009 20:14
What percentage of ths project has been completed so far?

What sort of timescale do you see for completing it?

Anyone have any doubts on it ever getting finished?

I only ask because I would really like to help out with a community project but honestly think that the game genre isn't suitable.

TDK

Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 17th Oct 2009 20:14 Edited at: 17th Oct 2009 20:15
@ demons breath - It'd be easier just to load the objects then hide them, I think. Idk if DBC still processes events that happen to them if they are hidden, though. In DBPro, instead of loading an object again with another handle you can clone them (much faster in most cases), I don't know if you can do that with DBC.
t10dimensional
15
Years of Service
User Offline
Joined: 22nd Mar 2009
Location: Code Cave, USA
Posted: 17th Oct 2009 21:02
Latch, No Time To Code, TheComet and OBese87 have been keeping this project well alive. I think if they keep it simple they should have at least the running game maybe by the end of the year.

Razerx
No Time To Code
15
Years of Service
User Offline
Joined: 22nd Dec 2008
Location:
Posted: 18th Oct 2009 00:38
Quote: "OR needs two complete expressions and therefore in this case would be slower than
if upkey() | downkey()
which is a single expression with a single return value."

@Latch
I think I understand but I substituted OR for | in the above line
if upkey() or downkey()
and it still works. Is it still slower then |?

Quote: "I think we should abandon using two structures and going outside."

That's fine with me. If the house is interesting enough and large enough the game could be contained in the house. It would just be cool for the player to look out of the windows and see the enemies coming toward the house. I think we would have to keep the rooms square or rectangular in shape to be able to define the rooms or "zones" as we discussed above. The hallways are going to be a challenge since you have overlap in areas.

Quote: "What percentage of ths project has been completed so far?

What sort of timescale do you see for completing it?

Anyone have any doubts on it ever getting finished?"


@TDK
This is my first team project so I'm not sure I'm the best person to answer these questions. I'm hopeful but have had my doubts about it being finished because we have had some of the more experienced programmers drop out(The Comet and I'm not sure the status of Robert The Robot). I think it would be a challenge to finish by the end of the year especially with the holidays coming up. Latch has been holding the team together and your help would be invaluable.
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 18th Oct 2009 00:52
@ TDK

Well, I suppose with the very basic movement, a simple debug level, a gun, and a barrel we have about 2% done. The goal isn't really that far away, it's just putting your mind to it that is the problem.

I don't think this project is going to take longer than a 2 years, but you can't really set a deadline for artistic things, especially for software.

I don't have any doubts that this will get finished. I'm going to stick with this until I'm satisfied. As long as people WANT it, they will GET it. And I do want it.

Quote: "but honestly think that the game genre isn't suitable."


Your opinions are of course welcomed with gratitude. Please, go ahead and suggest changes we can make to this project. What genre did you have in mind?

TheComet


Make the paths of your enemies easier with WaypointPro!
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 18th Oct 2009 01:28
I don't want to 'throw a spanner in the works' so I asked the questions because:

a) I'd like to get involved in a community project

b) I do have an idea for one...

c) I didn't want to suggest anything different that required everyone's hard work so far to be scrapped if too much had been put into it already.

a) I haven't before because the genre chosen has always been wrong or too ambitious. You need something for a community project that when split up consists of very simple elements so beginners can handle.

You can do an RPG or FPS with DBC but the basic elements can be quite complex.

b) I've never done a proper 'big' project before because I've never come up with a subject I was interested in. I now have an idea which I've been playing with for the last few days and think it could work.

It's at a very early 'thought' stage at the moment, and I haven't yet decided exactly the way it will go - making it a nice CP idea. The community can decide if it would best be an exploring, trading or fighting game - or bits of all three. It coud even include an FPS element if required but would stand on it's own without it.

I won't say what exactly my idea is right now - I'll knock together a little demo and put it in another thread. What I will say though is that it's going to be a lot, lot easier to write than an RPG and everyone can join in.

And, even if it's not used for a CP, I still intend to run with it, so don't worry about preferring to carry on with this one.

TDK

Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 18th Oct 2009 01:52 Edited at: 18th Oct 2009 04:46
@No Time to Code
Quote: "@Latch
I think I understand but I substituted OR for | in the above line
if upkey() or downkey()
and it still works. Is it still slower then |?"

What the? I tested it out before I worte that message and I was getting errors - now I test it out and it works! I must've been half asleep! Sorry for the misinformation on saying it wouldn't work - I'll go back and edit that message so someone else reading it doesn't get the wrong information. Anyway, in this case I think they'll both work at the about same speed.

@Demons Breath
Quote: "You could also just introduce some kind of boundary which the player couldn't pass - it could be just a railing or something, maybe some sort of trench with zombies in. It might add difficulty though if the player went up to it because you'd have to explain how the zombies got in (climbing over the railing, stepping on each other to get accross the trenches, whatever) and that sort of thing, but there might be a better way of doing a similar idea..."

This is mainly what I'm worried about. It almost be as if the outside would have to have a complete game coding system of it's own. While I like the idea of the slight change in environment - inside to outside and a second structure, I'd like to avoid the project getting side tracked by working on the outside interface. The logic of the monsters getting onto the farm from somewhere and the player not getting off of the farm is just a little bit of an added puzzle.

In regards to poly counts, there are a lot of tricks to handle this; some you have already pointed out, some others have pointed out as well. We'll have to have optimization in the coding itself and also perhaps as a choice for the user. For example, screen size and depth selection. 32 bit versus 16 is much differnt in terms of performance and of course actual screen resolution. 640x480 will run a lot faster than 2048x1536 and the polycount issues may not be issues at all.

@Digger412
Yes, hidden objects take much less processsing than visible objects - anything not having to be drawn is basically a little speed boost. There is no cloning, however. Duplicate objects generally have to be loaded for each occurance as an independent object especially if it is animated or has multiple textures.

@TDK
Quote: "What percentage of ths project has been completed so far?

What sort of timescale do you see for completing it?

Anyone have any doubts on it ever getting finished?

I only ask because I would really like to help out with a community project but honestly think that the game genre isn't suitable"

No Time to Code was working on a design document, I expanded it to be more of a project management document. The contents are still incomplete as the volatility of the team was in question and then members come and go as they have time. I also started to wonder if the document would actually be read and followed and if it made sense for a project where the only payoff was the completeion of the project with no one having any real accountability. So considering all of that, the project is starting to evolve with it's own life - a little less formal than I had imagined initially. Tenatively I would break down the initial phase of the project into 4 stages:

1. A working environment. This may not be the final environment, but close enough to be worked with and allow development in other areas. If I modify the house model and use the same terrain object and plan an additional structure, I'd say the environment is about 40% done

2. A way point system to create paths to have the enemy enter the inside structure from the outside. The team member working on this said they were making progress a week or so ago but we haven't seen any applicable or testable code so I'd have to say this 0% completed at this point.

3. A waypoint/tracking system for inside of the house to track enemies to the player. This looks to be almost complete. The code may need to be weworked a bit to function as a library and increase it's flexibility so I'll put it at about 75% complete.

4. A general movement system. This includes the speed of the player and enemies as they move through the environment, where the camera is in relation to the player's perspective, any controls - forward, backward, turning, strafing, jumping - and any world physics. There are some generic controls implemented for testing but they are by no means final. I see this as one of the easier aspects so I'll give it a 30% completion at this point because we actually have some movement and there is already some enemy tracking in place.

If each of these 4 carry a weight of 25% for the initial phase that puts us at about 37% complete for the first phase. I see the first phase accounting for most of the game. The remaining phases being combat and general physics, and user interface. I would place phase 1 somewhere between 60% and 70% weight for the game so that means about 22% to 25% of the game is complete. That's my tentative analysis.

Time scale:
Well, this is the worst time of year to work on this with a lot of holidays coming up, quarter end and year end processing for various jobs, people are going to be pulled all over the place so it's hard to say. If we can get phase one completed by the end of November, then it may be reasonable to finish by the end of January 2010. It's really hard to say. Part of the process is letting people try out things that they haven't done before - that may be successful or not and may change the time line.

Getting finished:
Part of the plan is to keep the game relatively simple. There's only one goal and one small unchanging environment.

Quote: "...but honestly think that the game genre isn't suitable"

I don't understand what this statement means. It's not suitable for whom or for what?

Also, there is a thread for beginners called DarkNOOBs where more experienced programmers help beginners through a project. This thread was aimed at more advanced programmers doing something similar to DarkNOOBs but for an audience with hopefully, a more developed skill set than perhaps would be required for DarkNOOBs.

Enjoy your day.
TDK
Retired Moderator
21
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 18th Oct 2009 03:51
Quote: "Quote: "...but honestly think that the game genre isn't suitable"

I don't understand what this statement means. It's not suitable for whom or for what?"


Sorry - it was a bit vague wasn't it.

It's my opinion (which doesn't make it right I know), that a CP should allow all participants to attempt any part of it if they want to. As people drift in and out over time, the easier and therefore quicker it is to complete, the more chance of holding interest in it.

Maybe I'm wrong, but I don't think an RPG or FPS is the best type of game to write as a CP. With the complexities of modelling, AI and character animation to list just three, it usually ends up with one or two key members of the group doing pretty much everything, while the others get bored and drop out after a while.

Don't get me wrong, I'm not trying to talk you guys out of this project. I'd love to see a CP succeed on here.

I had an idea for a nice project and would like to get others involved in it (if anyone was interested) but I didn't want to ruin this thread or step on anyone's toes - hence the questions to find out what stage this one was at.

On reflection, it sounds a bit selfish, but that wasn't intended...

TDK

Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 18th Oct 2009 03:58
Quote: "Once outside, why would there be incentive to return to the house? It would have to be so dangerous outside that the player wouldn't want to stay there in which case it makes designing the outside world more complicated."

I thought there would be a contextual reason for returning to the house, such as your family is hiding in there. I do agree with you though we should probably restrict play to within the house. It will probably cut our development time in half.

@TDK
Great to hear from you, does this mean you'll be joining in?
I'm sure we could use your help even if you don't have the time to be taking on jobs yourself.

TGC Forum - converting error messages into sarcasm since 2002.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 18th Oct 2009 04:45
Quote: "With the complexities of modelling, AI and character animation to list just three, it usually ends up with one or two key members of the group doing pretty much everything, while the others get bored and drop out after a while."

There's another aspect to consider: there are a lot of people watching and seeing what will come of this. Some people are very excited at seeing the development and the possibility of pulling off the goal - it may be sort of inspirational to some. In that regard, it's exciting to the community even if they aren't directly participating. They may even be gleaning information for there own projects. So even if it came down to a couple of people doing a majority of the work, the community is still involved. And even if a project wasn't finished, people along for the ride got something out of it.

And no matter what the size or difficulty level of any project, many people are excited at first and then just lose interest because there's nothing at stake and the tasks that need to be completed are no fun. Who has fun if their job is formatting text or tracking down bugs in a file loading routine? It's not fun to most; but it's a job that has to be done even if it's not hard to do. And most people want to see or make explosions rather than figure out why the "S" is on the other side of the screen in the menu. So I would say community project maintained participation is always a gamble.

The people willing to try new things and ask questions and learn along the way are the people that are going to keep contributing and keep trying, and I think we have some people like that on this project.

And TDK, if you would like, please join in. We could always use some expert level help.

@Obese87
Quote: "I thought there would be a contextual reason for returning to the house, such as your family is hiding in there. I do agree with you though we should probably restrict play to within the house. It will probably cut our development time in half."


It's something we'll have to consider. After hearing some opinions on the matter, I think we can continue as we are going. We'll finish up the primary tasks of getting the monsters to the house, and then getting them in the house and tracking to the player. The outside play won't affect this process. It will really come into play when we start the combat portion. It's just good to hear some feedback.

Enjoy your day.
Digger412
16
Years of Service
User Offline
Joined: 12th Jun 2007
Location:
Posted: 18th Oct 2009 04:56
Quote: "There is no cloning, however."


Darn. DBPro has it, so I'm used to just using 'clone object'. You can format your models to .DBO, though. That'll tremendously help the loading time (for me, 8 skyboxes in .x format take about 30 seconds, in .dbo they take about 0.45).
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 18th Oct 2009 05:17
@Digger
you can use MAKE MESH FROM OBJECT and MAKE OBJECT [object number],[mesh number] to clone objects. I'm not sure if texturing and animation go with it though.

TGC Forum - converting error messages into sarcasm since 2002.
demons breath
20
Years of Service
User Offline
Joined: 4th Oct 2003
Location: Surrey, UK
Posted: 18th Oct 2009 06:10 Edited at: 18th Oct 2009 06:13
I still think the outside part of the game sounds interesting, but as you say it would be a completely different challenge in itself. But I think the best way to approach it would be to complete the internal game. Then evaluate whether you think an outside section would be worth it (weigh up the effort against the improvement in outcome). I would definitely prefer to see a more completed game finished than a half-finished but more complex game though, obviously, and I'm quite interested to see the results of this project, whatever the outcome.

EDIT: also Obese you'd just have to weigh up the make mesh from object and make object commands along with the added texturing that would entail against the load object with pre-existing texture commands. I don't know which would be faster and honestly I have no idea how to figure out what would be faster (I generally use a combination of trial and error, logic and the fact that nothing I've ever needed has had to be speed-optimised in that I generally make projects as learning exercises more than completed games).

"A West Texas girl, just like me"
-Bush

Login to post a reply

Server time is: 2024-03-29 14:37:57
Your offset time is: 2024-03-29 14:37:57