Perhaps you should make the code a 5 digit alphanumeric serial number (are 60466176 combos enough?) and have it shipped along with a number (00000000-60466176), and have the number and serial # privately hosted and then transact by seeing if the sent num and serial match, then randomize the shadowcoin serial again, and send it to the other wallet. 3DS shadowcoin data transferred to website and submitted, server checks shadowcoin credibility, randomize shadowcoin data, and sends it to receiver. If the serial # and # don't match 3 times, then blocked for a day.That's a pretty good idea! It's simple, yet, effective! Of course, for our own purposes, it'd be encrypted client-side with a secret key only known by the server, but who know? Maybe keys themselves will be in our compressed MVC format because of this. We'd need a special system for making sure they're valid though. Do you think you could help?
ShadowCoins
Yeah! ExactlyWell, first of all, you'd have a simple, generalized way of using some sort of currency between software.Do you mean to say, I could have an in-game currency, which is the same kind of currency that can be 'earned' and 'spent' in games that other people write?
3. NOOOOOOOOOO! We are not going to use this as a chance to get money! This is just a project, not a business. If we were, we'd probably donate to a charity of some sort, but we are NOT going to let you buy stuff with real money!!!Then what was that about using it "to benefit from advertising"?
You could use the ShadowCoins for your own website and use it to benefit from advertising.
I mean as in use the ShadowCoins to get advertising for your website via ShadowTech. In benefit, I mean getting more users.3. NOOOOOOOOOO! We are not going to use this as a chance to get money! This is just a project, not a business. If we were, we'd probably donate to a charity of some sort, but we are NOT going to let you buy stuff with real money!!!Then what was that about using it "to benefit from advertising"?You could use the ShadowCoins for your own website and use it to benefit from advertising.
Okay. Say I have a game. It has an in-game currency. I do not give the player the best weapon from the start, naturally. A sword costs 200 currency units in-game, a plasma sword costs 500 currency units and a laser gun costs 1000 currency units. I have carefully adjusted my gameplay so that the player 'earns' currency in-game fast enough so as not to be frustrated by the 'grind', but not so fast that there's no sense of accomplishment. It has taken much playtesting and time and effort to reach this balance. Now I am considering making this in-game currency, ShadowCoins. Given that tomorrow, someone may make a rock-paper-scissors game where winning gives you 10000 ShadowCoins, why would I want to choose that?Do you mean to say, I could have an in-game currency, which is the same kind of currency that can be 'earned' and 'spent' in games that other people write?Yeah! Exactly
Well, we wouldn't allow anything that simple to give you coins. If you wanted, you could use a special built-in API we'll use to track what Coins the user has earned, and only give the user that much in in-game currency.Okay. Say I have a game. It has an in-game currency. I do not give the player the best weapon from the start, naturally. A sword costs 200 currency units in-game, a plasma sword costs 500 currency units and a laser gun costs 1000 currency units. I have carefully adjusted my gameplay so that the player 'earns' currency in-game fast enough so as not to be frustrated by the 'grind', but not so fast that there's no sense of accomplishment. It has taken much playtesting and time and effort to reach this balance. Now I am considering making this in-game currency, ShadowCoins. Given that tomorrow, someone may make a rock-paper-scissors game where winning gives you 10000 ShadowCoins, why would I want to choose that?Do you mean to say, I could have an in-game currency, which is the same kind of currency that can be 'earned' and 'spent' in games that other people write?Yeah! Exactly
So, for every game that uses ShadowCoins, it must first be sent to you for playtesting so that you can determine what is an appropriate number of coins to be earned from each task, and what is an appropriate number of coins to price each item?Okay. Say I have a game. It has an in-game currency. I do not give the player the best weapon from the start, naturally. A sword costs 200 currency units in-game, a plasma sword costs 500 currency units and a laser gun costs 1000 currency units. I have carefully adjusted my gameplay so that the player 'earns' currency in-game fast enough so as not to be frustrated by the 'grind', but not so fast that there's no sense of accomplishment. It has taken much playtesting and time and effort to reach this balance. Now I am considering making this in-game currency, ShadowCoins. Given that tomorrow, someone may make a rock-paper-scissors game where winning gives you 10000 ShadowCoins, why would I want to choose that?Well, we wouldn't allow anything that simple to give you coins. If you wanted, you could use a special built-in API we'll use to track what Coins the user has earned, and only give the user that much in in-game currency.
No, you test it yourself with a stripped down version of the API that will use a server for development users. I have to allow the API access to the main server, and ta da!So, for every game that uses ShadowCoins, it must first be sent to you for playtesting so that you can determine what is an appropriate number of coins to be earned from each task, and what is an appropriate number of coins to price each item?Okay. Say I have a game. It has an in-game currency. I do not give the player the best weapon from the start, naturally. A sword costs 200 currency units in-game, a plasma sword costs 500 currency units and a laser gun costs 1000 currency units. I have carefully adjusted my gameplay so that the player 'earns' currency in-game fast enough so as not to be frustrated by the 'grind', but not so fast that there's no sense of accomplishment. It has taken much playtesting and time and effort to reach this balance. Now I am considering making this in-game currency, ShadowCoins. Given that tomorrow, someone may make a rock-paper-scissors game where winning gives you 10000 ShadowCoins, why would I want to choose that?Well, we wouldn't allow anything that simple to give you coins. If you wanted, you could use a special built-in API we'll use to track what Coins the user has earned, and only give the user that much in in-game currency.
Well, we wouldn't allow anything that simple to give you coins. If you wanted, you could use a special built-in API we'll use to track what Coins the user has earned, and only give the user that much in in-game currency.You can't micro-manage every program/game that uses your library, deciding how many coins it can or can't give players. Either they can all give however much they want, or none of them can. If none of them can, then it becomes the Play Coins situation - only the system can give coins (in Play Coins' case, by walking up to 1000 steps per day), and games can only consume them. Is that what you want to do? That wouldn't be a bad idea, but everything you've said so far is so vague and fuzzy that I won't believe you if you claim that's what you meant. If it IS what you meant, then you should have stared the OP with "Play Coins for SmileBASIC".
The library doesn't decide. The programmer does. The API just tells how many coins have been earned by the user in that specific programWell, we wouldn't allow anything that simple to give you coins. If you wanted, you could use a special built-in API we'll use to track what Coins the user has earned, and only give the user that much in in-game currency.You can't micro-manage every program/game that uses your library, deciding how many coins it can or can't give players. Either they can all give however much they want, or none of them can. If none of them can, then it becomes the Play Coins situation - only the system can give coins (in Play Coins' case, by walking up to 1000 steps per day), and games can only consume them. Is that what you want to do? That wouldn't be a bad idea, but everything you've said so far is so vague and fuzzy that I won't believe you if you claim that's what you meant. If it IS what you meant, then you should have stared the OP with "Play Coins for SmileBASIC".
That's right!So it'll be like a Google play game, or like pokemon rumble for the 3ds? You can play the game normally but it'll be better with the gems? Or is it close to that.If it is something similar to it, then I would support this.
You guys are still making no coherent sense. Could you please just give one COMPLETE example for how this would be used in a simple game? I don't mean you need to actually make the game, but you should be able to describe it completely, and how it would interact with the library you're proposing.
You guys are still making no coherent sense. Could you please just give one COMPLETE example for how this would be used in a simple game? I don't mean you need to actually make the game, but you should be able to describe it completely, and how it would interact with the library you're proposing.Okay, here's a simple example. Imagine you make a simple tic-tac-toe game. You want to allow the user to earn ShadowCoins if they win. So what you need to do is get the development version of the API that you can use for testing. You will get: - A development wallet, - A development login, and - A development ShadowCoin library. For giving the coins, you'd simply just use a function like GIVE$(APIKEY$,AMOUNT) and then the amount will be saved to the wallet. In order to make them valid, you'd go on the website and type in the code shown by the wallet. But what about taking? Well, you'd use TAKE$(APIKEY$,AMOUNT), and ShadowCoins will create a popup dialog itself that asks if they allow the purchase. To confirm it, they go to the website and type in the key displayed, and then type the code on the computer in. Then the purchase will be done. Where do the coins go? Into your wallet, of course! To track coins, you'd use TRACK APIKEY$ which will return the amount of coins you've given and taken from the user. You can use that to make sure that you keep the same amount of ingame currency that your software allows. After this, the program will have to be allowed by us. This should only take a day or 2. If your TAKE$ or GIVE$s are too outrageous, we'll respectfully decline. If you're accepted, you'll get a copy of the full API, and an API key. Then you can start doing REAL stuff with your software. The data for the wallet will be stored in one TXT file, which will contain the username, coins, and all the keys to be uploaded to the server. To upload coins, you'd go to your wallet and get the keys for the coins, and type them into the website. The server will verify them, and your coins will be uploaded. Downloading coins is similar, except you use the online wallet to get the codes and type them into the SB wallet. Is that coherent enough?
Imagine a Cookie Clicker type game. Someone's too lazy to keep clicking, so he can use ShadowCoins to buy the ingame currency instead of earning it himself. It's like a pay to win situation for people that either sleep in money or are too lazy to play the game.Is this serious, or are you attempting to mock this project?