Wanderers / open world RL

[koiwai]

What is interesting about it?

1. The game is quite different from many Roguelikes and RPG games. First of all, the time system is semi-continuous: Your discrete actions are simulated in the continuous space and time, so you get interesting combat mechanics with a lot of pushing and dodging, while largely preserving the feel of familiar grid based games. 

2. The game world is simulated on two scales: The area around the player is simulated precisely with every detail taken into account, however, the rest of the world is not static and is evolving too with a bit coarser but still quite accurate simulation. Both simulation levels interact seamlessly, so your small actions will affect the whole big world. You can defend your village and make it stronger in the war with a neighboring tribe, or you can go explore the world and fight monsters in the underground dungeons.
 
3. Many features, for example social organizations of the NPCs, reputation, rumors, spell casting, villains, apocalyptic events and global quests are not implemented yet.

Can I play the game?

>>> Download for Windows:
Download the latest Windows build (January, 20, 2015).

How to play: README at Github.

>>> Download for Linux (and probably OSX):
Get the source code from Github. Compilation is straightforward. install the latest ocaml package for your system. Make sure you have your SDL1.2 and OpenGL libraries installed. Then just execute make.

How to play: README at Github

Controls

Arrow keys or h j k l - Movement
w a s d or Ctrl+direction - Melee attack
t - Rest
Space - Wait
i or Enter - Inventory mode (0, 1, 2 to move items between sections, Esc to cancel)
f - Ranged attack mode (f to shoot, Esc to cancel)
v - Interaction mode (v or Enter to open/close doors or barter, f for ranged attack)
m - Map (arrow keys and <, > to move, Esc to cancel)
< > - Use stairs
+ - - Faster or slower game speed
Esc or q - Cancel
Ctrl+q - Save and quit

Tips for new players

When you start playing, first, take a look at your CNS (Constitution). This is your mass in kilograms, and your max HP. Heavy characters are slower, and light characters are weaker. Also, light characters have better magical abilities.

The very first goal is to find some weapon, even a simple stick or a knife will make a big difference. You also may find a good random seed, where you start with weapons. To rest, press t, you will recover some HP. When equipping new items, pay attention to MBL (Mobility). When it drops down (say below 0.9), your damage also goes down considerably, and this is not what you want.

To get full Documentation about the game, read the README at Github.

The game is open source, distributed under GPL3 license.

[Rickton]

I like the art style, and the game sounds pretty cool. How much of the world simulation is already implemented?

[koiwai]

Rickton:
There are two main mechanisms implemented:

1. "Bulk" simulation of the world.
Each small piece of the map (region) stores its population, how many units of each faction is there. Number of houses. Total wealth of the region.

The world is simulated by a few rather simple rules: there is population growth, unit transfer between neighboring regions, fights between enemy factions, if their people happen to be at the same region. Houses are built and destroyed. This is very rough and approximate simulation, but it is detailed enough to resemple civilizations growth and their wars with each other.

When the player is nearby, a region is genearaged from its seed, and units are spawned. If you kill anyone, that unit is subtracted from the region's population. In the background, this region is still simulated as a part of the big world even when the player is there, but latently, the changes are saved and applied when you leave the region.
When you walk far away from the region, the region is reconstructed together with all its units and items. All items are decomposed into wealth.

In this sense, the world is semi-persistent. About 10-12 regions around you are stored and simulated in detail, but they get decomposed when you explore new regions.

2. Heroes (or actors) are persistent units, essentially like the player, they travel and fight mobs. Any mob (except domestic animals like cows) can be such a hero.

When heroes are in a region generated for detailed simulation,  they is spawned together with other mobs, and they act like normal mobs, no difference there. However, when the player leaves, they are not decomposed entirely. They travel in the "bulk" world, fight with local units (their fights are approximately fake-simulated), they pick up items, choosing the best possible equipment they can find.



All of the above is already implemented. What I want to add are organizations of heroes (actors). They are going to be tree-like hierachies. Starting with simple local militia to fight neighbors and wild animals to governments and military forces. Actors-Merchants to sell stuff. Actors-Craftsmen, Blacksmiths, Engineers, etc. to make new high-quality items. Good to make some factions more inclined towards technology and dwarf-like traits.

The factions, btw, are random and generated with the world. In the biginning of each game, I plan to ask for the name of the world and the name of the player. Both will work as seeds. So, you can play in the same world as many times as you wish. And you can play the same character in different worlds. I think, it can be interesting to add the following feature: If your character dies, but the final goals are not achieved, you can continue playing with another character. It is not a simple respawn, b/c you start a new character, and you loose a lot of time. But if you was very close to kill the bad guy, your second character can finish the job, where the first failed.

P.S. I liked Game Hunter's video of your game Possession, never played myself, but it looked very interesting

