These might serve your purposes.
In my day job we have a huge system that integrates with excel using it as a macro language.
Authorised users can upload spreadsheets which are populated with program entered values into certain cells then the results of the formulas read back.
This allows people who only "know some excel" to program it.
On the downside no caching of formula results or reading of xml could do this as it actually uses excel as a language interpreter.
This is the heavyweight end of the "I want to use excel in my app" scale...
c++ and Excel?
I once worked in a project in which engineering data was stored and manipulated in "live" Excel sheets for the same reason as in braindigitalis' example - the mechanical engineers and physicists that used the program were not so good at programming, but could handle the spreadsheets just fine :)
Author
Thank you guys very much!
I guess ill try and stick with CSV so far and see where ill land.
The reason behind my thought of using Excel was that i saw an interview with a game programmer that used Excel spreadsheets to calculate drop chance values and such.
I just need something easy to look at and change.
A file that can hold a list of items with stats that will automatically change the characters stats when equipped.
Do you guys have any idea what bigger game companies normally use when they program similar code?
Or do you guys often prefer to use. csv when storing variables and values?
Thank you guys very much!
I guess ill try and stick with CSV so far and see where ill land.
The reason behind my thought of using Excel was that i saw an interview with a game programmer that used Excel spreadsheets to calculate drop chance values and such.
I just need something easy to look at and change.A file that can hold a list of items with stats that will automatically change the characters stats when equipped.
Do you guys have any idea what bigger game companies normally use when they program similar code?
Or do you guys often prefer to use. csv when storing variables and values?
Sounds like the developer didn't want to bother with getting proper tooling in place for their game. Most of the time there is a dedicated tool that builds the game data. This is done for several reasons. One its harder to hack so your data files are a little more secure. Blizzard spent some time doing this exact thing so that their Diablo games had less cheaters.
I still have a hard time thinking that a developer would release a game that uses an excel base spread sheet for their data system. This would make their game more exploitable for cheaters to hack their game to get better loot.
The flip sided here depending on what language your programming in most .Net languages have the ability to connect to an Excel Spread sheet like you would a database. This is typically done using the OleDbConnection class and setting the connection string to access your Excel spread sheet. I still feel the CVS or another way would be better, but at least this could be done while you work on other tools to manage your loot management tools.
Sounds like the developer didn't want to bother with getting proper tooling in place for their game. Most of the time there is a dedicated tool that builds the game data.
It's perfectly normal for a smaller developer studio (or indie) to use an existing spreadsheet program for data. They're well known, mature, and should be mostly bug free. And the developer can take an exported CSV or whatever and turn it into whatever data format they want for the game.
And I wouldn't worry about hackers unless multiplayer, and if it's multiplayer, then it shouldn't be a spreadsheet, it should be a database, like some form of sql or whatever, and not even on the players' machines.
It's perfectly normal for a smaller developer studio (or indie) to use an existing spreadsheet program for data. They're well known, mature, and should be mostly bug free. And the developer can take an exported CSV or whatever and turn it into whatever data format they want for the game.
And I wouldn't worry about hackers unless multiplayer, and if it's multiplayer, then it shouldn't be a spreadsheet, it should be a database, like some form of sql or whatever, and not even on the players' machines.
This is an interesting point to think about. I just see a lot of Excelbases these days which causes me to cringe when I have to consume their data for use in my programs.
Honestly though my current game project I have been working on uses an Excel spreed sheet to track all my game entities so I have to agree this is a common practice. But I painfully move them over to my world builder code, just been to lazy to automate this process. For me though as a gamer if the final data file is a CSV file then it will be easy to exploit. Granted if someone wants to play a single player game and cheat to win then the only person their hurting is themselves which is a good point to think about when developing data files.
Anyways thanks for the food of though it is a very interesting point of view!
If the game data would be in xlsx, it would be very easy to exploit as well :)
Unless you actively encrypt the data, it is easy for a novice hacker to modify all the client side data, no matter what format it is in. Even heavy encryption won't help against more advanced guys - you need to have the decryption key in memory at some point in time so as to access the data yourself.
One way to protect data from tampering is to sign the configuration data by using the PKCS7 signature pattern (and you can add encryption alongside that). This way, unless the hacker modifies the client program itself, you can verify that the data hasn't been modified since it left your hands. Of course, if the hacker knows his/her stuff, he/she can disable the verification logic on the client.
If the game data would be in xlsx, it would be very easy to exploit as well
Unless you actively encrypt the data, it is easy for a novice hacker to modify all the client side data, no matter what format it is in. Even heavy encryption won't help against more advanced guys - you need to have the decryption key in memory at some point in time so as to access the data yourself.
One way to protect data from tampering is to sign the configuration data by using the PKCS7 signature pattern (and you can add encryption alongside that). This way, unless the hacker modifies the client program itself, you can verify that the data hasn't been modified since it left your hands. Of course, if the hacker knows his/her stuff, he/she can disable the verification logic on the client.
If this data is on the client machine, it's compromised from jumpstreet. Assuming you have multiplayer, this should live on your server.
If it's single-player, don't waste your time on any kind of encryption. Make the format as simple as possible, so that Joe Shmoe can fool around with it in Notepad. Modding is going to give you far more potential through the long tail than you might possibly gain on the front-end locking your player from doing save-editing/cheating and what-not.
The user has bought the software. They own the bits on their machine and can do with them what they will on their machine. They're going to anyway, whether you try to stop them or not.
\rant
I would agree that CSV is a better idea than trying to use Excel directly. If you're planning on doing any kind of scripting system, it might make sense to just define the loot data in the scripting language. I've seen this done pretty well in a handful of games using python or Lua, with lists of tuples.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement