Messages

1

Programming / Re: Making a Mac Roguelike

« on: March 29, 2011, 07:03:04 PM »

Thanks for the encouragement!  I needed it since it will be a lot of work (my plan is for more than just a typical text roguelike, it's half roguelike/half cRPG )

I've got a good start, I hope, the app core is done (about box, menus, etc), Sound/Music engine, complete Help system, with play logs and Hall of Fame, etc.  I've got my "color replacer" system working, so I can design a base "sprite" and all the color variants are "free". [Supports up to 8 distinct wildcard colors in the base sprite].  I'm working on the menu screens now, and the app/game states.  Next up is the command processor/queue and the character data/dialogs.   I also have a base design for a "secure permadeath save game system" using custom encrypting [what can I say, I designed my own cryptographically-secure PRNG just for fun. ;P ]

( I also thought of  a few neat ideas, like mobs/NPCs share the same base/class as a character, so in new games, you can even play as new races you've encountered/collected from previous games, etc. )

Here's the main welcome screen: 

sites.google.com/site/mizukirpg/news/ithasbegun/Miz000001.png




( BTW, If you have any comments on good/must-have features for a roguelike, I'd like to hear them.  I know there is no definitive list of roguelike features, but it's a big genre and I'm a casual RL fan.  )

2

Programming / Re: Methods against Save Scumming

« on: March 29, 2011, 06:48:46 PM »

I still don't see how it makes permadeath more meaningful but I realize now it's not a worthless exercise.

It's the only thing that makes permadeath meaningful in the first place

Permadeath isn't a thing if it's not permanent

Yes but making cheating harder doesn't affect that at all. For the people who don't cheat permadeath is just as meaningful as it was before and for people who do cheat it will also be just as meaningful (i.e. not at all).

Well, the presumption is that there is actually a third group you're not considering.  Those who would have cheated, but now cannot.  Considering my roguelike will be on the Mac only, in general this group will be bigger than you may think.  First, the stereotype is that Mac users in general are less sophisticated when it comes to technical details of the OS.  Secondly, many of the players will never have even heard of roguelikes, so there will be less accomplished save scummers and many more "casual game players".

However, I believe that there is such a group in the Windows and Linux crowds too.

The experiment for me then, is to implement some "low hanging fruit" that will help this group play permadeath as it is intended, as permanent death. 


As for the "online" part I had always thought that if I had the resources/inclination for a server, that I would simply implement a remote-key system:

1) Split the "Secure save" into at least two files:
     a) the essential character file ( Payload_0 )
     b) the rest of the save state (vendors, dungeons, etc)

When saving a permadeath game for the first time, the client sends up Payload_0 in plaintext* to the server. The server then sends down Payload_0 in encrypted form* [using a "master key" generated at random on the server] along with a subkey for Payload_1 -- client then creates Payload_1 file(s) in encrypted form on disk using the key from the server.  (Payload_0 from the server is saved as-is on disk by the client).   [* network traffic could be obscured/weak-crypted if desired ]

When loading a permadeath game, client sends up encrypted Payload_0 from disk to server, which then decrypts and "increments" the keys associated with this save game [for next use].  Payload_0 and the previous subkey are sent to the client for decrypting/loading.    On next save/load the newer keys are used (which is stored on the server only)

