• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
polyfrag

How to best allow for modding in a multiplayer RTS

5 posts in this topic

(Disclaimer:  I have no experience with CS or Spring mods)

 

What do you mean by "synchronized"?  If you're talking about distribution, the server either needs to require clients to have a given mod, or it needs to upload the given mods to the client when they join.

 

To operate on modded units explicitly, you need some kind of lookup system, typically string lookup, e.g.  doStuffIfExists(getUnitByName("MISC_EXT_TANK_1"));

 

More realistically, your engine would probably have some kind of index lookup so the mod only needs to do the string lookup once.

0

Share this post


Link to post
Share on other sites

All the client's files must be synchronized. Can you imagine what would happen if a client modified one of the scripts? He might gain an advantage or break the game for himself. All the files that are loaded would have to be tracked and a hash generated to compare to the server. If the file doesn't exist, it can be downloaded from the server. If the hash doesn't match, the client can choose to overwrite his versions in favour of the server's.

 

And what if the game's rules are moddable by script? And there are different map types, eg. CTF, biz, war. If the game rules are changed too much they might not be compatible with certain map types.

Edited by polyfrag
0

Share this post


Link to post
Share on other sites
And how best to handle the scripting/mod detection aspect.

How do you distinguish a mod? Is it an archive file in the /mods/ folder with an autoexec script? Would you then have a mod selector on startup load up that script which sets everything up, calling other scripts? The mod loader/selector functionality would have to be built into the engine then and require a restart to reload all the assets. Or this can be done with resource tracking, not requiring a restart to change mods. But that means mods can't share models or images or sounds or utility scripts. Maybe they can reference other archives or files? If there's a model or a script that's named the same in the same folder in two adjacent archives or in the same folder, there would be a conflict, and the server and clients would have to make sure the archive (or lack of it) they come from matches. Also it can be difficult for newer versions of content appearing, if you had a newer version of a map or utility script but the server had an older version, you'd have to revert to the server's version to join. Also one version of the utility script might be compatible with a certain map but updating or reverting to a server's version of the utility script might make it incompatible with another of your maps, which you might only discover when you try to host a game.

The main use for scripts in maps would be scenarios though. And there's not much you can do if the tutorial is meant to demonstrate a unit or building or rule that doesn't exist in the mod or is different.
0

Share this post


Link to post
Share on other sites

A game that properly supports mods is going to have some kind of "entry point" for the mod in question -- usually something like a definition file of some sort.  It could just be a text file in the mods folder (e.g. modname_mod.txt) that lists components and dependencies.  Yes, your engine has to be aware of it, and has to know how to load them.  Modding in games that don't actively support it typically involves editing data files or DLL injection.

 

This can all be done lazily.  When the user clicks "select mods", for example, the mod loader can scan the mods directory for entry points.  When the user selects an entry point, the mod can then load the requisite dlls ('plugins'), mods, or resources.  If the user adds a mod, quits to the main menu, and then clicks "select mods" again, the engine could theoretically reload the mods again.  Realistically though, most engines I've seen load mods at startup (or have the selector in a pre-game splash screen a la mount and blade or some paradox games), and it's nice to be able to do that for things like "mod manager" mods.  It's worth noting that you can however do all of this dynamically, and it shouldn't be performance-impacting if you do so at the right place and time.

 

As for sharing resources, that should be fine.  Just require a certain model in the models folder, or a certain sound in the sounds folder.  Mods should ask the game engine to load resources the game engine can load.  If multiple mods need the resource, you can just use a reference counting solution or something to track cleanup.

 

Version incompatibilities are a thing, but that's just like game version incompatibilities.  Either the server needs to require a specific version of the mod, or it needs to automatically give that version to clients.  As for your synchronization questions, that all depends on the operation.  If the client modifies the UI to be purple or something, who cares?  Anything the client can do in an RTS that affects other players should be sent to other players.  If the client says "I have a tank here with 10,000,000 damage", the server can say "I know what your tank is, and I know you've given it two upgrades and it has 30 damage".  That kind of validation isn't a modding issue, it's a fundamental anti-cheat issue that the core game needs anyway.

2

Share this post


Link to post
Share on other sites

This can all be done lazily. When the user clicks "select mods", for example, the mod loader can scan the mods directory for entry points. When the user selects an entry point, the mod can then load the requisite dlls ('plugins'), mods, or resources. If the user adds a mod, quits to the main menu, and then clicks "select mods" again, the engine could theoretically reload the mods again. Realistically though, most engines I've seen load mods at startup (or have the selector in a pre-game splash screen a la mount and blade or some paradox games), and it's nice to be able to do that for things like "mod manager" mods. It's worth noting that you can however do all of this dynamically, and it shouldn't be performance-impacting if you do so at the right place and time.

I like how Counter-Strike does it. It still remains Counter-Strike with the same menu background and options, but a map can be zombie infection mod or gungame, without requiring a restart. It doesn't even have any official label for mods in the server list, people just write it in the server name.

 

 

 


Version incompatibilities are a thing, but that's just like game version incompatibilities. Either the server needs to require a specific version of the mod, or it needs to automatically give that version to clients. As for your synchronization questions, that all depends on the operation. If the client modifies the UI to be purple or something, who cares? Anything the client can do in an RTS that affects other players should be sent to other players. If the client says "I have a tank here with 10,000,000 damage", the server can say "I know what your tank is, and I know you've given it two upgrades and it has 30 damage". That kind of validation isn't a modding issue, it's a fundamental anti-cheat issue that the core game needs anyway.

I couldn't connect to a CS mod server once because I had to delete some model file or something. That's how I want it to work.

 

If GUI's are defined in scripts, they're inseparable from the important code. GUI scripts might be made to define new dialogs and things. This is important in my case. Not sure how far I want to go with scripting. Might be too slow to write game mechanics in it.

Edited by polyfrag
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0