MMORPG style Inventory - Stock Torque3D 3.10.1

[Zweshi]

Hello everyone,

Isn't it high time that Torque3D had a easy to use, easy to maintain, and easy to expand upon inventory system? I think so too! And in that spirit here is a MMORPG style server to client inventory resource written in TorqueScript for stock Torque3D 3.10.1... probably works on any version of Torque but 3.10.1 is where it's been tested.

Video showing off inventory functionality:

llPf0IQMmDw

Current Version: 1.0.0a

Download: https://www.dropbox.com/s/p4x4e8qvwf9e4q5/MMO_Inventory.zip?dl=0

Installation: Instructions are found in the downloaded folder's base directory

License: Code: MIT | Art/Sound files: CC0

General Notes:

• Networked with a "never trust the client" mindset

• Standardized images/bitmap arrays

• Standardized data variables for all the things

• Standardized "helper" functionality

• Using a flat database system

• Using object namespaces to reduce redundancies

• Written in just TorqueScript

• No .gui files, the gui elements are built to a targeted gui(standard is set to PlayGui)

• Data driven gui approach with full customization

• Plenty of example objects

 

System Features:

• Base inventory

• Inventory Menu

• Currency panel

• Notify panel

• Examine panel

• Sound suite

• Select object behavior

 

Network Optimizations:

• Full inventory data is only sent when player opens their inventory for the first time

• Split/drop/Move/pickup functions only send data for the affected slots

• client verifies data before a request is made reducing redundant server calls

• server is only called if/when actions are taken not for redundant tasks such as open/close states

 

Inventory Item Types:

• Currency

• Stackable items

• Non-stackable items

• Equipable items

• Food items

 

Inventory Item Functions(Menu System):

• Split stack

• Pickup item

• Move item

• Examine item

• Drop item

 

A Word On Adding Content:

One thing I've learnt over the years is that efficiency on the data layer is useless if it means the content layer suffers(learnt that the hard way), so with that in mind content additions are handles exclusively within a scope that a artist without code/scripting skills can master. A item addition requires a shape(.dae) used for world placement, a 2D inventory image(.png) of the item, and a datablock akin to a simple non-interactive spreadsheet.

That is it, you do not need to even touch the codebase of the inventory system to fully interact with the content layer.

A Word On System Customization:

One of my biggest pet peeves is when developers build cool systems as external resources(for any engine or data system) that are very specifically engineered to do one thing very well but if you want to modify them at all you might as well re-engineer the worlds power grid first as that would probably be simpler.

With that in mind i wrote this resource to be adaptable through the dankest of data driven approaches, for example: Want the inventory on the left side instead? No problem just change $InvBase_PnlPos and your done, more inventory slots and rows? Just change $Inv_Rows, $Inv_NumBtns and $Inv_InventoryMaxSize and your good to go.

It's easy to change things and it should be easy.

A Word On Data Management:

You will notice that this resource uses a flat database as opposed to a more sophisticated separate database system for data handling. As i started this project i contemplated writing a database system to go with it and get some inter-server goodness going right of the bat for that sweet sweet efficiency. But limited time along with the fact that i was not gonna use the system myself made me lean towards a simpler solution, after all if you need a sophisticated database for your game then you probably already have a preference for a existing system.

A Word On Client Login:

This inventory system does not sport a client login system, instead it simply uses the client player name to connect the player to the server side inventory, this is what we in the industry call a complete lack of security bordering the absurd. This is by design though as i wanted to avoid writing a login system as at that point this resource would land in the security sphere which i'm not really comfortable with for a public resource like this. So keep this in mind for your multiplayer projects, you need to connect your login system to the inventory where appropriate.

Feedback:

If you decide to use this system for your project(s) and find some gaping flaw that i, in my infinite wisdom of course, overlooked completely i would very much appreciate if you would report back so i can break out the ol' shovel and get back in the trench to fix it.

Lastly if you have any questions feel free to reach out to me either in this thread, on discord, or twitter and i will do my best to help you out.

Twitter: Zweshi

Discord: Zweshi#0840

All the best and happy inventorying!

- Jonas

Edited December 9, 2018 by Zweshi

[Zweshi]

< Reserved >

[TRON]

Very well done. Thanks for sharing and nice demo video to go along with it.

[Duion]

Thats really nice, since it is exactly what I needed. Some time ago I also started making an inventory system after a tutorial, but I gave up somewhere in the process.

Now to the criticism:

The install is a bit annoying having to manually edit files and then the binds do not work, since the keys are already used, so they have to be fixed manually as well. The easiest solution for people who want to try it out, would be just to distribute a pre modified version, that you just have to drag and drop or even a full install, that you can just launch, since a full Torque install is also the same size download as the inventory system.

The other point is the size, I wondered what uses 130 MB in the package and then noticed it has art, plus source files, which is nice, but 1024x1024 texture for such tiny objects is a "bit" over the top, 128x128 would fit as well without noticeable visual difference. I know those are just example items probably, but then you made the things overly complicated for yourself, you could just have used plain materials, or no materials at all and just vertex paint the models, would save greatly on resources. Polycount is also far too high for some objects.

