Messages

1

Design / Re: Variable Encounter Rate?

« on: March 13, 2017, 08:33:49 AM »

Roguelike set to artificial world sounds interesting as you aren't bound by laws of physics (as if fireballs would obey them in the first place, but you get the idea).

If I understood your idea correctly, proxy would shield you from underlings and allow you to reach the boss without so many interruptions from underlings? Sounds reasonable idea to me.

Is there any reason player would want intentionally have a broken proxy? Might be a nice tactical option for player.

2

Programming / Re: Dice doesn't need to be this complicated.:/

« on: March 05, 2017, 08:19:09 PM »

That tutorial is doing pretty generic dice roller, that can handle lots of different types of die. It can roll one die "d6", two dice "2d6", three different types of die "d4+d6+d8" and so on. This is the main reason why the code is rather complex. Your solution however, is much clearer when rolling single die of specific type. If only simple roll is needed, no need to build complex solution.

3

Programming / Re: Organized method of scripting games?

« on: March 05, 2017, 08:13:11 PM »

What I'm wondering is, what would you call something like this? I tried making something like this before, although at the time I was a lot less concerned about simplification of code, so it got a lot more errors.

I would call that roguelike engine, since it's like Hamster Game Engine, but geared towards roguelikes.

4

Programming / Re: Packaging a python script as an executable

« on: January 18, 2017, 10:36:35 AM »

It's been a while since I used py2exe, but my hunch is that you should explicitly include BearLibTerminal.dll in your package, as shown in http://stackoverflow.com/questions/220777/including-pyds-dlls-in-py2exe-builds

5

Programming / Re: Rule libs for managing statuses & attributes?

« on: October 26, 2016, 08:19:55 AM »

I haven't completely given up hope with learning miniKanren and Adderall, but I'll tinker with something else for a bit and then get back to representing some of the interactions with miniKanren. I really like the idea that I can use the same code to both implement interactions and to reason about them. And since it would be relatively generic system, adding new items wouldn't necessary mean that I have to mess around with AI code.

6

Programming / Re: Rule libs for managing statuses & attributes?

« on: October 23, 2016, 08:04:03 AM »

This looks pretty nifty, thanks for sharing. I haven't done anything that complicated, but I tinkered a bit with miniKanren (wrote a little blog post about it too: https://engineersjourney.wordpress.com/2016/04/06/wishful-coding-adderall-traps-and-items/). It was much more simpler idea than yours, but could run rules to both directions (drinking this potion will slow me, does drinking this potion make me slow? what can I drink to be slowed? what does this potion do? and so on). Grand idea was to use it for AI stuff and goal finding, but I didn't quite get it to working as I wanted.

7

Design / Re: Whimsy in Naming Conventions

« on: October 19, 2016, 04:29:22 AM »

This is funny story, thanks for sharing it! Too bad that I don't have any similar ones (or at least don't remember any). My names are boring like generator, names, creature and such.

8

Programming / Re: Dijkstra Maps... What have I done!?

« on: October 11, 2016, 12:04:19 PM »

If I read your code correctly, you shouldn't be adding neighbour to l_open, if it already has a value associated to it. So instead of:

Code: [Select]

9 8 4 5 6
8 7 3 4 5
7 6 2 3 4
6 1 1 1 3
5 1 0 1 2
4 1 1 1 2
3 2 2 2 2
You want (player or goal located at 0):

Code: [Select]

4 4 4 4 4
3 3 3 3 3
2 2 2 2 2
2 1 1 1 2
2 1 0 1 2
2 1 1 1 2
2 2 2 2 2
After this path finding is simply just going towards smallest number.

9

Programming / Re: DIY programming language

« on: August 31, 2016, 10:39:17 AM »

Easy as

I think you need to install some kind of Git Shell, or what it was called, and compile from source. Hard?

