Increasing AI enemy abilities

#1 How about using a set of variables which improve with each level? Like speed, reaction time, accuracy, etc ...

//WARNING
//Psuedocode ahead
if(level==3)
{
%this.speed=0.3;
%this.reaction_time=0.3;
%this.accuracy=0.3
}

if(level==4)
{
%this.speed=0.4;
%this.reaction_time=0.4;
%this.accuracy=0.4
}
//End of Psuedocode

That sort of thing.

#2 yah thats basically what I was thinking.

Not rocket science eh?

#3 LoL, no.

I always think that keeping things as simple as you can, means that there are less things to go wrong.

#4 true dat homie!


::}}{

#5 If I may add my two cents...

I wanted something like that for my game too, but I wanted the opponents to have more health the higher the level. The only problem I had with that is that changes to maxDamage are on the Datablock on the server, and changing a datablock mid-game is frowned upon, I think...

#6 true, well why not simply have the variables, that vary, attached part of editable objects on the TGB interface where the variables are inside behaviors attached?



Datablocks and all that I find clunky.



How critical, is a datablock, i mean games can be built without can they not. as much info can now be plugged in via the editor.

#7 I would imagine so. I wouldn't really know since I am only accustomed to TGE instead of TGB. :)

#8 yah datablocks seem kinda "oldschool".

#9 They're "old school", but they're essential for quick networking.

Any sort of static data that needs guaranteed duplication on the client side benefits GREATLY from the use of datablocks.

Their info [when creating an object, for example] is passed by id. So lets say you need to spawn 20 monsters when someone enters a room. Instead of the server telling the client EVERYTHING about each monster [taking lots of computing and networking power], the client can just say "use this datablock" and send a tiny packet of data across the network. The datablocks get transmitted prior to playing the mission, so the performance hit happens all at once.

Sure you could have the CLIENT have all the monster data, but that leaves the door open for hackers/cheaters to change their stats.

It helps server maintain AUTHORITY, without creating network slowdown.

In the event of dynamic generation of numbers/values, it would still be wise to use datablocks, but augment the data with dynamic variables. That way, you're still sending a small datablock, and anything similar between the enemies isn't sent twice.


When using datablocks, you have to understand that they don't really contain the actual data, they contain the "presets" for an object. They create and store variables for the object.

If a datablock for an object has "hair_Color" as an attribute, you can still CHANGE the attribute of the actual object by doing

%this.hair_Color="Blue";

Assuming the objects exists in your simulation (client or server). No need to change the DATABLOCK, because it just creates a starting point, and makes sure that you aren't creating a transient local variable. It creates variables attached directly to the object, and it gives them a starting value.

#10

Quote:If a datablock for an object has "hair_Color" as an attribute, you can still CHANGE the attribute of the actual object by doing

%this.hair_Color="Blue";

Just to note, this isn't necessarily the case all the time, but generally it's true. For example, PlayerData has a maxForwardSpeed member, which determines how fast characters using that datablock can move. You could, in scripts, say
%myPlayer.maxForwardSpeed = 1000;
but the engine only uses the datablock value.

The way I've gone (specifically in the case of dynamic movement speeds) is to store all the possible values in the datablock - in this case, storing movement speeds for walking, running and sprinting. Then to change between these only a little flag has to be sent over the network saying which of the three speeds we're moving at - then the Player object uses the appropriate field from the datablock.

If you feel like getting deeper into the engine/scripts, you could do something like that (I'm not really sure how TGB works in this regard).

Quote:Datablocks and all that I find clunky.

Quick, run and hide... ;)

#11 @ Daniel Balmert

Thanks!
That makes a lot of sense. I have to look up client/server tho to truly understand.




@Daniel Buckmaster
Thanks as well.
I am new to programming and am basically starting with Torque. I attempted to write scripts for player, simply as a cs ile called by game.cs and consistently would no work tho my behaviors would.

just a comfort thing I guess but as I move along I thinks I shall be incorporating them.


Chanks guys!

#12 I own TGB, and the use of datablocks is very veiled for that engine. It currently doesn't have a client-server architecture in place. Everything is just "running" and you have to tell it what data to send and receive to other simulations.

This will change in T2D though, so I would say don't give up on datablocks entirely. However, I wouldn't worry too much about datablocks if your game isn't multiplayer.

#13 nice, thanks.

#14 what is the status with T2D?

what will it involve for me? a paid upgrade, what are its advantages. i did a quick search but notta. if you have a link info i would be interested.

#15 No one knows. They will be giving more info closer to the time of launch.

Start here and read up through the latest blog: http://www.torquepowered.com/community/blogs/view/17923

One Caveat: TGB is an extremely capable piece of code. If you have a project mid development in TGB, you might consider finishing it before starting on a new engine.

#16 thanks,

yah no worries about being midway with anything. My plan is to have something up in 3 months but it is very small. I am still learning. I hope to make, what I make in these 3 months in one month or less in the future.