I did my art like that in the past as well, everything with texture, proper node setup in blender, but now I know, that you can get away in many cases with just making a simple low poly model, giving it a color and export to .dae file and distribute nothing else with it and it will work just fine with hardly a noticeable difference in appearance. That way you could make that 130MB download into 1MB download or so while greatly increasing performance ingame and saving time on your workflow.

Yes this has nothing to do with the inventory system, it is just a workflow and performance optimization, for users and yourself, I like to be perfectionistic.

Another question, do you plan on making items use multiple grid fields instead of just one each? When I tried to make an inventory system, I wanted larger items to take up more spaces, like it is done in many RPG games, but I found it to be very hard to build so I gave up on it.

[XIXWYRMEXIX]

Thank you for providing this resource, especially considering you did not even make it for yourself. I will try it out on my current project. I was looking/thinking about an inventory system in the future but since it is here I will just use this! Thanks a lot! Will try to provide feedback after I use it.

[Zweshi]

@TRON Thank you, happy to share it!

@Duion Thank you, Happy to hear you were on the hunt for something like this!

The install is a bit annoying having to manually edit files and then the binds do not work, since the keys are already used, so they have to be fixed manually as well. The easiest solution for people who want to try it out, would be just to distribute a pre modified version, that you just have to drag and drop or even a full install, that you can just launch, since a full Torque install is also the same size download as the inventory system.

 

Install is a tricky beast to get situated, the reasoning behind having to add exec lines is to not overwrite the standard init files as that becomes a liability for compatibility down the line if they are ever changed either with a new Torque release or by the end user. The keys i hear you on, i decided to use the keys i find to be the most logical for the operations rather then what was unbound by default, i do think i made the right call but i can see it being argued both ways.

 

The other point is the size, I wondered what uses 130 MB in the package and then noticed it has art, plus source files, which is nice, but 1024x1024 texture for such tiny objects is a "bit" over the top, 128x128 would fit as well without noticeable visual difference. I know those are just example items probably, but then you made the things overly complicated for yourself, you could just have used plain materials, or no materials at all and just vertex paint the models, would save greatly on resources. Polycount is also far too high for some objects.

I did my art like that in the past as well, everything with texture, proper node setup in blender, but now I know, that you can get away in many cases with just making a simple low poly model, giving it a color and export to .dae file and distribute nothing else with it and it will work just fine with hardly a noticeable difference in appearance. That way you could make that 130MB download into 1MB download or so while greatly increasing performance ingame and saving time on your workflow.

Yes this has nothing to do with the inventory system, it is just a workflow and performance optimization, for users and yourself, I like to be perfectionistic.

 

I definitely understand your point of view but i do think there is value to over engineer 3D assets in the context of a resource. A bit of extra quality provides a more impressive visual to a window shopper and clarity in node setups/rendering setups/source files provides example opportunities for the end user to emulate. Since at the end of the day the items are of a example nature it isn't all too important that they would function well and be space efficient in a full production environment.

 

Another question, do you plan on making items use multiple grid fields instead of just one each? When I tried to make an inventory system, I wanted larger items to take up more spaces, like it is done in many RPG games, but I found it to be very hard to build so I gave up on it.

 

I have gone back and forth a lot over the years on which style i like the most out of these two types of inventory and they both have significant merits to them, but for this resource my intention is to stick with the style of "one item, one slot".

Thank you for the feedback Duion, always happy to hear it!

@XIXWYRMEXIX You're very welcome, Happy to hear i could save you some inventory dev time! :D

[LoLJester]

Great resource and video. Thanks for sharing.

[Duion]

I definitely understand your point of view but i do think there is value to over engineer 3D assets in the context of a resource. A bit of extra quality provides a more impressive visual to a window shopper and clarity in node setups/rendering setups/source files provides example opportunities for the end user to emulate. Since at the end of the day the items are of a example nature it isn't all too important that they would function well and be space efficient in a full production environment.

Yes, it is nice to have them higher quality, but doing models and textures like that shows that the art engineer does not know what he is doing, you could get away with 10% of the resources used and still achieve similar or higher quality, since for example no normal maps or specular maps were used, not to talk about new PBR rendering methods. You cannot have such a small items have thousands of polygons, no LOD levels and a huge 1024x1024 texture, of which most is empty space, since in the final game there max exist hundreds or thousands of those items on screen at once plus the game world, plus player models etc which will destroy performance.

It may not be relevant for an example, but this is not something an end user should emulate or use in a final product.

[JeffR]

@Zweshi Most excellent work, sir!

If you were interested in turning this into a module for future use in the new BaseGame template, I'd be willing to help with that and I think that would go a long way to dealing with things like Duion's complaint about installation complexity.

[Bloodknight]

I'm going to be awkward and ask for a licence, I'm assuming at least MIT for parity based on your comments about taking and breaking.

