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

Pages: 1 ... 4 5 [6] 7
7DRLs / Re: horddays (7DRL 2014) - devlog
« on: March 13, 2014, 05:31:13 PM »
- Numpad keys, in addition to hjklyubn.
- Death when HP=0.
- Item consumption and throwing.
- Items: Medkit, Antidote, Rock.
- Show when the player is hit/bitten.
- Score, day(level) count.
- Level difficuly increases with each level.

I did not do a lot last day, but there was some progress.

Plans for the last push are:
- More items (like, grenades, weapons, consumables)
- Better level generation (houses and small obstables)

On Friday, I will do the README, put it on github and things like that. I'm using MinGW for a Windows build - hope it will work fine.

7DRLs / Re: horddays (7DRL 2014) - devlog
« on: March 12, 2014, 02:59:28 PM »
- Better zombie flocking (crowds)
- Fixed a bug in the time system
- Map generation: Connected area, better spawning, and initial location.
- Blue zombies are able to see you
- Items
- Picking up items

7DRLs / Horddays (7DRL 2014 - SUCCESS) - devlog
« on: March 11, 2014, 04:27:54 PM »

For Linux and OSX, source code (C, SDL) at Github (version v0.7d.1).
For Windows, download 32 bit build.

The main goal is to escape from the horde of zombies, using items you can find around. The environment is 3D and resembles urban setting.


Old post:
Out of frustration with all those zombie TV shows, and because Catacysm2 is not yet ready, this is my take on this epic genre of Zombie Apocalypse.

Basic principles:
- Hordes of flocking zombies.
- You are a hoarder, and you are unable to pack your inventory - you cannot get rid of your stuff unless you use it.
- Simplified 3D world.
- Different types of zombies can smell, hear, or see you.
- This stuff can be done using arrays for everything, no fancy data structures, so plain C is just fine ;D

The development history so far:

Late Friday night
- Basic SDL setup.
- Basic structures and game loop.
- Simple random 3D map.
- Simple tileset.
- Walking @!

- Refinig the world.
- Field of view.
- Started programming mobs.
- Priority list for the time system.

- Time System.
- Flocking of the mobs.
- Possibility for non-zombie mobs.
- Killing mobs.
- Blood.
- Smell spreading.
- Sound and smell perception.

- Balancing flocking and sensing.
- HP indicator.
- Zombies hitting the player.
- Exit, levels.
- Better map generation. (World of ramps).
- Shadows.
- Better zombie tiles.


- Map generation: Connected area, better spawning.
- Map generation: Houses and high structures.
- Map generation: Small obstacles.

- Items
- Picking up items
- Show when the player is hit/bitten.
- Effects
- Using items

- Smoke (from grenades, shotgun, etc)
- Wind
- Sight
- Check Windows build
- Better UI
- Even better map generation
- Civilians

Programming / Re: I don't understand random seeds.
« on: March 05, 2014, 07:12:49 PM »
At least in scinetific applications (and probably in crypto-), good PRNG gives you some guarantees about the distribution of the generated sequence of numbers. They also runs quickly. Many simulation techniques (like Gillespie algorithm) use a lot of random numbers, so speed is important.  Hardware sensors, in general, don't give you such guarantees about their data. They can be slow too.

rand() returns the same number several times in a row?

Programming / Re: I don't understand random seeds.
« on: March 05, 2014, 06:19:41 PM »
Say, you are programming a space exploration game, and there must be 10K stars with planets or so. Instead of storing each star system, you store a single integer, the seed, for each of them, and when your ship visits the star system, you generate the system from the seed:
Code: [Select]
star_system = generate();
the seed uniquely determines the state of the PRNG, so every time you visit this star system, the PRNG will generate the same sequence of random numbers, and therefore the generated star system will allways look the same.

Optionally, if you PRNG permits that, you can do the following:
Code: [Select]

state = save_state_of_PRNG();

star_system = generate();


So, the usage of the random seed is limited to the 'generate' function call, and does not affect the subsequent commands.

On the downside, it's better to use seeds for things that cannot be easily changed by player's actions. This is why I gave an example with star systems. But they also can store landscapes, proceduraly generated textures, or things like this.

