Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Atreides

Pages: [1]
1
Programming / Updating Pixel Dungeon?
« on: August 12, 2016, 10:13:55 AM »
I have a few ideas about modifying (and perhaps altering the GUI to make it more extensible) but I can't get it to compile.  I'm not on my Android Studio machine, but I remember that it would produce errors that certain methods were not found, perhaps because newer editions of the Android libraries didn't support those methods.

How hard would it be to update Pixel Dungeon so it compiles on the most up-to-date versions of Android Studio?  Or should I use an older version of AS (and if so, where do I find it)?  Should I look at my phone to determine what version of AS I should or should not use for development, since I want to play my modifications of Pixel Dungeon?

2
Design / Re: Permanent consequences for failure that aren't death
« on: May 16, 2014, 11:11:04 PM »
At some point don't you have to wonder why reputation merits being linked to death, and consider calling it lives?  ;)
Depends on in-game fluff.  Maybe you're raiding a dungeon at the behest of a fey prince, and you're assigned one of his squires.  This squire hauls you out the first few times you die and he manages to bring most of your stuff, but the more you fail the less faith the squire has in you.  Eventually he stops believing you'll accomplish your task and he either won't bring any of your stuff (or he'll outright steal it and offer to sell it back to you), he won't take you very far from where you died, or he just won't come when you're near death anymore.

3
Design / Re: Permanent consequences for failure that aren't death
« on: May 03, 2014, 07:06:20 AM »
Felids lose a level upon reviving, so I guess they beat you to it, if I understand you correctly. Or we could say that great minds think alike!

Losing a level can be very icky depending on how it's implemented.  If the game keeps track of what you gain at a level up, or if what you gain is predetermined, then it isn't an issue and removing a level is as easy as adding one.  This is less true if removing a level means you suddenly can't hold all your gear and you need to spend 5 minutes reconfiguring your inventory, or if it means you need to, say, reorganize your passive abilities since you no longer have enough "ability points" to use them all (though I don't know of any games that have a system like this, outside of say Final Fantasy 9).

If your stat gains at level up are semi random, then level downs can benefit the player or hurt the player.  Say you gained 1 strength, 1 dexterity, and 1 wisdom on reaching level 22.  Then you are leveled down and you lose 1 wisdom.  That's a great deal!  Or you could have only gained 1 of something on level up and then lose 3 things on level down.

Even my negative experience idea can eat total shit depending on how experience is used in level gains.  If the game only tracks experienced needed to next level up (and then either pulls the experience needed for the level up after that from a table or follows some kind of algorithm to determine experience needed after you reach that level) then you can apply negative experience all day with zero consequences.

But if the game tracks total experience to determine when you level up, then you need to cap the amount of experience you can lose or else you'll lose a level and weird things could happen if that isn't what you intended to happen (and weird things will probably still happen).  Even then that creates something that can be abused, because it means you can take risks when your experience is very low without losing much experience.

I can only endorse negative experience when used with a system where your game tracks only experience needed to the next level up.

You could penalize the player even further by tracking total experience acquired and total negative experience acquired, and then do stuff with that even though it isn't used for level gains.  You could make certain quests time out once you reach a certain total experience and not have total experience take negative experience into account, punishing the player if he or she grinds too much or dies too often (an event ranking).  You could increase the difficulty of some encounters once certain milestones in total experience are reached (sort of an encounter ranking, or a battle ranking).

You - or your player's god - could reward the player with gold or random useful stuff if the player manages to reach certain events with a very low total experience and little or no negative experience.  I  prefer that the player not be rewarded with permanent stat boosts or otherwise-unobtainable abilities or items, because such things bring out the completionist in me and I like my social life!

4
Design / Re: Permanent consequences for failure that aren't death
« on: May 02, 2014, 10:14:15 PM »
Well, does anyone have any feedback on my thoughts?  I responded to OP's question.  Didn't feel like reading 13 pages of text.  Did I repeat what a lot of other people said?

I feel - probably unjustifiably - proud of the negative experience idea.

5
Design / Re: Permanent consequences for failure that aren't death
« on: May 02, 2014, 12:12:40 AM »
Lose all your stuff and start out at the beginning.