So saving a game, and they making a backup will only be valid until that save game (or it's copy) is loaded.  Once loaded, the backup files will no longer be decryptable by the client.

Of course, Payload_0 has to be pretty small to keep ISP costs down for this system to be realistic, and as someone mentioned it means if you're offline you can't load/save your "hardcore" character.  However, if your server also tracks "non-secure games" you could offer an option to "move a hardcore character offline" which would move that save game into the "non-secure" bracket, etc.



In-memory hacking (which I wasn't really worried about with the OP) is "easily solved" by storing critical values using a simple custom obscuring algorithm.  Players can feel free to search for "0x0012" for gold, but they won't find "0x34FF" which is the actual value stored in var.  I'd also combine that with limits on stats via the mechanics.  You can also do some clever things with CRCs so that simply "replace CRC checking to NOP" won't work.   But I'm not so concerned at that point.  If someone is navigating memory and altering code execution, they aren't in the target group for me.  The main goal/proposal was just about reverting to backups to cheat death.


Great ideas, pretty good discussion!  =)

 ((  In retrospect, I probably should have mentioned, I'd also make non-trivial effort to make death in those situations interesting, carrots to the sticks, as it were.  Because I think that is one major reason for save scumming is that there is too much investiment vs no reward for not cheating.  So consider that along with the "counter measures" there would also be incentives. Perhaps that aspect would make a better thread.  ;P ))

3

Programming / Re: Methods against Save Scumming

« on: March 25, 2011, 04:57:44 PM »

It's rec.games.roguelike.development. For centuries it has been the forum for roguelike developers.

Ah!  Thank you!  I know about the newsgroup, I just didn't associate the initialism to it.

You're combatting a problem that doesn't exist.

edit - particularly if you're adding savescum functionality as a feature of the game. Why prevent people from doing something indirectly that you've already allowed them to do directly? It makes no sense.

I have to disagree.  I'm sorry you don't understand what I'm attempting to do, all I can say is it's the same thing as to why people put locks on school lockers, or why roguelikes will bother to delete the savegame after loading it in.  I'm simply attempting to go a bit further (but not drastically so).  The savescum functionality you refer to that I mentioned is not a conflict.  As I alluded to, that functionality is only available for non-permadeath situations, and I only mentioned it specifically to show I'm not trying to take away work-flows for some people.  I'm only attempting to see if some ideas can help make permadeath more meaningful and make cheating harder.  I don't think I need to explain why a "traditional rpg" difficulty setting should/is different in substance to a roguelike/permadeath setting.  It's not my intention to resurrect philosophical discussions on permadeath/etc that are already on rgrd, as has been explicitly pointed out by others.



That being said, thanks for the input!  =)    Between the suggestions here and a search in rgrd, I think I have plenty of ideas to consider. 

4

Programming / Re: Methods against Save Scumming

« on: March 24, 2011, 07:10:29 PM »

While I do really appreciate the feedback re: "Don't do it", my intention for my post was to solicit ideas for preventive measures.  I'm fully aware of the impossibility of making anything impregnable, but that doesn't mean a little effort can't help diminish the problem in a significant way.   My intention is not to slave away on some obscure quasi-DRM-like functionality, but I also believe that if I can spend a day or two to make permadeath more meaningful and worthwhile when it is chosen, I would like to try doing so.

While it is possible for people who want to cheat to go to drastic measures, my RL will already provide them a simple convenient method for save scumming (e.g. "Revert to Save Game" ) as a simple keyboard/menu command [for non-permadeath settings]while you are playing.  So I'm not attempting to remove choice/playstyle from those who are accustomed to it -- I'm just trying to experiment with something different.  { And ultimately, these are just plans at the moment, nothing's been implemented yet. }

[ The claim that hidden files or the mere existence of registry keys are criteria for a trojan/malware is simply hyperbole in my book.  But I understand the position, and anything I do end up implementing won't be drastic, and would only apply for permadeath games. ]

Lastly, I don't know what rgrd is, so I still hope people will be still be interested in sharing ideas for preventing save scumming.   The "database" suggestion is an interesting angle, and gave me some good ideas.

5

Programming / Methods against Save Scumming

« on: March 23, 2011, 10:51:31 PM »

In my RL I would like to provide varying difficulty settings.  The combination of most of these settings will form a "score modifier". When you die/retire/win your base score will be multiplied by the modifier for a "final score"

One of these options will be under what conditions you can save.  The hardest will be only while quitting [while still alive] which also brings with it the concept that the save game is "deleted" when loaded ( aka Permadeath ).

However, since I've played other RLs with most of them permadeath by default/only-option, I am familiar with the temptation to "Cheat".  Considering my game will provide options to not have to deal with permadeath, when you are actually playing a game "with permadeath set ON" I would prefer for it to be as hard as possible to do save scumming.  (After all, YOU ASKED FOR IT IN THE FIRST PLACE )

I have a few ideas, but I was hoping people would share their ideas on ways to make save scumming as difficult/painful to do as possible. As I don't have a lot of resources, methods that rely heavily on storing data across a network connection aren't ideal for me.  Mostly i assume there will have to be a combination of tricks to hide "key files" required to decrypt the save file. 

Any other ideas/tips?

6

Programming / Re: Making a Mac Roguelike

« on: March 17, 2011, 08:20:59 PM »

Thanks for all the feedback so far (it was more than I expected

Some responses:

1) The one I mentioned here was a specific idea, out of many potential projects.  I can still do this idea, then later do a cross-platform RL.  For this idea, making it xplat does have many upsides, but the notable downsides for it were the following:  a) I couldn't really use Objective-C/Cocoa in a way meaningful enough to learn it as deeply as I'd like.  b) This idea includes playing around with the interface, seeing if I can use UI improvements to improve the gameplay.  I generally don't like the xplat UI/misc frameworks because they generally look clunky on all platforms.  I'd use SDL out of all of them, but I've never used it, while I'll be learning it'd be slow.  I'll also be slowed down further with having to test/support many more platforms.  c) There are plenty of RLs developed on Windows and ported. I feel that while mac users aren't as numerous, they are further under-represented because many don't know about DOS Box or RLs.  Maybe if there were more Mac native RLs the mac users figures being reported for other RLs wouldn't be so dismal.  d) A RL in Cocoa will be much easier to port to iPhone/iPad, if it turns out to be any good.

On the other hand, if the game is any good, it is possible it would be played by only 7 people, ;P   But on the other other hand, if the game is terrible, no one will notice. ;P    And I'll still have learned more about Objective-C/Cocoa.

2) "Sound? How would you use sound in Roguelike magic?"  --  I'm thinking of not having "classes" per se, but rather allow you to collect your own set of skills.  Magic would then have to be something you'd have to learn, and develop (more than just learning, investing somehow).  Therefore, I'm leaning towards "skill based magic".   The ideas I'm thinking about is to categorize Magic into Modes and Methods, such that learning one will make you less effective (and eventually unable) to use others.  There are three Modes: "Wild", "Eldrich" and "Resonant" ( respectively: elemental "control", self energy/chi use, and Catalystic use of powers/blessing from other beings to you).   There are three Methods: Runes/Cards/Etc, Music, and Enchanting.  For the first method, you are constrained to casting spells based on loot you acquire, but learning spells is as easy as experimenting, and "mana cost" will be low.  Usually a Rune/Card will survive the strain of the cast, and you can continue using it, other times it might break/etc.  These kinds of spells do not rank (except maybe char level or somesuch).   You can only cast one at a time, but durations can be short/long depending on the formula used.  The third method, is heavy on one-time component use (but some of the components you'll get from breaking down unwanted items), but allows for creating magic items that can be used simultaneously.  E.g. You can create/wear 20 rings (but (all?) enchanted items carry a sanity cost...), and therefore create spells with long long durations.   Still need to balance it, but likely it will reduce the rate of profit you could make vs other builds.  Also probably it will have the most skills to invest in, to get the most out of the method.  And when you get better, you'll mostly just boost the success rate of creation. [the components/host-item decide the power rating].  The second method, requires you to lug around an instrument, work on a play skill, and generally have only short term spells, but there will be some with moderate durations, and also a "as long as you are playing" spells that beat the durations of Runes/Cards.  You'd also have to acquire song sheets and learn them.  As you get better, the spells effects get stronger.   [[ To add spice/flavor.   Runes/Cards can be presented with different scripts/styles, Enchanting could bring with it lots of different kinds of materials/receipes, and Sound could possibly allow for different music files being played.   Under the hood, the systems could actually be implemented with generic code/mechanics with only small snippets to differentiate a card object with a material object, etc.    The Modes will also add an additional layer of complexity with (hopefully) not vast effort on the coding side, with their own flavors and pros/cons.     As I can't implement the vast amount of features of many roguelikes, like NetHack, I'll be investing in fewer areas, but hopefully with multiple layers of complexity to (hopefully) bring something new to the table. ]]

3) I'm not exactly a fanboy.  ;P   I've got like 4 functional Windows 7/Vista gaming machines, and only one functional Mac laptop.  I generally enjoy the Mac better, but both have things that infuriate me. 

