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 - Antsan

Pages: 1 [2] 3 4
16
Programming / Re: DIY programming language
« on: July 27, 2016, 10:38:58 AM »
I'm currently in July'9. The blog is surprisingly readable this far, but there's already a ton of head-scratching going on. How the heck do you design a map generation algorithm in a way that leads to corridor carving being tightly coupled to the rest of map generation?

Word of advice: Problems don't exist in anything itself but only in the relations between things. That is, not the programming languages are flawed, the relation between you and programming languages is.
Of course you'd have a point if there were problems in all relations between programming languages and humans, but I can assure you that this is not the case.

17
Programming / Re: DIY programming language
« on: July 26, 2016, 04:45:58 PM »
I'm not sure whether you're trying to mask your own ignorance or trolling.

What would you actually want to see in the first place? It's kind of strange that you only give off these fuzzy, non-descriptive blurbs about some nebulous ideas that there may be some interesting concepts to make programming more accessible for non-academics, but finding out what such a language would actually look like doesn't seem to be in your interest. I mean, I'm showing you a tool and you berate me for not doing your work for you?

Of course I'm showing you trivial examples!

18
Off-topic (Locked) / Re: Thea: the awakening
« on: July 25, 2016, 05:19:41 PM »
But they're social and the go outside and they aren't full of contempt and bitterness! Who could ever like them?

19
Programming / Re: DIY programming language
« on: July 25, 2016, 02:54:49 PM »
I'd really like t know what you were reading, that would give me some idea what you might already know.

And given by your behavior up to this point I'd wager everything I could show you would either be not impressing enough or too complex for you to understand in a timespan that you'd consider worthwhile. I mean, how much time have you spent with Common Lisp before dismissing it? Half an hour? Cannot be more than that if you haven't even found out about macros yet.

But just for you, here's a demonstration of some stuff that is possible in Lisps. If you don't understand what's going on here I'd advise searching out some actual tutorials on Lisp, like, I don't know, Practical Common Lisp or this sample chapter from Land of Lisp or if you want to dive into the more unusual stuff straight away because properly understanding a language is for babies, you can read On Lisp, which is all about macros. I'd also recommend buying "Let Over Lambda", but I assume making such an investment isn't really useful for someone with the patience of a cat.


Let's start with something trivial.
When looking something up in a collection oftentimes you get either back the object you were looking for, or a "NIL" value. This normally looks like this in code:
Code: [Select]
(let ((targeted-monster (find-occupant square)))
  (if targeted-monster
      (hurt targeted-monster)
      (message "There's no target at this point!")))
It's not really that much, but after a while it gets tedious to do that all the time. So I'll write a macro to do it for me:
Code: [Select]
(defmacro [a]if (test then &optional else)
  `(let ((it ,test))
     (if it
         ,then
         ,else)))
Now I can write code as above like this:
Code: [Select]
([a]if (find-occupant square)
       (hurt it)
       (message "There's no target at this point!"))
That already saves a lot of typing.


But that's trivial. Barely worth talking about.
I don't know whether you know about the difference between eager and lazy evaluation. If you don't, go read up on it.
Most Lisps are eagerly evaluated, especially since Lisps are very decidedly not functional and lazy evaluation tends to behave weirdly when side effects are involved unless special care is taken to avoid these problems.
Still, lazy evaluation can be tremendously useful in parts of a program not relying on side effects. Although Common Lisp does not support lazy evaluation out of the box, you can implement it. There are many ways to do this and I'm going to show you the easiest way of doing it, not the most useful one:
Code: [Select]
(defmacro freeze (&body body)
  `(lambda ()
     ,@body))

(defun force (thunk)
  (if (functionp thunk)
      (funcall thunk)
      thunk))
Those to alone aren't that useful, but more powerful macros can be written atop them to make them more useful:
Code: [Select]
(defmacro let~ ((&rest bindings)
                &body body)
  `(thunk
    (let (,@(mapcar (lambda (binding)
                      `(,(first binding)
                        (force ,(second binding))))
                    bindings))
      ,@body)))
and so on. I've got a more involved library for the whole thing here, which relies on this. That library also implements algebraic data types and pattern matching on those algebraic data types.