Azure Dreams is a roguelike for the PS1.  You have a  town where you can do dating sim and a bit of building sim stuff, along with minigames and shops.  The actual roguelike stuff happens in the monster tower just outside town.  Whenever you enter this tower you start out at level 1 with the exact same starting stats.  You can only bring 5 items into the tower with you.  You can also bring two familiars (basically pokemon) with you, who can fight alongside you or augment your attacks with their magic.  These familiars gain levels just like you, but they keep their levels and stats when they reenter the tower.

If you die in the tower you end up outside it with only the familiars that went in with you.  Everything else is gone.

It's possible to leave the tower at any time with one of several different items.  If you leave this way, you keep all your stuff.



While you probably should keep permadeath, there's no reason you can't have a few second chance items or abilities around.  These could punish the player by having the player awaken closer to the beginning of the dungeon, with less gold or missing a few random items, or several class/character levels lower (alternately, give the player negative experience, which must be worked off before you can gain a new level).

I don't think that the player should have unlimited retries, though that could be an option the player could select.  Instead I think that the retry feature should be linked to another game mechanic.  If your game has pets or familiars, then the familiar could have several chances to teleport you away, but at great cost to it and yourself.  There could be a cap on negative experience which will cause permadeath if it moves past that cap (if you die too many times).



What mechanic you choose depends on how your game works, and on how the roguelike stuff is done.  If it's in a repeatable, randomized dungeon (like in Azure Dreams), then you could punish the player as harshly as that game does, because the player can still start again with his familiars and the items he keeps in his safe at home.  If the whole game is a roguelike, then you need to do something a bit more subtle especially if you intend to keep permadeath.

Negative experience is probably the most devious thing you can do, because it temporarily locks down character/class progression and forces the player to be cautious for a while until he or she can start gaining levels again.  Losing gold is always good, especially if shops and consumable items are available (even more so if they are necessary or very useful).  Losing random items can be horrifying, so each item should have a value rating or there should be a way to derive a value rating.  This matters because powerful characters with lots of time invested in them should pay more for a second chance, while less powerful and time-invested character should be fairly cheap to save from permadeath.  This in itself is a mechanic that makes the game difficultly increase over time, as you gain more powerful and useful (or one of a kind) items.

One last idea I had just now - dangerous enemies could be produced where you died.  If you died on the 5th floor of a tower and your familiar drags you to the 3rd floor, then maybe the shadow of your death should be skulking around the 5th floor, waiting to embrace you.  So if you want to get past it, you need to grind a bit to defeat yourself as you were before because you're fighting yourself as you were when you died.

6
Programming / Re: Trying to compile Advanced Rogue 5.8
« on: May 01, 2014, 12:29:49 AM »
I added
#include <stdlib.h>
#include <string.h>
as appropriate per the compile-time error messages.  Down to 2 error messages, but it compiles and runs.

Now I'm going through command.c, commenting the controls for the game so I can reassign them to less-stupid keys.

Oh, one last thing - does anyone want the modified source code?  I could upload it to github, but bear in mind I'd need to learn how to use git!  I could compress it into a 7z or tar.gz and upload it here if anyone's interested.

EDIT

Took me a while to figure out how to escape single-quotes with grep.  Should have tried the obvious, a backslash.  Saving this for later perusal.

Code: [Select]
[2]person@computer ~/Games/arogue5.8.2-src $ grep \'h\' *.c *.h -n
command.c:132:     case 'h': case 'j': case 'k': case 'l':
command.c:148: case 'h': case 'j': case 'k': case 'l':
command.c:169: case 'h': case 'j': case 'k': case 'l':
command.c:184: when 'h' : do_move(0, -1);  // move 1 left was h
command.c:192: when 'H' : do_run('h'); // move
mdport.c:1066:                case   't': ch = 'h'; break;
mdport.c:1090:            case KEY_LEFT   : ch = 'h'; break;
mdport.c:1103:            case KEY_B1     : ch = 'h'; break;
move.c:33:    { 'h', '\0', 'l' },
move.c:833: case 'h':
rogue.c:421:    'h', " left",
rogue.c:574: 10, TRUE, TRUE, 'h', "8-10",
rogue.c:1014: 15, TRUE, TRUE, 'h', "5-7",
rogue.c:1266: 100, TRUE, FALSE, 'h', "16",
util.c:422:     case 'h': case'H': delta.y =  0; delta.x = -1;
util.c:504:    if (runch == 'h' || runch == 'l') horiz = TRUE;
util.c:653:     case 'h':