Off-topic (Locked) / Re: War never changes
« on: March 05, 2014, 01:05:50 AM »
Yes, in that video, Ukranian troops are marching to their airbase. Russian soldiers took over the base, and don't let them in. The Russian soldiers all have their isignia removed, but the uniform is distinctively Russian, there is no doubt about that. Russian media present them as "Crimea self defense forces".

At 0:55, one ukrainian shouts "US with us! the world is with us!" They also say that they did not bring any weapons and want to talk.

How I see the situation:

There are many reasonable people in Russia who see that this is not right (1, 2, 3, 4,  use google translate to translate into your language). They inderstand that Ukraine is an independent country, understand that people of Russia will only get troubles from all this. For example,  in the past, there was a discussion between EU and Russia to cancel visas with Europe for Russians - forget about it. Russia was a respectable political power, and a member of G8 - forget about it.
But, what is funny, Putin's electorate doesn't want to travel to Europe, so they don't care about EU visas, they are pretty simple and gullible people - they can be manipulated into thinking that this incident in Crimea is a demonstration of Putin's and Russia's power. When for the the rest of the world, this is a sign that you cannot deal with Russia, that Russian politicians are irresponsible idiots. Many Ukrainians will hate Russians, not only Putin, they will hate all Russians. Many people in the world will hate us as a nation because of this BS. Why do we do this?!.. Because someone in Kremlin could not install Civ V on his computer? All this can make a long-lasting negative effect on the economics of the country, and its international image. This is just stupid, this is just wrong.

Off-topic (Locked) / Re: War never changes
« on: March 03, 2014, 11:41:26 PM »
"We should let %nationality% people die" is not funny at all.

I think it is, because some countries want war more than others. Russia, Somalia and other underdeveloped countries. Let them kill each other rather than hurt civilized world with whatever they do. We should know better and be wiser than them.

Dude, why don't you cite relevant scientific research on the topic?


Now, your view point is much better supported by actual facts.

Seriously, take your head out of the sand.

Off-topic (Locked) / Re: War never changes
« on: March 02, 2014, 09:01:19 PM »
People don't want a war -- Putin does, he is a bored megalomaniac.

Early Dev / Re: KeeperRL (formerly Zagadka)
« on: February 27, 2014, 05:03:00 PM »
Oh if you're compiling yourself, then add "OPT=true" to make arguments, otherwise it's the debug mode and it's very slow.
You are right, I simply did make without OPT=true. Recompiled - It works fine now  :D

Thank you for the clarification regarding the license.

Quote from: koiwai
Is the library designed to be simply copied in your project directory, and distributed together with the source code of the game (if I make my code open source)?
Not sure I understood you here. The library binary is supposed to be distributed along with an application, but mostly because I do not imagine it in installer form =). The location of sources is up to you.
My question was mostly about packaging BearLibTerminal for Linux: A library can be installed as a separate package (like ncurses or SDL do, for example). Alternatively, I can simply copy BearLibTerminal source code in my source code, and distribute them both as a single piece. One more approach, when building from sources, is to fetch both my code and BearLibTerminal code from their repositories, build together at the user's machene and install the game.

Sorry for compicating things, but when developing an open source game, I want to be sure that a user will be able to build the game without much hassle.

Looks neat. I read the original forum briefly, the library was in development for quite a while. And it looks versatile and crossplatform. The examples with layers resemble Cairo documentation, btw. I tried to compile the source code on my 64bit Linux, and it failed at libfreetype2. (Unless I did something wrong with cmake)
Code: [Select]
/usr/bin/ld: ../Dependencies/FreeType/libfreetype2-minimal-static.a(ftbase.c.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
../Dependencies/FreeType/libfreetype2-minimal-static.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Terminal/CMakeFiles/BearLibTerminal.dir/build.make:790: recipe for target 'Output/' failed
make[2]: *** [Output/] Error 1
CMakeFiles/Makefile2:128: recipe for target 'Terminal/CMakeFiles/BearLibTerminal.dir/all' failed
make[1]: *** [Terminal/CMakeFiles/BearLibTerminal.dir/all] Error 2
Makefile:75: recipe for target 'all' failed

But it seems that FreeType2 is available for my distribution, and most likely for other distributions too. Maybe, I can use my native library to build BeaR on a 64bit system?

Another question. Is the library designed to be simply copied in your project directory, and distributed together with the source code of the game (if I make my code open source)?

Also, I suppose that the library is distributed under some unspecified free / open source conditions, right?  ;D I did not find anything specific about the license, but it's good to have one.

Early Dev / Re: Wanderers / open world RL
« on: February 27, 2014, 03:26:00 AM »
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.  :) 

