GTB is such a huge game that I seem to veer into certain areas of it for weeks at a time, then veer back into other bits of it and think “did I write all this code?”

One of the features from Gratuitous Space Battles that I was very happy with, was the online challenge system. It was very popular. About 226 trillion billion zillion challenge games have been played (roughly). Obviously I want a similar system incorporated into GTB, and naturally I want to fix the things that were not perfect, which I identify as:

  • The challenge browser was not as good as it could be. You couldn’t filter out played/downloaded challenges.
  • Any challenge that had content, be it DLC or a mod that you did not have, could crash the game, and not be pre-filtered
  • The emotional connection between you and the challenger was limited. (Rarely used messaging, and rating, but not leaving comments etc).

I plan to fix all of this, but the middle one is the current one of interest.

GSB had a binary .gsb format for a challenge, which basically packed in binary data for the fleets designs, deployments and orders, and a little bit of data about the challenge (custom settings etc) and that was it.

GTB will use a new .pak format I’ve written that will behave a lot like a zip file. (no compression yet, sadly). It will be a folder full of stuff for each battle, all the enemies unit designs, the deployment timings for their attacking units (or initial deployments of defending units), and all of the data from the scenario file, down to the location of every tree, crate, barrel, barbed wire etc…

That makes a GTB challenge file slightly larger than before, but I can live with that. They are under 100k. How many custom maps in games are under 100k now? It also means you could move a few trees or change the texture of a single tile, and upload an existing scenario trivially without any inconvenience.

Anyway…. The upshot of this new file format is that theoretically, if I write the code for it, the format could include custom sounds, graphics etc. That means you could do a mod for GTB which included different textures for the terrain, and custom units, issue it as a challenge, and EVERYONE could play it, because the required content gets downloaded with it.

Sadly, there is no way to prevent dupes there, so if you have a custom tank texture, and upload 10 challenges, someone downloading all 10 gets the texture 10 times, but I think that’s not so bad. Only a minority of players are likely to issue or play modded challenges anyway.

The main thing is, my pak file format pakker and unpakker all works fine, so it’s another step along the path to having online play working. Now I need to replicate a lot of the GSB functionality (and improve on it).

Edit: I swapped out my code to use some zip code instead , after finding a zip wrapper that was extremely lightweight.