4) Although I proposed a lot of ideas, I'm hoping to scope the project to 1-3 years of work.  There will be a lot I'll probably leave out, from the quirky-evolutionary stuff (dipping potions etc), to "AI systems and Fractal landscape generation" etc.   I might not even implement stuff like lighting and player-made traps in the 1.0    My "epic roguelike" will likely not come to fruitition until my 5th attempt! ;P

5) I'm also hoping to sometime collaborate on a project, since I'm a newbie, by doing "that Mac Roguelike", I'm hoping people might have a better chance not seeing me as just another stranger who implemented yet another roguelike.  ;P   


Any other comments are welcome!
Thanks!

7

Programming / Making a Mac Roguelike

« on: March 17, 2011, 12:23:32 AM »

Hi All!,

I have decided to not do a different roguelike project, but am still very much wanting to do a roguelike, or at least an RPG that is primarily influenced ( >50% ) by roguelikes.  So I recently mulled over my options.

One of my ideas was to do a "Mac Roguelike", which would double as a way to learn Objective-C and Cocoa ( I'm a traditional C/C++ Windows and Mac OS X programmer by trade ).   I was thinking of something along the lines of ADOM, Elona, etc ( rpg-like roguelikes if you will ), tile-based, no "level cap",  a "classless" class system, non-traditional magic (Sound, Cards, etc ), a complex loot system, and  character-building "overland activities" (like building up your own estate).  [ Though I haven't finished brainstorming and pairing-down actual features to implement. ]

I realize that there aren't many Mac-based rogue-devs around, but I figured it wouldn't hurt to float a balloon or two and see what pops up!  ;P


Comments?

8

Traditional Roguelikes (Turn Based) / Elona: Original Developer Noa officially ceasing development, releasing source

« on: March 04, 2011, 09:47:21 PM »

Elona, a Japanese roguelike (available in English) has been around for years, but the original creator has decided to move on.  He has, however, released the source code ( via a time-limited link in an announcement on the J side of the Elona forums) without any licensing restrictions.

On the English forums, there is a thread currently gauging interest in people continuing development of Elona.  If you are interesting in on working on one of the more quirky roguelikes around, and know a programming language ( especially HSP or C/Java/etc ) you might want to check out the English forums!

If you want to take a peak at the source (it's in a basic-like language called HSP ) take a look at the topmost forum sticky on the J side of the forums ( you can also use google translate to help fumble through if you don't know Japanese. )