Early Dev / Re: KeeperRL (formerly Zagadka)
« on: February 27, 2014, 12:54:17 AM »
I played the Keeper mode. I liked the game. I won on hard once, then tried to repeat the build to make screenshots and died in the end (one enemy swordsman was too strong, he is right here at my front door in the screenshot)

My impressions after playing.
You always have choices: what to build first, how to spend mana (learning vs monster spawning). This is great. Unlike DF, where I was always building basically the same fortress with minor variations, here I have to choose what's the next thing to do (taking into account available resources, your minions, and what is already built). It would be great if the map could force you to make certain decisions. (Say, there is a human cemetary nearby, and you benefit from going into Necromancy early on).

I notice that I delay building the Library, first building the lobby, then the storage room, and only then the library. Probably, it costs me later on.

The game flow is very natural and intuitive. You gain resources, knowledge, minions. The development if the dungeon is smooth. Other things are balanced well too. I was usually going for golems (a few stone, a lot of iron, then lava in the late game), and necro (mummies, and later vampires, when I played second time). To support my army, I had ~ 4-5 gnomes and goblins (They both work at the laboratories and the workshops, right?). Golems cannot pick up items when controlled directly, but humanoids can.

I neglected the spellcasting branch. But I was spawning flies frequently to distract enemies from my real army. You can make a lot of flies, and they seem to be useful.

Sending minions to kill civilians and animals is fun, even a single vampire can do a lot, if there is no military units (when the the village is defeated it seems to be the case). The raven is good early in the game to quickly explore the map at ~0 cost.

It seems that for building the dungeon, you need a fixed amount of resources, so you don't really need more than you are given. It would be fun to make a map with more than one mountain. So, you could conquer a nearby village and move to a better and bigger mountain. All games unfold according to the same scenario. Some, even minor, variability will make the game more fun. Random events, maybe. It can be interesting to generate maps that dictate certain decisions and events (for both, the player and AI).

Controlling a group of units is not very convenient. When you return to the Keeper-mode, you cannot select the same group easily. You cannot control two groups. (You can use yellow flags, but it's not the same). Anyway, this is a minor issue. Also, in the unit-controlling mode, movement is a bit sluggish. Probably it's unavoidable, all the mobs must do their moves, but this delay is not a great thing. Maybe, you can try to do some "shortcuts", for example, doing expensive computation like the Field of sight of the mobs not at every turn, but once in a while, especially for those mobs that are far from your minions and are not fighting. For melee fighters, when they are in combat, their perception radius also can be reduced. Some "shortcuts" with pathfinding also, probably, can be done. Not sure if anything of the above is applicable, but just my two cents. Maybe, you find it useful.

Hints at the bottom help a lot. I could understand the game without reading anything. (I don't enjoy reading readmes). I still don't see the purpose of the treasury room though. For buying stuff? For sidetracking greedy heroes? Also, if I want to read about the types of minions (what's the difference between a mummy and a vampire?), where can I do that? Do they have special abilities?

Overall, KeeperRL is a very fun and well-balanced game. Definitely worth playing. Very enjoyable, though sometimes seems to be too fast for my taste. There is an obvious potential for becoming even better. If I can suggest some ideas for the future development, IMHO, the game can benefit from additional random events and map features that affect your strategic decisions (and AI's decisions as well).

Early Dev / Re: Wanderers / open world RL
« on: February 26, 2014, 07:01:57 AM »
miki151: Awesome, thank you for compiling and playing. The game is not really ready for players ;D 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.


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).

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.

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.

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

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.

Early Dev / Re: Wanderers / open world RL
« on: February 26, 2014, 04:49:00 AM »
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 "" and "", and did not notice anything problemmatic, but there is no guarantees  :)

Pages: 1 ... 4 5 [6] 7