7
Programming / Trying to compile Advanced Rogue 5.8
« on: April 30, 2014, 06:20:17 AM »
Source code from here:
http://rogue.rogueforge.net/advanced-rogue-5-8/

SVN page:
http://rogue.rogueforge.net/trac/browser/arogue5.8/trunk

Attempted compilation:
Code: [Select]
person@computer ~/Games/arogue5.8.2-src $ make
gcc -g   -c -o chase.o chase.c
gcc -g   -c -o command.o command.c
command.c: In function ‘command’:
command.c:251:4: warning: incompatible implicit declaration of built-in function ‘exit’ [enabled by default]
    exit(0);
    ^
command.c: In function ‘quit’:
command.c:454:2: warning: incompatible implicit declaration of built-in function ‘exit’ [enabled by default]
  exit(0);
  ^
command.c: In function ‘call’:
command.c:925:6: warning: incompatible implicit declaration of built-in function ‘free’ [enabled by default]
      free(guess[obj->o_which]);
      ^
command.c:926:2: warning: incompatible implicit declaration of built-in function ‘strcpy’ [enabled by default]
  strcpy(prbuf, elsewise);
  ^
command.c:930:6: warning: incompatible implicit declaration of built-in function ‘strncpy’ [enabled by default]
      strncpy(obj->o_mark, prbuf, MARKLEN-1);
      ^
command.c:934:47: warning: incompatible implicit declaration of built-in function ‘strlen’ [enabled by default]
      guess[obj->o_which] = new((unsigned int) strlen(prbuf) + 1);
                                               ^
command.c:935:6: warning: incompatible implicit declaration of built-in function ‘strcpy’ [enabled by default]
      strcpy(guess[obj->o_which], prbuf);
      ^
gcc -g   -c -o daemon.o daemon.c
gcc -g   -c -o daemons.o daemons.c
gcc -g   -c -o encumb.o encumb.c
gcc -g   -c -o fight.o fight.c
gcc -g   -c -o init.o init.c
init.c: In function ‘init_names’:
init.c:244:28: warning: incompatible implicit declaration of built-in function ‘strlen’ [enabled by default]
  s_names[i] = (char *) new(strlen(prbuf)+1);
                            ^
init.c:247:2: warning: incompatible implicit declaration of built-in function ‘strcpy’ [enabled by default]
  strcpy(s_names[i], prbuf);
  ^
init.c: In function ‘init_player’:
init.c:302:6: warning: incompatible implicit declaration of built-in function ‘strcpy’ [enabled by default]
      strcpy(pstats.s_dmg,"3d4");
      ^
init.c:353:6: warning: incompatible implicit declaration of built-in function ‘strcpy’ [enabled by default]
      strcpy(pstats.s_dmg,"1d4");
      ^
gcc -g   -c -o io.o io.c
io.c: In function ‘endmsg’:
io.c:68:5: warning: incompatible implicit declaration of built-in function ‘strcpy’ [enabled by default]
     strcpy(huh, msgbuf);
     ^
io.c: In function ‘doadd’:
io.c:90:14: warning: incompatible implicit declaration of built-in function ‘strlen’ [enabled by default]
     newpos = strlen(msgbuf);
              ^
io.c: In function ‘status’:
io.c:235:15: warning: incompatible implicit declaration of built-in function ‘strlen’ [enabled by default]
     pb = &buf[strlen(buf)];
               ^
gcc -g   -c -o list.o list.c
gcc -g   -c -o main.o main.c
main.c: In function ‘main’:
main.c:58:5: warning: incompatible implicit declaration of built-in function ‘strncpy’ [enabled by default]
     strncpy(home,md_gethomedir(),LINELEN);
     ^
main.c:61:5: warning: incompatible implicit declaration of built-in function ‘strcpy’ [enabled by default]
     strcpy(file_name, home);
     ^
main.c:62:5: warning: incompatible implicit declaration of built-in function ‘strcat’ [enabled by default]
     strcat(file_name, "arogue58.sav");
     ^
main.c:76:43: warning: incompatible implicit declaration of built-in function ‘strlen’ [enabled by default]
         strucpy(whoami, md_getusername(), strlen(md_getusername()));
                                           ^
main.c:90:2: warning: incompatible implicit declaration of built-in function ‘exit’ [enabled by default]
  exit(0);
  ^