Of course that's still small fries. writing some lazy evaluation library is only a few steps above writing a "Hello, world!", even if tons more useful.
I already know you think little of entity-component systems, but I find them to be incredibly useful. There already are some implementations for them on the net, but because they all relied on a central system loop to access them, which is too restrictive for my tastes and provides features I really don't need, so I rolled my own.
Entities themselves are simple objects, and the can be created like this;
Code: [Select]
(entity)
They aren't particularly interesting in themselves. The interesting parts are the components. To define a certain type of component, I can do one of the following:
To define a component with an already existing type:
Code: [Select]
(define-component-type strength (integer 0))
To define a component as a structure type:
Code: [Select]
(define-component-struct inventory ()
  (content (empty-set)
           :type set)
  (capacity 0
            :type (integer 0)))
Components can also depend on other components being present.
And then I can write functions which will only be run on entities in which certain components are present and let them do just nothing on other entities:
Code: [Select]
(define-entity-method distance ((e1 entity location1)
                                (e2 entity location2))
  (max (d (x location1)
          (x location2))
       (d (y location 1)
          (y location2))))

You want the implementation of these things?
Here's a paste. I don't want to make the corresponding repository public yet.
Here's some snippets of stuff not in this file:
Code: [Select]
(defmacro [a]if (test then &body else)
  `(let ((it ,test))
     (if it
         ,then
         (progn
           ,@else))))

(defmacro [a]when (test &body then)
  `([a]if ,test
       (progn
         ,@then)))

