I don't think you need to use any kind of standard wording for this. If you aren't using someone's art in your final game, you have no contractual obligation to include them in the credits, so I don't see why there would be any particular way that you "should" do it. The fact that you're doing it is awesome, and, as Redshrike said, I think people will appreciate it. :)
Is this kind of what you were thinking of, or is it too simplistic?
Since digital currency doesn't really "sound" like anything, I tried to make it sound computer-y, but I could go for something a bit less chip-sounding if you prefer.
And done. Note that it will only count downloads since the counter was added (and since before the original was removed) because there wasn't any way to count them in the meantime.
Tap seems to be following the "full immersion" school of thought, which realistically will teach you to program faster if you have the patience to tackle the big learning curve. However, I'm going to play devil's advocate for a moment and say that an engine that does a lot for you might be the absolute best way to start out.
This is because with an engine like that, you can get right into making games. Since it already does a lot for you, most of the common functions will be taken care of, and you can produce a working game possibly without writing a single line of code.
You won't be totally satisfied with a game produced this way, though, because you'll invariably run into the limitations of what the canned functionality can do for you. The way around this is to dip your toes into scripting (which is the opposite approach from what Tap was talking about) and write a few lines of code here and there to start out with. Most likely, other people will have run into the same limitations that you have, so there will probably be web tutorials around that can give you some pointers on what to do.
I'm honestly not sure which of these approaches is the better one. I'm 35, so when I first started to try to make games as a kid back in the 1980s, there just weren't any game creation kits around, so I pretty much had to try and write them myself. I was never able to write anything more complicated than a simple text adventure until the early 90s.
I'm a reasonably good programmer now, and I learned how to do it the way Tap is talking about -- by jumping right in and doing it the old-fashioned way. But doing it that way will involve a lot of false starts, and you need to be prepared for the fact that it'll take you quite a while to make anything more than the most basic stuff.
I don't think you need to use any kind of standard wording for this. If you aren't using someone's art in your final game, you have no contractual obligation to include them in the credits, so I don't see why there would be any particular way that you "should" do it. The fact that you're doing it is awesome, and, as Redshrike said, I think people will appreciate it. :)
QR Code, for the lazy.
OHRRPGCE wiki link, for the lazy. :)
Very nice! :)
Nice work. :)
These planets would be easier to find if they were grouped together in a single submission. Would you mind doing that?
Is this kind of what you were thinking of, or is it too simplistic?
Since digital currency doesn't really "sound" like anything, I tried to make it sound computer-y, but I could go for something a bit less chip-sounding if you prefer.
This sounds like an interesting request, so I'll see what I can do.
And done. Note that it will only count downloads since the counter was added (and since before the original was removed) because there wasn't any way to count them in the meantime.
Tap seems to be following the "full immersion" school of thought, which realistically will teach you to program faster if you have the patience to tackle the big learning curve. However, I'm going to play devil's advocate for a moment and say that an engine that does a lot for you might be the absolute best way to start out.
This is because with an engine like that, you can get right into making games. Since it already does a lot for you, most of the common functions will be taken care of, and you can produce a working game possibly without writing a single line of code.
You won't be totally satisfied with a game produced this way, though, because you'll invariably run into the limitations of what the canned functionality can do for you. The way around this is to dip your toes into scripting (which is the opposite approach from what Tap was talking about) and write a few lines of code here and there to start out with. Most likely, other people will have run into the same limitations that you have, so there will probably be web tutorials around that can give you some pointers on what to do.
I'm honestly not sure which of these approaches is the better one. I'm 35, so when I first started to try to make games as a kid back in the 1980s, there just weren't any game creation kits around, so I pretty much had to try and write them myself. I was never able to write anything more complicated than a simple text adventure until the early 90s.
I'm a reasonably good programmer now, and I learned how to do it the way Tap is talking about -- by jumping right in and doing it the old-fashioned way. But doing it that way will involve a lot of false starts, and you need to be prepared for the fact that it'll take you quite a while to make anything more than the most basic stuff.
Very colorful and epic. Nice work. :)
Pages