Full Engine coding ?

#1 It's possible, but why? Nothing is secure - one way or another someone will hack, crack or cheat your game. The scripts in T3D are precompiled to bytecode and are not human-readable in the shipped product. Additionally, like any good script interface, nothing heavyweight is done in script - it's not like they wrote the renderer in script, nor any of the 3D math functions. Overall game performance would probably not improve by more than 10%~15% with this change in a finished product if you utilize the engine as designed. So, unless you're taxing the hardware to the breaking point you probably will gain far more in shorter dev time using the engine as intended than you would gain in performance or security by making the modifications you describe.

It would almost be easier to build the whole game from scratch than to overhaul it the way you're suggesting. Almost....

#2 You would be surprised at how easy exploiting a script engine is, from decompiling a script to doing a full class dump without relying on any engine function.
I am a reverse engineer and Ive done the two things i mentioned above on Unreal Engine 2 / 3.

Coding in C++, would not only give me those 10% performance boost but also give me an option to virtualize (Themida VM) critical functions such as the server-client handshake / packet encryption / device hooking scan / built in anti cheat.

"Nothing is secure", this is 100% correct, but at least you can try your best at securing something if you know what youre doing, coding in TorqueScript would expose all my game logic to any attacker that will have his hands on a decompiler tool, which may be the case in a few months or years just as what happened about Unreal Engine.

My goal is to learn the most out of this engine and then write a basic FPS game and develop it for multiplayer, but starting in TorqueScript and then trying to secure all the game with it will take more time than coding in c++, at least its what i believe.

Hope to hear from someone who have done a full engine coding.

Thanks.

#3 Going full-on C++ is possible but it's not inherently more secure than TorqueScript and it does have some pretty clear disadvantages, like slower development time.

From a multiplayer standpoint, the Torque way of doing things is to assume the server is the final authority on game updates - positions, command actions (firing weapons, etc.) and so on - are all processed by the server. Each client maintains their own game state for interpolation purposes but the server pushes out updates at timed intervals to keep everyone in sync.

In reality, you could ship a game with all of your scripts in plain, human-readable format and be perfectly fine (in fact, both Tribes and Tribes 2 did this). Just because a player has access to all of your game logic, datablock/object definitions, etc. doesn't grant them any magical cheats. Modifying something on their end will have no effect while playing on a server (because datablocks are downloaded from a server to the client at load time - effectively overwriting any changes they've made to their local copies).

If you're interested in security issues with Torque-based multiplayer games, do some research on Tribes and (especially) Tribes 2 cheats. You won't find many and those that you do find tend to be mesh replacements (like making flags bigger) and an accompanying CRC bypass.

#4 Im planning to rewrite the whole net interface as i plan to write the server in c++ and using linux apis for better performance.

My goal is to make an online fps game this is why i prefer to do the hard job now rather then changing all what ive done in the future.

I guess the best way is to do it in TorqueScript, modify the VM compile / exec and add a few encryptions to protect the scripts.

Then write the whole net engine in c++e and have the packet handlers in TorqueScript :\

#5 Why would you rewrite torque's networking? It's networking is amazing, and all handled in C++. It ran on games like Tribes and Fallen Empire: Legions, (multiplayer FPSs), it'll work on anything made today.

As for the 30% of the engine being C++, It may look like a lot is done in script, but the bulk of the engine is still C++. Things like editors or scripted events don't need the efficiency of C++. The engine is 19.8MB of C++ files (not including the libraries used, just the engine source), the Pacific demo has 197KB of scripts, and the tools sections has 6.41 MB of files, most of it being GUI art.

#6 One question then, why does the pacific demo lag on a i7 930 3.2Ghz, 16GB 1066Mhz ram and GTX 590 3GB PC?
And how many players can the current TorqueNetwork handle?

#7 I thought the Torque networking could easily handle 128 players?

As for the pacific demo running slower than expected on high end machines. Is that due to scripting? Or unoptimised rendering/physics?

#8 I haven't done any modification to pacific ocean and your question is pretty much the point of this topic, "Does scripting cause this pacific ocean lag?".
Cause if yes, i don't see any player that would play an FPS game with that kind of lag.

For the TorqueNetworking, 128 players is small compared to todays gameserver that handles about 3000 players per server.

#9 Unless you can get T3D to compile without RTTI, there is zero security, weather you write your simulation in C++ or script.

In terms of performance, don't optimize early. Think scripting will be your bottleneck? Every Call of Duty game runs at 60fps+ and the simulation is entirely in script; Torque is capable of this too, just make your game then make it fast.

#10 Ok, you're new to Torque. Perhaps you should get to know the engine before rewriting vast expanses of code.

I don't get lag in the Pacific demo. My rig is an AMD Phenom II 2.8 GHz with 4 gigs RAM and an ATI Radeon HD 5500 series graphics card. I use a Linksys network card and I'm running on an Asus motherboard (can't remember the model). 3+ years old. Playing multiplayer with friends I get network latencies between 7 and 70 ms from next door or across the U.S.. You might have another issue....

#11 Sorry, i meant to say video lags, not network lags, sorry for the confusion.
Ive got convinced to stay on scripting rather then writing full engine, but now my concern is the torque networking, it handles only around 128 players while my goal is to have 3000 players per server like any modern game does it.

#12 The problem you experience in the pacific demo is becouse it's not optimised. (models/scripts/etc)

#13 I don't know any FPS that has 3000 players per server, but I do know that I've been waiting a long time to have FPS's that support 128 players and was extremely surprised when PS3's M.A.G. hit the 256 mark before PC.

Now I'm not saying I've seen every game ever made but those are my observations and if I can get to the 128player mark then I will be very happy.

As for Framerate problems you are going to see this in any unoptimized engine, for example the Soldier does not have a single LOD... that means that the model is fully loaded with no optimization therefore wasting resources that could smooth out your Framerate.

Look how far Rockstar had to go with GTA, even with the new engine you still see LOD "popping" because there is so much going on that cant be loaded at the same time or else it would be unplayable.

#14 "Handles only around 128 players" is inaccurate. Bandwidth and server horsepower make a huge difference, but there have been people who have reported numbers like you're looking for. Remember, the networking code is largely intact from TGE, which was designed to host servers on Linux. Just because Quake-like FPS games would do well to limit the number of players because of the sheer amount of data that would have to be shoved over the pipe does not mean that the system is not capable of handling that many connections. It's all about bandwidth, man....

#15

Quote:my goal is to have 3000 players per server like any modern game does it.

We're speaking different languages - I think people here are referring to 128 players in a game together, while you're talking about a matchmaking (master) server. There is no FPS out there that supports 3000 players in the same game concurrently (oddities like Planetside excepted, of course). Torque is not a master server; you'll need to provide that part yourself, and it'll be your responsibility to make it support 3000 players ;P.

#16 Try turning the lighting option to low in the pacific demo. It seems to be really shadow intensive, and all the water certainly doesn't help. I have an Intel i3 and ATI HD M4300 (nothing great). I can run it kind of smoothly with everything maxed but the lighting low. Torque is really hard for me to handle on high lighting, it seems to be the slowest part of the engine.

Quote:while my goal is to have 3000 players per server like any modern game does it.

Like what modern (non-MMO) game? MMOs have completely different structures to split up how player networking is handled. Usually all 3000 players aren't updated to eachother at once in an MMO.

Torque's networking code is top tier, the way it handles updates I personally think is higher than Source's network code, the rest of it is up there with it as well.

Also you won't be able to script decent networking.