16 Responses to “Starting on the challenge stuff…”

  1. Kemp says:

    Was there any reason for not just using zip files (with a .pak extension)? Other than the urge to reinvent everything yourself of course (not a jab at you, we all feel it even though we know it’s wrong).

  2. Cap'n Lee says:

    Is there any plan to add custom assets to your own menus once you have used them? sleep is death added every custom asset you came across online to your own asset picker, it allowed the best custom content to spread about everyone’s custom stories

  3. cliffski says:

    it was quicker to write what I needed myself, where I have all the source, than hunt through the web finding what megacorp insists on logos, NDAS, license payments yada yada for the right to use .zip.
    Plus I don’t need more than 0.001% iof the .zip functionality, and hate shipping a game bloated with 10MB of un-called DLLS because it’s all in some middleware :D

  4. Kemp says:

    Fair enough. Working with things like zip files in C (and derivatives) can be a horrible experience. The reason I ask is because I recently had to work with zip files in Python and it was actually easier than working with individual files.

    One thing though, when you say “(no compression yet, sadly)”, is that a plan? It might be when you’re trying to implement compression on your custom format that you suddenly realise that using a zip library would have been nice :)

  5. BOB says:

    Descent 1 and 2 missions are under 100K back then there was almost no internet. Also source code is now open source! This guy has been doing incredible work for what amounts to a lone guy by himself.

    http://www.descent2.de/

  6. BOB says:

    Duplicating data is not an issue with modern 2 Terabyte hard drives. Doing what is easy works. The great think about data-duplication is that the LEVEL itself remains a self-contained entity. So if someone screws up the config or textures only that persons level is effected.

    Look at what happened when we moved from DOS to windows and “DLL Hell” we all know of. Each program should have a copy of the dependency files they need so they remain self-contained and don’t depend on the system.

    “DLL Hell” happened because programmers stupidly moved away from self-contained programs. Your program should be able to run straight from the directory and not need any file from the operating system. That is good programming!

    There are days I pine for the DOS command line because of direct X version conflicts, after Microsoft made the Xbox 1 direct X started (again) to suffer from “DLL Hell”, the early versions of DX were awful, it wasn’t until Direct X 6 and 7 that things started to stabilize and then DX9 was great for a long time. Problem was over the years because Microsoft split DX10 to windows vista only and Windows 7 only. They had special versions of direct x 9 where they had special versions of direct3d and the like for different games. You had these separate special cab files listed by the month they were released… It is awful.

    Direct X as it stand today is a lot better in some ways but it still needs a lot of work where so version conflicts don’t happen.

    I’m all for DATA duplication if it means programs remain self-contained and don’t pollute your system.

  7. Xietanu says:

    With challenges at less than 100KB, I really don’t think you need to worry too much about duplication or compression with modern Internet connections and hard drives. Even at 56 Kb/s, that’s going to to take, what, 16 seconds to download?

    I’m glad to hear you’re going to be improving the browser, though. I’d really like to see that improved a lot, as it was the main thing preventing me playing more of GSB’s challenges. It was impossible to find quality challenges that were the sort of thing you wanted. Perhaps you could look at picking out a small selection of particularly good ones every week/fortnight/month/whatever and putting them somewhere prominent? I really like that aspect of SpaceChem, where they pick out particularly good user submitted challenges every so often for people to do. You can still do other custom challenges, but it gives a nice stream of quality challenges, and sorts them by difficulty and keeps things competitive as everyone is doing the same challenges. It’s massively extended the life of the game for me.

  8. Mike says:

    So the normal way of specifying a sound or a texture is the filename. But people most likely won’t be editing these map pak’s in Notepad, they’ll be using your editor, right?

    Is there any chance you could use something like the file size + an md5sum (or some other cheap hash with a huge symbol space) as a key pair for a file in your asset database, which will be placed in the pak maps automatically by your editor, rather than arbitrary filenames (and transmitting possibly several factors of waste in duplicate data).

    This all prefaced with: I have no idea how you’re planning on the “because the required content gets downloaded with it” thing. And I’m just talking about art assets, what about future expansions which have modules or tweaks to your units/turrets which need binary patches?

    What if somebody makes a mod which happens to contain all of your DLC content? Slippery slope :-( I am starting to envy your situation less..

  9. Mike says:

    BOB, I could not disagree more. The high availability systems I work on rely on my programs continuing to run, even if I have to temporarily pull out specific processing engine DLLs for debug, code fixes, and upgrading, all without harming my main program’s functioning and only causing temporary outages of specific services.

    On the other hand, you can get the same modular functionality with independent applications and pipes/sockets/shared memory regions instead of it all in one process. I don’t see the difference in technique really affecting the quality of the solution.

    I do hear your pain. Games have to integrate with nearly every functional component of your system, but static linking isn’t really good for anything but binary bloat and producing insecure applications, with even larger patching requirements.. Or am I not understanding your assertion of being able to integrate with graphics, sound, network, disk and user IO OS subsystems without any external dependencies (shared libs) — isn’t this only achievable through static linking?

    And yeah, things are wayyy better now.. (pic of my gaming rig with Steam and Windows 7.. you do NOT want to see my SxS folder)
    http://picturepush.com/public/6598660

  10. Flap says:

    “Only a minority of players are likely to issue or play modded challenges anyway.”
    This is a dangerous assessment Cliff…

    The reason why it wasn’t used that much with GSB, is that it was difficult to use online.
    But imagine that at only one person creates a mod with new textures, and that 20% of the user prefer them than yours. Then, especially if it is easy to use and never creates immediate issues to the player, that same data is very likely to be uploaded thousands of times on the server.

    To overcome that, it might be useful to create different packages : the map on one side, and the modded units/textures on the other. Then, these packets for modded things would have a name and a check sum to make sure that their are the same. (Well actually, the only really important things to check for the map are the parameters of the units. This could be directly read and compared)

  11. D. Moonfire says:

    RE duplicates. You could use a SHA256 or some other hash on the zip file to determine if the client already has it. That would help reduce the duplicates but maybe change how you are storing it.

    Are you considering multiple packs? So if someone has the “OMG Killer Pony Tanks” pack (skinning), could then use a different pack for the maps, etc? That could further reduce the duplicates if someone really, really loves MLP and uses it on twenty different scenarios. That would change the module to use a list of packs, but just an idea.

    I love the idea of downloading the requirements to play challenges.

  12. Which Zip wrapper was the winner btw?

  13. Lynx says:

    I’d suggest having a provision for ‘shared mods’ with versions. So you could say ‘this mod depends on that mod’, and then if 20 people use ‘Bob’s Awesome Hi-Res Texture Pack’ then they can just depend on v1 or v2 of that pack instead of including it with their mods. Just because current mods are 100k doesn’t mean future ones won’t, especially if they have the option of large amounts of data.

  14. BOB says:

    @Mike

    I mean with regards to levels. He was thinking about implementing a level system where textures aren’t stored with the level only referred to. Descent 1 and descent 2 use this system to some extent so levels are tiny since each person has a copy of the textures that came with the full game. You can put custom textures in Descent 1 + 2 levels if you want they have their own separate file just for that and that adds to download size… but that’s not the only thing.

    Having each level have it’s own texture/sound/item space is a godsend. Many older games have texture/object and some other limits built in. For instance in Descent 1+2 you can’t easily mod the game and add new models/sounds because of the way the game is coded, so you usually end up replacing/overwriting the bots/items that came with the game if you want to do any modification.

    What we’re really talking about here is good design and coding practices. When I referred to DLL HELL I was pointing out the fact that when DLL versions changed this usually caused massive havoc for many programs because they didn’t keep a local copy of the old version of the DLL that the program relied on for stable functionality. This is what I mean by having programs be self-contained.

    A new file format would allow for items/sound/graphics/special fx to be self-contained entities without having to over-write any built-in or hard-coded items/objects/textures limits from the main game. Thereby causing “mod hell”, where you go to mod the game and you have to go through all sorts of convoluted stuff to get your extra stuff to work in the game.

    Old games like Descent prove that ‘hard coding’ stuff (bad design) is not great for end users, especially when they want to mod/preserve/update your game years after your company is gone.

  15. DarthMasta says:

    IMO, you’ll be wasting an opportunity if you don’t include an automated online league, similar to the Google AI Challenge, but played using your game.

  16. Lore says:

    @BOB

    >Old games like Descent prove that ‘hard coding’ stuff (bad design) is not great for end users, especially when they want to mod/preserve/update your game years after your company is gone.

    Agreed in full, dude.