Messages

16

Programming / Re: DIY programming language

« on: August 19, 2016, 10:07:15 AM »

I watched the first part. Besides almost falling to sleep I learned that the students tried hard to look smart, lisp teachers are smug and there was young Bill Gates in the class.

 

On a related note, Humble Bundle has a bunch of programming books for sale currently. Lots of interesting looking titles for languages like Python, F#, Lisp, Erlang and Haskell. And bunch of books that aren't language specific as far as I can tell.

17

Programming / Re: DIY programming language

« on: August 14, 2016, 03:10:25 PM »

When talking about DIY languages, lisp tends to pop up a lot, and for a good reason. In general, it's good language. In particular, it's great language for writing the language that you want to use to solve a particular problem. Since code and data are interchangeable in lisp, it's a language that is easy to extend to handle features you would like it to have. It's also very simple language. Writing a working lisp interpreter is a weekend excercise (and fun to boot).

There are some features I would like it to have though, one of them being some sort of static typing with inferred types. But I guess I can't have everything, can I?

There's nice set of MIT lectures for Structure and Interpretation of Computer Programs. It's starts very slowly, from very basic things, but eventually gets to really mind blowing stuff. I often rewatch it just for the sheer fun of it.

Coming up with own language is fun exercise, you should definitely try your hand on it and see what you can come up with.

18

Programming / Re: Heterogeneous saving and loading objects in C++

« on: April 07, 2016, 04:33:55 AM »

I dont' do C/C++, but I found skullcoders explanation interesting to read and I learned something while doing so (surprisingly, serialization isn't in stl yet). Thanks for taking your time to write that.

19

Programming / Re: working with AI library of sorts

« on: April 06, 2016, 06:41:39 AM »

