Messages

1

Design / Can Roguelikes offered a different battle system?

« on: November 28, 2018, 03:14:22 PM »

What Roguelike that comes to mind to me, was one introduced to me by my ex room mate. It was a game called Sanctuary. The map design was using letter based murals, rather than simple letters and numbers.

But it at least seems like it doesn't have to have that major difference to count as a separate system.

Even if something were turn-based (I'm considering basing the grid on some other kind of turn like system) my mind doesn't really perceive it as turn based if turns were not actively being counted.

The turn based only really becomes obvious, when I use simple murals for battle systems.

I'm having to rethink how I approach everything, as I'm thinking I might focus on puzzle solving and investigation, rather than action in my next few sets of variations on the Nihilist theme.

2

Design / Re: Corridors considered harmful

« on: November 28, 2018, 03:08:19 PM »

I've been thinking about that actually, would a roguelike even work inside the context of a spaceship?

Historically I'd make a spaceship be represented by letter P, and an enemy spaceship called E.

But increasingly, I'm considering having the Spaceship be the dungeon itself. But that in itself would largely change how one would go about doing procedural generation. Something like, the spaceship design reminds constant, but the surrounded space is procedurally generated. The spaceship itself would be something like a "home" state.

3

Programming / Re: Issues With Some online references,

« on: November 28, 2018, 03:04:27 PM »

Nope, are you from the planet Robot?

4

Programming / Issues With Some online references,

« on: November 27, 2018, 06:52:16 AM »

Have you ever noticed how just casually asking for certain solutions to programming problem, Stack.Overflow would be completely outright mislreading at times?

Ways to clear the terminal is one example: You don't need to leverage Ruby to do that task, you can just do a system call to clear the screen.

They also don't teach you: How do you make sure statistical values remain constant across different programs?

You do this by reading from a file that has that statistical value, then converting that file type into a direct integer. Then simply write that change you want to make to that stat to that file.

I've tried asking basic questions there, and my topic would be closed for almost no explanation.

For those just learning Ruby:

You can do type the simple command to clear the terminal.

Code: [Select]

system("clear')

I also use it for when I want to refer to an outside program. It doesn't all have to be require "ostatus.rb" (as an example) that I've tended to get more errors with.

You can also do procedural generation by cloning your game file, (Think small game chunks of 7 * 7 grid or 9 * 9 grid.) SImple call these rooms, and then create a gamestate program that shuffles a deck between these different rooms.

Then have one game chunk be your home.rb.

It seems like there is a lot of stuff Stack overflow just isn't going to teach you. Especially if they just close threads willy nilly.

5

Early Dev / Re: Nihilist -- Experimental

« on: November 19, 2018, 04:34:52 AM »

Thanks, will check out a different solution later on.

I'm finding myself hating the Rubygems documents lately. So I'm having to figure out a bunch on my own.

I keep forgetting my copy is on my other computer. I might add Terminal Shooter to it.

Edit: This puts it into this weird hybrid of Puzzle Game/Terminal Shooter game.

6

Early Dev / Nihilist -- Experimental

« on: November 12, 2018, 08:00:46 AM »

This is a test game I created in a couple of days. I still plan on refining it, though I'm still extremely new to learning how to do procedural generation.

Title: Nihilist
Genre: Puzzle SF

Concept: An experimental puzzle terminal game without corridors, and a slightly different battle system. This one also focuses more on puzzle solving, although there are random battles after each unlocked door.

Issues: Each hidden room with locked door had a random chance of encountering another locked door, so the puzzle difficulty could have more difficult if I had not had a boss battle after each unlocked door.

Github link: https://github.com/LWFlouisa/Nihilist/tree/master/Nihilist

Update: Modified battle system. A quirk of the gamestate machine is based on the dice you can get a lot of battles.

7

Design / Re: Corridors considered harmful

« on: November 12, 2018, 07:46:54 AM »

I see; semi-random generation through randomly selected predetermined chunks. That's an interesting concept indeed, as long as there is plenty of chunks available so that dungeons never feel samey.

Just finished it in a couple of days. It's not going to be perfect. This one is called Nihilist.^ ^

8

Design / Re: Corridors considered harmful

« on: November 11, 2018, 11:59:00 PM »

No procedural content generation => not a roguelike.

Not necessarily, it depends on how it's done. There is a wide area between having something have static dungeons, and having something be "truly random". By definition, truly random ends up looking like a mess.

What you want in something in between. You have a limited number of dungeon designs, but the game shuffles between these different designs. You might have only three designs, or you might have over 2,000 designs.

The way I figured it out is to create mini-levels, and have a state machine shuffle randomly between different levels. There seems be a lack of tutorials on it, is how to specifically do procedural randomness. Most of the few out there is either behind a paywall, or it's in some other language besides Ruby.

On the other hand, badly written random can look like this.

Code: [Select]

*  *  *  *  #  *  *  *  #  *  #  * 
 *  *  *  *  *  #  *  #  *  *  *  * 
 *  *  #  *  #  *  *  *  *  #  *  * 
 *  *  *  *  *  #  *  *  #  *  *  # 
 *  *  #  *  #  *  *  #  *  *  *  # 
 *  *  #  #  *  *  #  *  *  *  #  * 
 #  *  *  *  *  *  *  *  #  *  *  * 
 *  *  #  *  *  #  *  #  *  *  #  * 
 *  *  *  #  *  *  #  *  *  *  #  * 
 *  *  #  #  *  *  *  *  *  *  #  * 
 *  #  *  *  #  *  *  *  #  #  *  * 
 *  *  #  #  *  *  *  *  #  *  #  * 
 *  *  #  *  #  *  *  *  #  *  *  * 
 *  *  #  *  *  *  *  *  *  *  *  # 
 *  #  *  *  #  *  *  #  *  *  *  # 
 *  *  #  #  *  *  #  *  *  *  *  # 
 *  *  *  #  *  *  *  *  *  *  *  * 
 #  *  *  *  *  #  #  *  *  #  *  *

Not the kind of level I really get anything out of playing. And it creates more work for the programmer for people that is just beginning to code.

9

Design / Re: Corridors considered harmful

« on: November 11, 2018, 12:27:56 PM »

I don't design maps based on "generation." Or rather, I didn't use to.

That make no sense. Please explain.

As in I hard code it, there isn't anything random about it. It was more important when I was using booleans instead of variables.

10

Programming / Re: Question on nesting [Ruby]

« on: November 11, 2018, 09:37:55 AM »

Cool, well it does seem to work as intended.

Made a simple game of navigate, and be followed by pet.

The main change is variables instead of booleans to determine navigation routes.

The error codes in Ruby legitimately needs to be rewritten to be more understandable. As it makes figuring out exactly what my error is impossible at times. I don't get many errors anymore, so there really isn't a very good reason for software not to point to a specific issue on a specific line.

11

Design / Re: Corridors considered harmful

« on: November 11, 2018, 06:30:42 AM »

Seems like a non issue to me, I don't design maps based on "generation." Or rather, I didn't use to.

12

Programming / Question on nesting [Ruby]

« on: November 10, 2018, 10:09:32 PM »

Is nesting your source code generally considered bad practice? When looking at the source of other games, it seems like nesting is more common than I realized.

I often use classes and sub classes, rather than nesting, as that tends to flow most similarly to the original language I'm used to for Renpy. When I was designing Terminal Shooter, I was deliberately avoiding nesting if I could. After a point, is nesting unavoidable?

Right now, i'm wanting to do more of a Hacklike with espionage/stealth elements. But struggling with logistics at the moment.

13

Programming / How do I get user_input for phone?

« on: April 01, 2017, 03:08:15 AM »

I looked all over startpage, and it seems like nobody wants to give a clear or straight answer about how to get user-input for smartphone.

How do you get user-input for smartphone in Ruby if gets.chomp doesn't work?

It seems like all the search results point to laptop keyboard input.

14

7DRLs / Terminal Shooter [Semi-Success] [7DRL]

« on: March 20, 2017, 06:04:19 AM »

https://github.com/LWFlouisa/TerminalShooter

You play as a stand alone spaceship wandering space, fighting enemy spaceships. Simple enough. Random difficulty: Even, Advantage, Ambushed, Last Stand. The object is to repair your spaceship at a speed that out paces the ability for he enemy to attack you.

You can theoretically win Last Stand, but it takes a long time and careful ship repair timing.

New Screen Shot:

15

Design / Re: Variable Encounter Rate?

« on: March 11, 2017, 09:18:57 AM »

I hate to be that guy but my eyes just bled a little reading your code. What's wrong with:

Code: [Select]

if $steps_taken == $steps_per_battle
    b = Battle.new
    b.fight_menu
  end

Instead of $alarm_mode? This way you don't have to hardcode magic numbers or have duplicate code in your if-else. It's also a lot easier to extend, you don't have to add another "else" whenever you think of something new.

Of course you can still have $alarm_mode if you need that for other stuff, just set $alarm_mode and $steps_per_battle together when the alarm is activated or deactivated. Finally it's not really a "mode" if it's only on and off (true or false), might as well call it $alarm_active or just $alarm instead.

Because I didn't specifically assign $steps_per_battle. It's for tracking the steps you take outside of battle, Steps per battle would convey the amount of steps taken during a battle. Which is useful if you wanted to do a tactical battle system, but I'm not tracking how many steps are taken during battle.

In other words, it would convey something I'm not going for.

If I wrote $alarm and $steps_taken on the same line it wouldn't work as intended. It just would not. $steps_taken is a sub if/else of alarm mode, because I want a different encounter rate if MC is not proxied.

In other words, alarm is important to notify whether a MCs identity is compromised.

I mean I get you want accurate variable naming. But if I'm going to call it $steps_per_battle, why not go even more specific? $steps_taken_in_battle for in battle navigation and $steps_taken_outside_battle.

That would completely make it have more clarity.