(defmacro [av]if (test then &body else)
  (let ((g!found? (gensym "found?")))
    `(multiple-value-bind (it ,g!found?)
         ,test
       (if ,g!found?
           ,then
           (progn
             ,@else)))))

(defmacro [av]when (test &body then)
  `([av]if ,test
       (progn
         ,@then)))

(defun car-or-x (x)
  (if (consp x)
      (car x)
      x))

(defun symb (&rest objs)
  (intern (format nil "~{~A~}"
                  objs)))

(defun ensure-list (x)
  (the list
       (if (listp x)
           x
           (list x))))

(defun plist-rem (indicator/s property-list)
  (declare (type (or cons symbol)
                 indicator/s)
           (type list property-list))
  (the list
       (loop for (prop item)
          on property-list by #'cddr
          unless (if (consp indicator/s)
                     (member prop indicator/s
                             :test #'eq)
                     (eq prop indicator/s))
          nconc
            `(,prop ,item))))

(defun copy-hash-table (hash-table)
  (declare (type hash-table hash-table))
  (the hash-table
       (let ((newhash (make-hash-table :test (hash-table-test hash-table)
                                       :size (hash-table-size hash-table)
                                       :rehash-size
                                       (hash-table-rehash-size hash-table)
                                       :rehash-threshold
                                       (hash-table-rehash-threshold
                                        hash-table))))
         (declare (type hash-table newhash))
         (maphash (lambda (key value)
                    (setf (gethash key newhash)
                          value))
                  hash-table)
         newhash)))


None of this is in Common Lisp by default. Every programming paradigm you can come up with is implementable in Common Lisp itself in such a way that you can write it intermingled with the more typical Common Lisp. Damn, there are libraries implementing Prolog in Common Lisp – that is, you can write Common Lisp and Prolog in the same file without any external tools, without the need to write a Prolog interpreter or compiler. Just load the library and you're good to go.

Even if you're not going to use Common Lisp or any other Lisp for writing your roguelike, a Lisp is still your best bet for writing your own programming language. Once again, I point you at "Let Over Lambda" and "On Lisp".


In the end, unless you are willing to understand what programming actually is, it doesn't matter which programming language you are working in, you're just going to suck at it. And if you're going to write a programming language without any effort on your part to even understand what others have already been doing, your programming language is going to suck, because you'll make errors that others already made decades ago only because you have no idea why programming languages are the way they are.
Breaking stupid rules is a worthy endeavor, sure, but before that you must understand the rules you want to break.

20
Programming / Re: DIY programming language
« on: July 25, 2016, 08:42:36 AM »
What CL manual? The Hyperspec? The manual of some CL implementation?

If you think that CL is like any other programming language you are factually wrong.

21
Programming / Re: DIY programming language
« on: July 24, 2016, 12:13:29 PM »
You're wrong, but only by a technicality. But knowing math has nothing to do with understanding Lisp, especially since in math at the University Java (urgh) seems to be the language of choice.

I embrace both math and Lisp because both have a focus on cutting down rules to the bare minimum. The less rules I have to keep in my head, the better.
C and everything close to it seems like a huge pile of rules which don't lead to anything interesting. Lisps are smaller collections of rules which interact in awesome ways to allow for extremely powerful stuff.

22
Programming / Re: DIY programming language
« on: July 24, 2016, 11:36:33 AM »
I learned programming with Delphi, Haskell and Prolog in school. I tried for years to grok C/C++ and never got anywhere – of course I understood the principles, but that somehow never coalesced into anything usable.
When I picked up Common Lisp, it just clicked and everything fell into place. he syntax is the most natural I can imagine. For me other languages have ridiculous syntax. It's all a matter of perspective.

23
Off-topic (Locked) / Re: Thea: the awakening
« on: July 23, 2016, 02:04:59 PM »
This game is interesting to me, there are damn good commercial roguelikes and I generally don't like people who use "we" instead if "I" – it's disrespectful and arrogant.

Quote
And who the fuck are you?!
Antsan, registered 6 years before you. Who are you?

24
Programming / Re: DIY programming language
« on: July 23, 2016, 01:23:36 PM »
Quote
When I've been working on a large scale roguelike one of the things that has always interested me is the relationship between code and data. There is something about handling data that feels "wrong" if you know what I mean. I don't know what it is exactly, maybe the rigid way C++ handles data in extremely low level way.
That suggests a few things to me:
1. You want a language with value- instead of variable-typing.
2. You may want to look into reactive programming, which is describing programs similarly to (but more general and flexible than) spreadsheets.
3. You want automatic garbage collection.
I'd recommend Common Lisp (of course) together with cells, but cells isn't in quicklisp anymore. I don't think you'd like Haskell with reactive-banana, judging by your dislike of functional programming. I don't really know which other languages have something similar.

25
Design / Re: Corridors considered harmful
« on: July 23, 2016, 01:07:00 PM »
Here's another idea to make corridors interesting and dangerous to the player: Add the ability to move past an enemy for giving them an automatic free simple attack. This way players can be way more easily be circled inside corridors. When the game is balanced to mostly generate groups of between 2 and 7 enemies, fighting in open spaces becomes more desirable than fighting in tight corridors, as long as the ability to get away fast is more important than to fight few enemies at once.
The question is how to balance it that freedom of movement is more important than preventing raw damage.

Quote
Don't say such reddit things. You're better than that.
I'm kind of sorry. After coming back here after a few years my first impression just was that any topic explodes into fights pretty fast, no matter the topic. I actually did look at reddit shortly after (didn't bother with that before) and at least roguelikedev seems to be a nicer place.

26
Off-topic (Locked) / Re: Thea: the awakening
« on: July 22, 2016, 10:19:39 PM »
Speak for yourself.

27
Programming / Re: DIY programming language
« on: July 22, 2016, 10:17:22 PM »
When people other than programmers/scientists/engineers develop programming languages, stuff like COBOL, Java and php happens, so… no thanks!

Writing your own language is surprisingly easy. It just doesn't help that much. I wrote Poslin with a whole standard library and I intend to continue working on both (because I actually really like it – is there any other language in which the user can add their own optimization passes? I only need to add the corresponding syntax making it easy enough…), but for the moment I do everything else in Common Lisp either way – when I need another way of expressing my idea of what the program should do, I write the macros which allow me to express it in a way that suits me.

My advice is this: Try to formulate what you want your language to be like. You can start fuzzy, but you will need to get concrete very fast.
You'll need to write prototypes to test your ideas – something that seems nice in your head might not work out when you actually try to program in it. Some stuff you thought would make your life easier might actually make programming incredibly hard because it has strange corner case behavior you didn't think of – avoiding these corner cases with checks doesn't really help, especially since it will make the semantics of your language even harder to understand.

28
Early Dev / Re: Ultima Ratio Regum (v 0.7 released, 18th April!)
« on: July 22, 2016, 09:43:43 PM »
I think making URR OS is actually not up for debate. I assume the comment about openness to suggestions was in regards to game mechanics.
I mean, why are you guys even talking about this, it was already said that URR isn't going to be Open Source. It seems this has been discussed elsewhere quite extensively already.

29
Design / Re: Corridors considered harmful
« on: July 20, 2016, 09:32:13 PM »
Well, while I think corridors are perfectly fine to have in your roguelike I think a discussion about how to make them more interesting is still worth having.
But by my impression maybe not in this forum. What a shame.

30
Early Dev / Re: Ultima Ratio Regum (v 0.7 released, 18th April!)
« on: July 20, 2016, 11:46:07 AM »
I should have specified better: Is there going to be a way to add kennings? This seems like the kind of stuff that isn't spoilery and well-kept in text-files either way (or I'm missing some very important stuff here), so I wonder whether you are keeping kenning definitions in plain text files, which could be edited by players.

Pages: 1 [2] 3 4