For MonoGame? Just use nuget-packages from nuget.org (https://www.nuget.org/profiles/MonoGame) and you're set. Bonus points for being ready to update to a newer version when it gets released.

10

Programming / Re: DIY programming language

« on: August 31, 2016, 03:24:59 AM »

But.. it's slow. Seriously. I can see the 80x25 level printing on console, it's that slow. I tried to replace Map with simple array (for tile glyphs) and use Console.Write instead of printf, but there was no difference. At least it looks like console programming is out of the question. I wonder how easy it is to go graphical on F#.

Easy as eating a pie. Just pick your favourite .Net graphics library and go wild. I found MonoGame (http://www.monogame.net/) both easy and fast. For console stuff there's MonoCurses (https://github.com/mono/mono-curses/).

11

Programming / Re: DIY programming language

« on: August 22, 2016, 10:17:26 AM »

I don't know if it has to be similar to C++. More like better if it's not.

It'll be easier to find when you know what you're searching for. When you find your language, do let us know 

12

Programming / Re: DIY programming language

« on: August 22, 2016, 06:30:00 AM »

Java is compiled into a specific form of byte code

Yes, it's for java, not for any other language. At least I haven't heard you could compile some other language to java byte code and run with jvm (well, except Scala I guess?). So the java byte code IS java, just in a sort of half-ass-compiled way, slower than pure machine code.

"Argument from (personal) incredulity (divine fallacy, appeal to common sense) – I cannot imagine how this could be true, therefore it must be false."

Here's a handy list of languages that target JVM: https://en.wikipedia.org/wiki/List_of_JVM_languages

But I was wondering. If you are after OO language that has similar syntax as C/C++, have you had a look at C#? Pretty familiar language, but has bunch of constructs that make your life easier.

You could write down list of features that you definitely want, would like to have and which would be nice. Armed with that list and internet, your search might turn up some language(s) that could be good candidate for next project.

13

Programming / Re: DIY programming language

« on: August 21, 2016, 03:35:21 PM »

Parlor tricks with syntax or esoteric features are fun to talk about, but not particularly useful in evaluating a language.

I don't think syntax is a trick. For example I don't like lisp's syntax and probably never will.

I didn't claim that syntax is trick or completely irrelevant. I merely pointed out that parlor tricks with syntax aren't that good grounds for evaluating a language.

One could ask questions like: "does it have objects?", "how are objects built?", "can I combine objects to create more complex objects?"

Or even: "does it have arrays?", "what can I put into arrays?", "can I put arrays in arrays?", "What other datatypes are there?", "How do I combine datatypes to bigger constructs?", "How do I make big blog of combined data to behave in a cohesive way?"

"Can I have subroutines?", "Can I combine subroutines to bigger subroutines?", "Can I pass sub routines around as data?", "Can I create subroutines from subroutines that were passed in?" and so on.

It's ok to not like a language because of its syntax. But it's not particularly good idea to say that some language is superior to other just because of its syntax.

14

Programming / Re: DIY programming language

« on: August 21, 2016, 01:15:10 PM »

Every language has a learning curve. If there isn't curve, you aren't learning and are merely just hashing old ideas. And that's not particularly productive, usually.

There's also difference between core ideas of language and its syntax. Latter of those requires merely some memorization, while learning the former actually exposes you to new ideas and paradigms. You can pick up OO language and write code that looks very procedural. Or you can pick up lisp and write very object heavy code with factory objects and such. Doing so misses the point why the language was invented in the first place.

I'm repeating myself, but when evaluating a language, one should look past (not completely ignoring though) its syntax and see what are the primitive parts of the language, how you can combine them to create new parts and how do you create abstractions for those new parts you created. Parlor tricks with syntax or esoteric features are fun to talk about, but not particularly useful in evaluating a language.

15

Programming / Re: DIY programming language

« on: August 20, 2016, 11:20:19 AM »

I have heard quite a bit good things about scala, but haven't programmed with it. It's yet another example how languages are developed and features collected from various other languages. No wonder software development (at least in some areas) is moving towards polyglot culture, where no single language is considered the only viable choice. Keeps your world view fresh too, when you have to pick up new things and try out new features.