I was looking at an inventory system very much like this for converting the AFX demo into a more rounded RPG demo (which I will pester jeff about later on regarding making it fit into the new modular basegame) The server sided determination is the icing on the cake which I'm pretty sure was going to provide me with headaches, but you've done that :D

As for asset detailing, generally I find its easier to convert better quality/higher fidelity assets to something else than the other way round, much art texturing comes with far bigger textures than needed which allows the designer the freedom to adjust somewhat.

[Zweshi]

@ Zweshi Most excellent work, sir!

If you were interested in turning this into a module for future use in the new BaseGame template, I'd be willing to help with that and I think that would go a long way to dealing with things like Duion's complaint about installation complexity.

 

Thank you very much! Sure i'd be up for that, just let me know what is needed from my side

 

I'm going to be awkward and ask for a licence, I'm assuming at least MIT for parity based on your comments about taking and breaking.

 

Not awkward at all, software without a license is some bone chilling stuff :D

You are correct that the package is meant to have a MIT license(will add this explicitly as soon as time allows, not sure how i missed it in the first place), the exception being the art/sound files which are CC0(these CC0 files have LICENSE.txt files in the directory structure pointing them out).

 

I was looking at an inventory system very much like this for converting the AFX demo into a more rounded RPG demo (which I will pester jeff about later on regarding making it fit into the new modular basegame) The server sided determination is the icing on the cake which I'm pretty sure was going to provide me with headaches, but you've done that

 

Sounds like a fun project, best of luck! Let me know if the inventory system gives you any trouble and i will see what i can do to help.

 

As for asset detailing, generally I find its easier to convert better quality/higher fidelity assets to something else than the other way round, much art texturing comes with far bigger textures than needed which allows the designer the freedom to adjust somewhat.

 

This tends to be my opinion as well, having worked with a lot of stock 3D modelling i have found that having more quality at the expense of performance is rarely a bad thing given that the ability to down scale is as accessible as it is.

 

Great resource and video. Thanks for sharing.

 

Thank you, happy to share!

[Duion]

I would suggest not to add a license to it, since every time someone adds his MIT license, it has to be kept at the header forever and somewhere in the future each code file will consist of 90% license header and 10% code.

The default practice with Torque3D so far was, that each time someone contributes to the main repository, the code becomes the Garagegames MIT license, which is not so nice, but feasible.

So I would suggest to keep it that way or to have something similar for addons, so the license header does not get bloated and then create some kind of credits file or menu, where each contributor is credited, if he wants to, even the CC0 ones. Thats how I keep it with my game as well, it helps me keep track of everything.

[Bloodknight]

well, some discussion is interesting, afaik you can add a licence without literally adding it to every code file. Many projects on github for example only contain a license.txt file.

[Duion]

MIT license header has to be inside every code file, as the license states:

"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

You could try to redefine what a "substantial portion" is, but your chances are not that good, since one code file is definitively a portion of the software.

[Bloodknight]

Short of this becoming a legal discussion for which nobody here is qualified, i'd argue that the two sentences are different and that if it was supposed to be inside every code file, that's precisely what it would say, also I've seen many projects with just a licence file, and more than a few in the past with a licence file and a short form reference to the licence file. Short of a lawyer popping on to explain in detail precisely what 'substantial portion' actually means to a lawyer... I suspect we are stuck simply discussing.

[globojim]

Hi, new here and need a bit of help with this as I'm exactly trying it on stock 3.10.1.

I can only pickup the coins, everything else says 'I can't carry that'.

[globojim]

With my latest follow-up tests, picking up the coin and I would assume all items only works on the server/host side.

Edited September 27, 2023 by globojim

[Duion]

Its quite common for resources like in the Garagegames resources section in the past or addons you buy or instructions that they usually work only in singleplayer or are not fully thought through and not ready for a final game, I spend weeks and months fixing them until they were fully working for my game, sooner or later you need to learn how to code stuff yourself, they are more or less examples.

[Duion]

Look into how items are handled in the stock template, there are always lines in scipt that send a command to server that the item has been picked up etc and you need to network everything like that, its also wise to handle those things on server side by default to prevent cheating etc. Look how into the scripts folder they are divided in to client and server scripts and important stuff has to be done on server side, client side is only for stuff thats not relevant to the game mechanics like user interface, controls, graphics settings etc.

[globojim]

Ok thanks for the tip. From the resource details, it clear states:

Quote

And in that spirit here is a MMORPG style server to client inventory resource

so was expecting this to be multiplayer by default and not single or server only feature.

anyways will just try and reach out @Zweshi for some help and guidance.

[Kent Butler]

Are you still having trouble with this?

I'm fiddling with it in a single player context and it seems to be working pretty well. Does the resource have issues when playing across a network?

[globojim]

 

On 10/15/2023 at 1:25 PM, Kent Butler said:

Does the resource have issues when playing across a network?

got busy for a bit so have not looked into yet nor contacted the author but yes

still no go as this is supposed to work on multiplayer as posted.