[Quendus]

This looks interesting. I had a similar idea bouncing around my ideas file, I guess you're saving me the trouble of actually making it. Looking forward to seeing what becomes of this

[reaver]

Same here, quite interesting idea - I'm currently toying with something similar, but more as pages of notes rather than code
How do you handle simultaneous actor movement? what if they decide to move to the same square, etc?

[miki151]

Looks really cool, and it's written in Ocaml!

I'm trying to compile it on Linux, but I get this error:
File "src/global.ml", line 18, characters 0-11:
Error: Unbound module Common

Any hints?

[Stone Dog]

Hey, this looks interesting.
Too bad I'm on Windows and don't know the first thing about coding/compiling.
Here's hoping somebody will compile for Windows, or suggest a workaround (which is not going to be "install Linux").

[koiwai]

Hope to make a fun game ) Thanks for the responses!

How do you handle simultaneous actor movement? what if they decide to move to the same square, etc?

I wanted to make a time system, where decisions don't cause actions immediately, but take some time. There had to be a mechanism to resolve collisions and other possible conflicts. Well, eventually, I had to sacrifice some discreteness, making units' positions continuous. But it does not seem to be a very big deal, all steps are still discrete, you walk from square to square, because you don't get control over your unit until you cross the boundary between the squares (+ some delay).

Every unit has "position" (pair of reals) and its "location" (pair of integers), this is the square the unit is in. In the gif, the location is marked by four green dots. When walking, units move to the center of an adjacent square.

Every unit, when its move is computed, checks its current square + 8 adjacent squares. If there are other units, a force is applied to the current unit so that it's harder to move towards others. The force is non-linear (see "sim.ml", function "move_dv" (line 109), and "force_collision" (line 118)).

So, there is a simple physical simulation. Units are pushed when they collide, or when they are hit. Of course, one could use some rigid-body physics engines - but you don't need that, all collisions between units are "soft", so simple integration of the Newton's second law is really enough. It's easy. Even the time step does not have to be very small.

With some continuity of movement, you can make crowded city streets (need to add thieves there!), hordes of monsters pushing you, and not just waiting while you kill them one by one. Some physics in combat is also interesting. If you are heavy, you pushing opponents, if you are light and small, you can escape easier.

Looks really cool, and it's written in Ocaml!

I'm trying to compile it on Linux, but I get this error:
File "src/global.ml", line 18, characters 0-11:
Error: Unbound module Common

Any hints?

I don't know why this is happening. This is what my compiler outputs when I make the game: http://sprunge.us/QfZE
First, it finds dependencies between the modules with ocamldep, then it builds the GLCaml library, that it builds the game itself.

What is your system and the version of the compiler? Btw, I don't use Jane Street's Core, only the original standard library. The external dependencies must be minimal, only installed OpenGL and C headers, probably.

Paste the full output of the compiler, it should help to find the reason for this behavior.

[miki151]

The movement system sounds awesome! Can't wait to compile this thing

Weird, I tried again and this time I got this error:

ocamlopt -c -I lib/ -I src/ src/view.ml
File "src/view.ml", line 381, characters 2-12:
Error: Unbound value List.iteri

My system is some old Ubuntu with Ocaml 3.12.1

[koiwai]

The movement system sounds awesome! Can't wait to compile this thing

Weird, I tried again and this time I got this error:

ocamlopt -c -I lib/ -I src/ src/view.ml
File "src/view.ml", line 381, characters 2-12:
Error: Unbound value List.iteri

My system is some old Ubuntu with Ocaml 3.12.1

I see. This an understandable error. List.iteri was introduced in 4.0.0.  But 3.12.1 is not that old, still I was using some functions from the 4+ version.

Maybe, I should try to add some workarounds for compiling with the 3.12 version, since I don't really use fancy novelties of the language. I will keep this in mind, thanks. For now, maybe, try to update to 4.1, if it's available )


Update:
In fact, "view.ml" is one of the last modules, so if the first error occured there then, probably, the code is largerly 3.12-compatible. I can simply replace this function with my own analogous, this is a simple iterator, nothing special. I will let you know.

[koiwai]

miki151: I fixed that particular List.iteri - replaced it with another function that is 3.12.1 compatible.

I don't have any means to check if it's enough or not. I tried to look through the rest of "view.ml" and "mail.ml", and did not notice anything problemmatic, but there is no guarantees 

[miki151]

Ok, it compiled. I walked around a bit, couldn't figure out how to pick things up for a while. An on screen help would be nice. A horse walked into me and pushed me . I tried fighting with someone (AWSD?), but got killed.

It's hard for the player to figure out what to do if they start in an open world. You could add some hints on how to get to the dungeons. Are they just scattered randomly on the map? Maybe you could add some roads?