main.c:144:6: warning: incompatible implicit declaration of built-in function ‘exit’ [enabled by default]
      exit(1);
      ^
main.c: In function ‘fatal’:
main.c:236:5: warning: incompatible implicit declaration of built-in function ‘exit’ [enabled by default]
     exit(0);
     ^
gcc -g   -c -o maze.o maze.c
gcc -g   -c -o mdport.o mdport.c
mdport.c:59:26: fatal error: ncurses/term.h: No such file or directory
 #include <ncurses/term.h>
                          ^
compilation terminated.
make: *** [mdport.o] Error 1
[2]person@computer ~/Games/arogue5.8.2-src $

I'll look up these error messages in my free time.  Documenting here in case anyone is interested.

EDIT

It compiles if I change mdport.c
line 59 : #include <ncurses/term.h>
to
line 59 : #include <term.h>

This part goes over the character limit, so I moved it to pastebin.

Compilation:
http://pastebin.com/pibXnZN2

8
Player's Plaza / Re: Looking for a roguelike to play with
« on: April 29, 2014, 05:14:11 AM »
Having the data in the code is kind of the textbook definition of not being able to quickly and easily modify.
It is if I'm not sure how to create new data files, or how and where my modifications to the data are stored, or how to add new things to the data (like a durability byte that has a chance to decrease when the item is used, eventually causing the item to break when it reaches 0 durability).

Besides that, I'm used to reverse engineering console video games.  Editing data tables in compiled executables is easy for me, if that data table is always x bytes per entry and y entries total.  I use spreadsheets and a python script to write changes to files.

tl;dr

Due to my admittedly niche background, I'm comfortable mixing my data with my code.  When I'm bored I locate data tables in my compiled executables and screw around with them to see what happens.

EDIT

I feel like Doctor Evil upon rereading that last sentence.  I hereby disclose that meat helmets were not a substantial part of my childhood, but I have shorn my testicles on occasion.

9
Player's Plaza / Re: Looking for a roguelike to play with
« on: April 29, 2014, 02:10:33 AM »
Can't edit my old message, here's my edited reply:

http://pastebin.com/TQYTua83

10
Off-topic (Locked) / Having trouble with the anti-spam measure
« on: April 29, 2014, 02:08:56 AM »
It keeps timing out.  I click save to save my edit and it keeps going forever.  Does this apply to all users?  Do I need to get past a certain post number?  Is there some way I can be promoted past this so I don't have to deal with this junk?

11
Player's Plaza / Re: Looking for a roguelike to play with
« on: April 29, 2014, 01:58:31 AM »
Not a programmer.  Will be reading and doing exercises from a book on C this summer, then starting university this fall.  I like roguelikes, but I dislike how all roguelikes quickly become way to complex to quickly and easily modify.

I know how to use terminal commands (cd, ls, make, grep if I have a guide handy), I know how to read and follow instructions, I run Linux (granted it's Mint Debian), I've screwed around with other roguelikes in the past.  I have a good idea of how to use grep to puzzle through code, but the codebases of most roguelikes are way too huge to easily make something fun.

I want code mixed with data because I'm easily confused when I have to edit stuff in JSONs and in the *.c and *.h files too.  I'd rather keep it on one place.

I initially tried a bunch of very old games, but I couldn't get them to compile.  I'm happy with something very old as long as it compiles, is small, isn't too buggy, source if available, and it runs on linux.  Ideally I want something that is CLI, written in C or C++, and keeps the data and code together.

EDIT

How long until the captcha is no longer mandatory?

12
Player's Plaza / Looking for a roguelike to play with
« on: April 28, 2014, 05:12:45 AM »
I want a roguelike that:
* Is small - by which I mean it doesn't have a lot of source files,
* Is stable,
* Is open source, and
* Runs on linux.
* BONUS: Code is well-documented/commented and is easily maintainable.
* BONUS: I prefer CLI roguelikes (Command Line Interface, for the uninitiated.  Also known as ASCII graphics.)
* BONUS: Everything is editable via the source code only.  No JSONs, not *.dat files.
* BONUS: Ideally C or C++.

I want something that is easily modifiable, with minimal effort or knowledge.  I'm okay with either the traditional dungeon-crawl roguelikes or modern free-roaming open world ones.

Pages: [1]