I tinkered with some miniKanren code and wrote a blog post about it too (https://engineersjourney.wordpress.com/2016/04/06/wishful-coding-adderall-traps-and-items/). What's not shown is a small function that when given characters inventory and trap they want to cross, will find out all the items that could be helpful:

Code: [Select]

(defn helpful-items [inventory trap]
  (run* [q]
        (fresh [item trigger mode]
               (memberᵒ item inventory)
               (triggerᵒ trap trigger)
               (safe-modeᵒ trigger mode)
               (effectᵒ item mode)
               (nameᵒ item q))))

Essentially, the code is saying that there are three logic variables: item, trigger (what triggers the trap) and mode (what movement mode should be safe). Then it goes about to declare relations between them and passed parameters inventory and trap: item is member of inventory, trigger is triggering effect of trap, trigger and mode has safe-mode relation (mode will be what doesn't cause specific trigger to work), mode also will be an effect in item (flying, teleporting, etc.) and finally q (the return value of logic program) will be name of item.

The progress has been slow (got sidetracked with other things), but I have a hunch that this might be an interesting approach. Drop memberᵒ goal and unify item with q and suddenly program will start producing item descriptions that help you to crossing the trap. I can see feeding this description to item generator when level is being generated, so the level is guaranteed to have item(s) for getting past some specific trap.

And to make sure that AI is up to date with rules and vice versa. I would be checking if moving through a trap using certain movement mode triggers is, by using same goals:

Code: [Select]

(defn triggers? [trap mode]
  (not (in #U0
          (run 1 [q]
                 (fresh [trigger]
                        (triggerᵒ trap trigger)
                        (safe-modeᵒ trigger mode))))))

Here I'm stating that trigger is what-ever causes the trap to sprung and there is safe-mode relation between that trigger and current movement mode. If program finds any answers, the trap doesn't trigger, so as a final flourish, I'm taking a negation of the result.

So slow progress and dumb ai still, but I'm having fun tinkering with these ideas and seeing what I can cobble together.

20

Programming / Re: What would a programming language for roguelikes look like?

« on: April 02, 2016, 04:37:21 AM »

I find this topic fun. Perhaps if you ever end up building a custom chip for your new roguelike language, you could include the option to turn permadeath on, which would instantly fry the chip when you lose. Then you have to go solder another one in!

  That would be hilarious.

After sleeping a bit, I think I have another perspective to this. Maybe we should look from point of view of primitive, means of combination and means of abstraction too? They're the basic parts of pretty much every programming language and the essence that really tells them apart.

Primitives: the usual suspects like numbers, text, lists and such are obvious. But since we're talking specificially roguelike language, should there be higher concepts here too? Like character/creature, item, coordinates, action, ai-routine and such? If they're very detailed, building different kinds of roguelikes might be tricky, but if they're too vague they're maybe not so useful? Code is one primitive too I would say. Things like lazy and infinite datastructures and asynchronous operations would be nice to have built into language.

Means of combination: Code gets put together sequentially. Primitives can be placed inside lists and arrays. Actions can be chained together to create more complicated actions (or is this last one actually about abstraction or both even?) Pieces of AI-routines can be combined in a meaningful way with state machines and other AI-routines to create more complex/sophisticated AI-routines.

Means of abstraction: Code can be wrapped into functions, so we can give explicit names to higher level concepts. Functions can be used as parameters and return values (think of a* where you can parametrize how routine works by passing in part of the routine).

21

Programming / Re: What would a programming language for roguelikes look like?

« on: April 01, 2016, 09:10:45 PM »

I'm extremely biased on the subject, as I have been tinkering with something like this for a bit. Also, language features is one of those topics that can generate very heated discussions, so be warned This is just my opinion on the subject and isn't any more correct or more wrong than any other opinion on the topic.

I wouldn't choose OOP as main paradigm, but rather split data and functions that operate on that data apart. It's easy to build a hierarchies and topologies of different type of data, but as soon as behaviour enters the picture it starts to get trickier. Having functions that operate on the data separate also helps in organizing the code and reduces amount of 'doers', 'managers' and 'utilityclassxes'. It also helps to answer the question "if I want to read a scroll, who has the method? character, scroll, some manager?". Multiple dispatch would be really nice, with :before, :after and :around semantics like in CLOS, so one can check if preconditions of a function (like attack for example) are fulfilled, before calling the function. Compile time type checking with inferred typing would be my preference, but my preference on that tends to fluctuate a bit. I like syntax of lisp quite a bit, so I think I would take that as a base.

Having ability to model the basic constructs like state machines is very good idea. Syntax I chose for my current project is somewhat like:

Code: [Select]

(defstatemachine <statemachine name> [<interface>]

  (--init-- [<init parameters>] <init code>)

  (<state> <initial-state>
                (on-activate <activation code>)
                (active <code that is run while state is active>)
                (transitions [<check> <new state>]
                                   [<another check> <another state>]))
  <more states>)

This creates a state machine, which can then be instantiated and called like it were a function with parameters defined in <interface>. <init parameters> and <init code> are for initialization of the finite state machine. Each state is then defined in a block that starts with name of the state (on being marked as initial state, which is the state the state machine starts in). on-activate block is executed when state activates, active is run when finite state machine is given signal to process and transitions define when and how the machine switches to different state.

Ability to do random stuff, without having to resort to random numbers and comparing them to some range is nice. So instead of:

Code: [Select]

(if (> (.next random 1 100) 90) (something-bad-happens player-character))

I want to write:

Code: [Select]

(rarely (something-bad-happens player-character))

Another option I would like to have is relational or logic programming. Instead of describing an algorithm, I would describe problem domain and relations of things within it and let the computer to solve the problem. For example, if a AI character would like to figure out what kind of items it needs to bypass a trap and if they already have them, it could be done with a program like (this one doesn't take account possible skills or perks of the character, only their inventory):

Code: [Select]

(defn item-for-safe-passage [inventory trap]
  (run 10 [q]
    (fresh [item trigger safe-method]
      (triggerᵒ trap trigger)
      (safe-movement-methodᵒ trigger safe-method)
      (memberᵒ item inventory)
      (effectᵒ item safe-method)
      (nameᵒ item q))))

Code would output at most names of 10 items that let character to bypass the trap. Neat thing about this approach is that the goals can work all directions. For example in:

Code: [Select]

      (safe-movement-methodᵒ trigger safe-method)

If triggering method is know, this will produce safe method of crossing the trap. If safe-method is know, this will tell what kinds of triggers can be avoided with that. If both are known, the code will check if the trap is sprung or not. Since this language can be wrapped into a function, it is transparently callable from regular code. Having AI and game logic share the same routines helps to make sure that if rules of the game are updated, AI is updated too.

Since designing language is hard and designer will never get it right for every user, I would like to have ability to modify and extend the language. It could be done in macro system similar to what lisp has, or it could work with some other system. But since ability to do symbolic programming is something I really like, lisp macros would be my preferred method of extending the language.

I think something like that would be my start.

22

Programming / Re: working with AI library of sorts

« on: March 29, 2016, 04:28:27 AM »

I've been playing around with different AIs in my current project, Professional Adventurers' League.
To start with, actors are classified as either smart or dumb.  Smart actors use A* pathfinding and avoid dangerous terrain, while dumb ones check to see if the most direct step toward the nearest enemy is possible, then the two adjacent steps; if none of those, they stand still.  Dumb actors blindly charge through dangerous terrain.  Some enemies can use doors, some can't.

I keep too different 2D boolean arrays for pathfinding; one for walkers and one for flyers.  That way I don't have to recalculate anything and the actor just grabs the appropriate map.  The only exception to this is for enemies who burrow; they grab a copy of the appropriate map, then mark all nearby diggable cells as passable.  This stays reasonably efficient, as there there are never many burrowing enemies.

Some of my ranged actors will prioritize staying at range over attacking an enemy; one particularly family of actors uses Dijkstra maps to flee around the player when cornered, while the others just back directly away and switch to attacking if cornered.

Ghouls will move near, but not adjacent to, an enemy.  They will attack the enemy if it moves adjacent to them (they don't run), they are hasted (they can self-buff by eating a corpse), or there is an ally adjacent to the enemy.

Revenants will prioritize moving to a corpse so they can possess it, and if one is not available and they don't have a host will flee from the enemy.

This sounds neat, especially how ghouls kite the player into attackking them. What will they do if player has ranged weapon and never come next to them?

I really like the sound of the game as enemies seem to be varied and have different behaviours. Fleeing is something that I have been considering, but haven't gotten around implementing. How did you implement dijkstra maps for fleeing? Fill with player at tile 0 and have monster move to downhill on the map?

23

Programming / Re: working with AI library of sorts

« on: March 23, 2016, 11:35:47 AM »

I'm huge fan of having different monsters that differ in other ways than just stats. It doesn't even have to be that different before interesting things start popping up. Like the aforementioned rats and beetles. They have almost identical AI, except rat likes to live by the walls and beetles away from walls. When there are couple of both in a big room, rats will patrol around the walls, while beetles take care of rest of the room. Player can still try and sneak past them, but it's a lot harder. Movement patterns are probably one of the easiest ways to differentiate monsters. It's readily available for player observation and is easy to follow over time.

Natural obstacles could be fun, as ones obstacle is others' home. Bats could live inside deep pits and emerge when somebody disturbs them and eels could lurk under water. Currently none of my creatures really understand what pits mean for them, so they just try to walk over them and die in process. I have been playing with an idea that AI could reason about things like that to a degree: it would understand that walking over pit means it doesn't have support from below and thus would fall down and hurt itself. But if it can fly (by natural or unnatural means), pits aren't problem at all. But that probably is too resource intensive to be run for each and every character, at least for each and every step. Maybe a two level approach would work, where more resource intensive part of the routine is ran less often and less intensive more often. Less often run routine could be in charge of selecting high level goals and making broad decisions (like deciding to cross trap by going through it) and lower level system would be in charge of more simpler tasks (finding path and such).

Tracking by scent doesn't sound too complicated to write. I'm not sure how granular the simulation should be, ie. would all horses smell same or could bloodhound track a specific one? From realistic point of view, one could tell the scent apart, but what would make most sense from the gameplay point of view? Would be funny if characters could use oils to mask their scent or even impersonate other creatures. Tracking by memory sounds a bit more complicated, as creatures would have to remember where they last saw the foe, walk there and start looking until eventually giving up.

Lots of good and interesting ideas. Probably just have to slowly chip away the easiest ones first and then what kinds of tools that will give to me and then build more complex cases on top of the more simpler ones.

24

Programming / working with AI library of sorts

« on: March 22, 2016, 08:37:06 AM »

I have been tinkering with a rewrite of my messy AI routines and got the first one done. It's super simple, just a rat that selects a room, travels there and then patrols along the walls. If enemy comes close, it switches to combat mode and starts fighting. After enemy either dies or runs away, the rat returns patrolling the room. It's a rough draft still, for example any creature with different name is considered as an enemy (so player can see rats and beetles fighting with each other). Current code is at: https://github.com/tuturto/pyherc/blob/master/src/herculeum/ai/rat.hy and https://github.com/tuturto/pyherc/blob/master/src/herculeum/ai/firebeetle.hy

Most likely it doesn't make sense to publish this as a real standalone library, but I'm still trying to have it be mostly nicely contained within the codebase of the game. There are actual finite state machines for AIs that are generally per monster and then underlying set of functions that implement specific behaviour. Combining the functions and a bit of logic in state machines is how I envision the library working in the end.

A bit further down the road I would like to add more complex things, like scavenging level for gear and selecting what items to use or deciding when it makes sense to take a short cut over a trap instead of going around. Maybe even throw in a bit of fuzzy logic, so I can raise level of abstraction from solid numbers to ranges of things.

But this is where I'm drawing a blank. What else should there be that would create interesting creatures and situations? I like having monsters that player can lure to fight with each other for example. And maybe a group of creatures that move together as a loose band. But what else would be interesting? What are memorable creatures from other creatures, mainly because how they functioned?

25

Programming / Re: Monsters moving between levels

« on: March 21, 2016, 08:39:46 AM »

I was just thinking about this and how it could be weird to program so i was wondering if there were some specific approaches that people knew of that would help?

Normally you'd just have monsters from the current floor be active in your game, so moving monsters between floors could get tricky. The only thought I had was when a monster is pathfinding to the player and the player goes down stairs, the game will register that that monster was x turns away from the stairs and once those x-turns are up it adds the monster to the new floor at the correct spot.

That sounds like a good solution if you don't want to have multiple levels active. You could try having the level where player is active and the levels that can be reached from that level and see how big impact it has on performance. If you aren't keeping multiple levels active, you pretty much have to abstract movement somehow and counting x turns sounds like a good plan. Of course then you have to think what to do if the monster has some active spells or status effects (poison, being on fire and such) and think how to deal with them.

26

Design / Re: "Fun" Maps

« on: March 17, 2016, 11:38:16 AM »

Emergent game play can be really interesting, even for the designer.

Yee the emerging gameplay is awesome but it's not easy to achieve. You also can't control it . It just happens. In my experience the only way to get it is keep adding new mechanics and hop it will magically appear. If someone has a better approach i would love to hear it

I guess that's why it's called emergent, it happens as a sum of lots of little things. One can experiment and prototype these and see what they'll find. Open game system probably helps too (in a sense that if you explode an oil bottle, it'll damage surroundings -> can be used as a weapon or as a way to break through doors. Or crack ice with it and create traps.) But interesting emergent gameplay is hard to achieve. Balanced even more (I'm going to ignore balance in my game pretty much completely, just aiming for having fun while exploring).

27

Design / Re: "Fun" Maps

« on: March 17, 2016, 08:46:45 AM »

This is mildly similar to a frequent RPG question of how to make quest text interesting. The best writing (or best level generator) will still be ignored and invisible to the player... unless it affects gameplay.

So the best terrain, IMO, is terrain that interacts with your game, mechanically. Pools of water that do nothing are background noise, but the player notices water if it sometimes contains eels. Doors are meaningless unless you can use them to surprise or be surprised by mohsters - or lock them in TGGW-style!. Grass is cooler when you can set it on fire. Etc etc.

And it doesn't even have to be anything really complex. Just little details like mentioned by forumaccount take you far already. Emergent game play can be really interesting, even for the designer.

28

Programming / Re: Any programs like Game Maker to create Android games?

« on: March 08, 2016, 05:43:03 AM »

The little experience what I have with Unity is positive. You still need to know how to program, but the system takes care of lots of more mundane things. And lots of pre-made components are available at the asset store for relatively cheap price.

29

Design / Re: OOP, ECS, Roguelike, and definitions

« on: March 05, 2016, 03:07:46 PM »

If you use lisp, your code is just data too

And instead of writing an engine, you'll end up writing a whole new language, to write your engine, to code your game

30

Programming / Re: beyond python and curses

« on: February 24, 2016, 07:08:28 AM »

And no, farmer is not a surname. You actually grow stuff and then kill demons by throwing beetroots at them.

I'm loving this Is that available somewhere? I would like to give it a try.