I will play some more later, it looks like fighting could be really interesting with the kinetic repelling.

Btw, have you tried compiling the game into javascript to run it in the browser?

[koiwai]

miki151: Awesome, thank you for compiling and playing. The game is not really ready for players Starting position varies, usually you start in a village of your faction and it makes life easier, but sometimes your faction gets all exterminated before the game starts, so you appear in a very harsh world. Finding a first weapon can be hard, unless neighboring factions fight and you can pick up weapons from killed mobs. All dungeons are marked on the minimap with a triangle pointing down. Sometimes weapons are just laying on the ground (epecially in dungeons). Also, don't fight with wolfs and other forest monsters (brown faction), they don't drop anything.

Inventory.
How to pick up things: you open the inventory (i), choose an item with arrow keys, then use keys 0, 1, and 2 to move items between three sections (0 = ground, 1 = equipped, 2 = inventory). It's somewhat wierd and counterintuitive, but it was easy to code. Sorry about that )

At the moment the player experience is very raw, there are very few hints. Until other meaty content is in place, I don't really try to make it accessible. Read the controls section in the readme file, it should be helpful.

WASD = melee attack, F = ranged (with F to fire and Esc or Q to cancel)
T = rest for a short time, helps a lot
Space = wait.

Primary parameters
ATL = Athletic skills, your physical strength (for both fighting and movement).
RCT = Reaction (in ~ 0.1 of a second). The smaller the better, for moving and shooting quickly. This is your basic delay, you want it to be small.
CNS = Constitution = your mass in kilograms = you max HP. (For some mobs, their mass and HP can be not the same though).

Secondary
MBL = Mobility, freedom of movement. Determines how well you can use weapons. When overburdened, your fighting abilities degrade.
TMS =  total mass, including your own mass, equipment, stuff in the inventory.

Melee
DMG = roughly, DPS, Damage per second. "Sharpness." (Although, the actual damage also depends on your ATL and enemy's defense)
DUR = duration of one attack.

Ranged
DMG = roughly, DPS. "Sharpness."
FRC = The momentum projectiles get. The higher the better.

Defense
DEF = the probability to absorb physical damage.


About compiling to JS. I did not try to compile for browser. I don't think that programs like js_of_ocaml really can do that, but maybe, if I rewrite the graphics rendering code specifically for that, it should be possible.

[miki151]

I'm still intrigued by your choice of OCaml. I used to use it quite a lot at university, but never took it seriously for bigger projects, especially games. It seems that you are using the functional style a lot, and the code is very compact. I bet that you make far fewer bugs than I do in C++  . I'm actually quite jealous that I didn't consider OCaml when starting my roguelike. The fact that it's an interpreted language, but at the same time can be compiled to a native executable is a huge plus when you start to distribute your game.

[koiwai]

About OCaml.
There is no perfect language to my knowledge. We just stick to those that are least annoying )

Yes, good type checker helps a lot, especially when you are refactoring things, and that's invaluable when designing/programming a game with multiple interconnected systems. OCaml code is compact, there is only 4K lines of code at the moment in this project. The language comes with useful data structures like Hash Tables, Maps, and Sets (in addition to more traditional lists, arrays, and records). This is kind of a no-nonsese language, in my opinion. Libraries are usually high quality, and the signal to noise ratio in the community is high. Although, OCaml users tend to be invisible and not very vocal about the stuff they do, and a bit inclined to academia. Though it is gradually changing with Yaron Minsky and people like him, who bring the language closer to the industry, which is good.

OCaml is a bit restrictive, when you want mutually recursive function calls between different systems. In general, you have to define the function before you can call it. So, the whole program have to be carefully stratified, with clear module dependence. It helps, if basic types are defined early, and the operations on them are defined later, in higher-level modules. But still, you should be careful (Essentially, it boils down to the question: Which game entity is more essential: a Tile, a Unit, an Item, etc. - and how you can make all these different entities be aware of each other).

I don't write extremely functional code here. You rarely can avoid stateful data strucutres in games. So, there are arrays. There are (mutable) hash tables. I avoid using functions as properties of game entities, because the Marshalling module for dumping the gamestate into a file does not really like lambdas in data. So, I have to be conservative in this respect too.

There are both ups and downs. It's easier to program in OCaml than in C, and probably, in C++. But it's harder than in Python or Ruby. I think, you should be reasonably proficient in this language to write good code. I would hesitate to say that it's the best language for programming games, but it's an awesome instrument if you know it. I have been using it for several years, and there were a few game projects that never reached the state of a playable demo.

I'm happy to hear that you know and used the language. Well, I bet, functional programming affects your C++ code too, there are just some good practices that are applicable anywhere.