Advertisement

Is this how modding works (dll and VM)?

Started by January 07, 2004 08:28 AM
1 comment, last by eSCHEn 20 years, 10 months ago
Ok, I just had a large ''ding'' go off in my head and a lightbulb appear: I think I''ve just worked out how a modding a game works. I''m pretty sure I''ve got it right, but just to clarify I wonder if you could tell me if I''m correct or not? Here goes. You have a game, and in that game there are different engines such as physics and renderer. Each engine has a set of functions in it for doing different things, so for an example the physics engine may have:

function MovePlayerForwards(PlayerPosition: TPosition):  TPosition;
begin
  // move player 1 unit forwards
  PlayerPosition := PlayerPosition + 1;

  // return the new player position
  Result := PlayerPosition;
end;
Now this function is stored in a dll called ''originalPhysics.dll''. If a person playing the game thought "That''s a cool game, but I want to make the player move differently and create my own mod", then all they would have to do is make another dll, say ''FasterPhysics.dll'' and make a new movement function thus:

function MovePlayerForwards(PlayerPosition: TPosition):  TPosition;
begin
  // move player 10 units forwards
  PlayerPosition := PlayerPosition + 10;

  // return the new player position
  Result := PlayerPosition;
end;
As long as they keep the function name, variables and return type exactly the same as the original function then this should work, yes? Obviously there would have to be a mechanism to load a custom dll for a mod, and people wishing to create mods would have to be able to see all the appropriate function names, variables and return types. Now if my thinking is correct from above, then my next question has to be that of "How do you create a mod using a Virtual Machine (VM) ?" Before anyone answers this I would like to first make sure that what I consider a VM is in fact a VM. To me a VM is a class that has public methods that are all derived from a certain type, and handled by a command interpreter, ie:

// declarations
type
  TCommandFunction = procedure(CommandLine: String);
  
  TCommandParser = class
  ...

  public
    procedure DispatchCommand(CommandLine: String);
    procedure Say(CommandLine: String);
    procedure Load(CommandLine: String);
  ...

// implementations
procedure TCommandParser.DispatchCommand(CommandLine: String);
var
  CommandName:  String;
  TempCommand:  TCommandFunction;
begin
  // copy first word from commandline
  CommandName := Copy( CommandLine,1,Pos('' '',CommandLine) );

  // remove first word from command line
  Delete( CommandLine,Pos('' '',CommandLine),Length(CommandLine) );

  // assign address of function with name = commandname to tempcommand variable
  // i realise this is a Delphi specific function, but i have no idea what the equivalent is in C
  @TempCommand := Self.MethodAddress( CommandName );

  // check if function exists
  if TempCommand <> nil then
    TempCommand( CommandLine );  // function exists, dispatch command with argument  
end;

procedure TCommandParser.Say(CommandLine: String);
begin
  // update editbox2
  EditBox2.Text := CommandLine;
end;

procedure TCommandParser.Load(CommandLine: String);
begin
  // load world from disk
  MyWorld.Load( CommandLine );
end;
Say a program has: EditBox1, EditBox2 and Button1 on a Form, and an instance of TCommandParser called (novelly) MyCommandParser. Now, a user types "say hello" into EditBox1 and clicks Button2, sending the the text "say hello" from EditBox1 to the ''DispatchCommand'' method of MyCommandParser. DispatchCommand then chops out the first part of its ''CommandLine'' string leaving us with "say" and "hello". DispatchCommand then checks to see whether a function exists within its class called "say" (which it does), it then calls the ''Say'' function with its CommandLine equal to "hello". The Say function recieves this and updates EditBox2 with the text "hello". My base for the above is from some code/ideas by Tom Nyudgens in this article. Now taking the above definition of a VM into account, the best I can think of how a mod is created in VM code would be to have some kind of encrypted text file that stores the commands and then they are somehow loaded from disk and used; I really am a bit lost with this, would anybody care to elabore on how [implementing a VM based mod] it would be done (providing, that is, my definition of a VM is indeed correct) ? Thanks for taking the time to read this. -- Cheers,
--
Cheers,
Darren Clark
quote: As long as they keep the function name, variables and return type exactly the same as the original function then this should work, yes?
Obviously there would have to be a mechanism to load a custom dll for a mod, and people wishing to create mods would have to be able to see all the appropriate function names, variables and return types.

Pretty much. All a DLL does is to allow you to wait until runtime to link functions together, instead of doing it in the original file. By requesting a function from a different file at run-time, this allows you to change the DLL that provides that function whenever you like. You don't need to write a DLL with a new name - typically you just overwrite the existing one. Or maybe some systems let you edit an INI file (or something similar) that lets you specify where to find the relevant DLLs.

It isn't just game mods that do this; hundreds of Windows programs have various DLLs that you upgrade from time to time without changing the original program. And Linux systems rely heavily on a similar mechanism for most applications.

quote: To me a VM is a class that has public methods that are all derived from a certain type, and handled by a command interpreter

No, you're confusing a concept with a sample implementation. Virtual machines have nothing to do with classes or public methods. These things are entirely to do with the programming language you choose to use, whereas a VM is something different. What you posted was just one way of implementing one basic type of virtual machine.

A virtual machine is so called because it simulates a 'real' machine, where the real machine is the computer processor. A virtual machine plays the role of the processor in reading commands and dispatching them, but also in storing/retrieving data, dealing with erroneous operations, handling control-flow structures, and so on. When you run a Java applet in your browser, that's a Java virtual machine running there that reads the applet and does whatever is required. Quake 3 also includes a virtual machine (which you can read about here: http://www.icculus.org/~phaethon/q3mc/q3vm_specs.html ). You'll find more info on what a VM does here: http://en.wikipedia.org/wiki/Virtual_machine.

Now, given that a virtual machine can be implemented in various different ways and can process whatever code it is designed to handle, how to create a mod for it totally depends on the game (or program) in question. Generally the process is somewhat similar to normal computer programming, where you write in a high-level language (such as Java, or QuakeC, to continue the examples above) which is often then compiled to byte-code, and which in turn is then executed by the virtual machine when necessary.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]


[edited by - Kylotan on January 7, 2004 8:19:52 PM]
Advertisement
Thanks for the reply Kylotan. I''m glad that at least one thing I thought of is correct, but I''m annoyed at myself for believing that a VM would be as easy to implement as a dll based mod, ah well never mind.

I had wanted to eventually implement modding via a VM after I read an article by John Carmack on how vunerable dll based mods were to cheating/malicious code, and I was confident that it would be easy (stupid me) after the success of coding my own scripting language from scratch, but I can see that I need to do a lot more research before I start on anything.


Thanks again for taking the time to reply.

--
Cheers,
--
Cheers,
Darren Clark

This topic is closed to new replies.

Advertisement