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 2 3 [4] 5 6 7
46
Traditional Roguelikes (Turn-based) / Re: Anyone playing Wayward?
« on: September 02, 2014, 02:57:45 AM »
Vaughn: Wayward was very addicting when I played it ~ 2(?) years ago. I got bored eventually, but it was fun nevertheless. At the time, I remember a friend of mine calling me asking "How to make a campfire?" I was scared for a moment, thinking that she is going to make a campfire in her own apartment.. No, she was playing Wayward.
Maybe, it's time to try the game again  :D

47
Programming / Re: Slow progress is slow.
« on: September 02, 2014, 02:40:44 AM »
The design sounds great. The rogue class seems to be the hardest, all special/hidden objects must be put on the map in a meaningful way, and balancing may be tricky. However, in principle, even "normal" characters may eventually benefit from such special objects, if, for example, a melee or magic character trains some simple rogue skills too.

I agree that making a playable demo is a good thing. Even if not many people actually play it, there may be some meaningful discussion, the project gets potential players, and it is also an additional motivation for the developer. On the negative side, people may try a half-made game and never actually return to play the final version ;D Or, I don't know, the story should not be released too early, but then again, a limited demo does not have to be a complete game. Anyway, good luck with your project.

48
Programming / Re: Slow progress is slow.
« on: August 31, 2014, 09:15:46 PM »
My programming habbits are quite similar, with long periods of doing seemingly nothing, thinking about the game systems and how they should interact. However, no matter how enjoyable this process might be, finishing and releasing something is also very important.
My first relatively successful game was Curse of War - a rather simple project actually, but I was lucky to get some attention from the Linux community, and some nice people joined to help me make the game better. I've got a good (and maybe surprizing) lesson that even a simple project like that takes quite a lot of extra work after the main programming work is done.

Let me share my thoughts on how to speed up super-projects (if it is possible at all  ;D):

1) Start with the most important core game mechanics. They must be fun to play, and they should work really really well. Everything what makes the "meat" of the game (e.g. Combat(!), Skills?, Generated contents) must be there as soon as possible. (This is probably my main criticism to URR: while it is an admirable game/art project, and I agree with the author on many things, it is still not clear to me, will it eventually become a game or not; I wish he succeedes).

2) The engine should not be more complex than is necessary to implement those core features. Of course, it must be flexible enough to permit adding new functionality, but if it is an order of magnitude more complex than the game, I should switch to programming the game itself. (And, btw, game engines as separate projects are no good by themselves, unless they have a dedicated group of people who are using them for making actual games)

3) Try to find game mechanics that can be easily and efficiently implemented! Probably, it does not sound like very fun, but it may actually turn out to be a great improvement to your game. On the other hand, struggling to implement some dream design feature may become a reason to detest and eventually abandon the project.

4A) The game contents should not hamper the way the game is implemented. I try to generalize the game, and factor out specific details. It takes time to do it right, but at least you would not get stuck at a later stage with some unmaintainnable structure.

4B) On the other hand, avoid unnecessary layers of abstraction. All game components must serve some purpose. OO code tends to look funny, with infamous god classes, and everything is an object kind of thing. As John Carmack said: "Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function."

5) Essentially, I think, it is important to make the game grow steadily. When all components are developed simultaneously. Then, you have many things to work on, so you are not getting bored (I remember Dwarf Fortress developers were saying something like that), and you find bad design decisions early on, when you still can change them.

There is nothing new, but I think, it still may be interesting to those people who want to program something big.

49
Early Dev / Re: Wanderers / open world RL
« on: August 26, 2014, 02:39:46 AM »
Techbear, thanks!

Updates:

1. Now, all dungeons are not simple vertical shafts, but a complex interconnected network. See the screens below, the minimap on the left shows the layout of your current level z=-2



2. Player's Inventory is hidden to save the screen space:

(a) Hidden:             (b) Visible:
 

3. Graphics code is significantly improved. It is much easier now to change the window size. Currently, it is set to 854x480, which is one of the standard Youtube resolutions. I plan a config file, where these and other parameters can be adjusted.

4. An alternative tileset variant inspired by ADOM.

 

I am going to keep both the flat tileset, and the "3D-ish" one. It should only affect walls, doors, and maybe some other obstacles, but the majority of the things is still the same

5. An experimental fog effect on unexplored tiles.

It can be black or white, or any other color:
 

The fog can be animated, Youtube video:



Also, notice that if you watch it in 480p quality, all pixels are crisp and look good, this is because the window dimensions match one of the Youtube defaults. I don't like this resolution too much, it's a little too small for playing comfortably, but for recording lets plays it must be one of the best possible. Not that I'm recording LPs myself, but it makes sense to make the game youtube-friendly :)

50
Early Dev / Re: The Temple of Torment
« on: August 02, 2014, 08:09:07 AM »
Nice work! Have you tried to show tiles scaled up 200%? I did not play the game, but just from looking at the screenshots, small tiles look somewhat noisy visually, because they are very detailed. In x2 zoom, they are more pleasant, in my opinion http://i.imgur.com/3kY5bM0.png . Also, by the way, your graphics is pretty good (is it original?), but it is hard to fully appreciate it when the tiles are small. A similar sentiment was expressed by DCSS artist John Attea regarding Stone Soup: http://johnattea.blogspot.com/2012/08/looking-back-on-dungeon-crawl-stone-soup.html

Edit: A simplified (Infra Arcana-like) graphics style is another way to reduce visual noise. (If it is necessary, or course, it all depend on how exactly the game plays, and many other things...)

51
Programming / Re: DRAWILLE, a python library to paint in console
« on: July 27, 2014, 11:37:17 PM »
This is neat. I think, it is good for drawing things like laser beams or maybe other temporary effects in otherwise ASCII games.

52
Early Dev / Re: Wanderers / open world RL
« on: July 19, 2014, 06:02:56 AM »
I had some trouble with adding money and merchants to the world. I could not decide, should they be just an item in an inventory slot, or deserve some special treatment. So, finally decided to postpone this feature altogether, and add other things.

Better map generation

I made nice automated dungeon generation module, which constructs a random map from a short specification like this:
Code: [Select]
@joint ,+/%$
@door  ,+
@floor .,

@gen / = ,#
@gen % = +#
@gen $ = +,

@b ,+ = #

##/##
#...#
/...$
#...#
##/##

#####
,...,
#####

#####
,...,
#...#
##$##

#######
#.....#
#$###$#

You basically tell the program:
  • what are possible building blocks
  • what tiles are the joints (the places at which two blocks can be joined)
  • rules for merging tiles
  • tile randomization
  • some post-processing



A few more examples (for other specifications):




This map generation module builds all dungeons now. It also builds houses in settlements.



I'm going to make a library or a command line tool that uses this generator, so everyone, if they will, should be able to use it for their projects. In fact, I already have a command line tool now, it is used to make those ascii screenshots. But I want to do it right, and it should works for all platforms. Maybe, it even worth rewriting the thing in C, I'm a bit uncertain about it.


Weapons and materials

Added two alternative metals: Rusty steel, and high-quality (~Damascus) steel. Example with three daggers:



My current set of weapons (some of them, like polearms, are not in the game yet)



The oversized ones are way too heavy for normal people. If you wield them, the unit would be slowed down a lot. And they are very expensive too, so practically, they never really drop. Probably, they are waiting for giants, super-light alloys, mlthril or something like that  ;D

By the way, there is a great source of information about swords: https://www.youtube.com/user/scholagladiatoria/videos  (Matt Easton)

Mobs' strength markings

Since mobs wield weapons, to quickly see who are dangerous, I added markings:
2 yellow dots - they are between x0.25 and x1, compared to your strength approximately,
3 orange dots - between x1 and x4 - they are likely to be stronger than you,
4 red dots - more than x4 stronger than you - real danger.


I think, I should add real doors, finally. Maybe, chests with stuff, and yeah, money. Because not only the player, but also several hundreds of NPC-heroes also should participate in trading, money should be implemented efficiently.

53
A JavaScript adventure game you play by modifying its source
http://alex.nisnevich.com/untrusted/
mirror: http://alexnisnevich.github.io/untrusted/

Apparently, it's using rot.js for generating levels.

54
Programming / Re: Multiplayer roguelike implentation through MySQL???
« on: March 31, 2014, 11:11:20 PM »
You can start with a 2-player game. When one player starts a server, and another one connects to the server. TCP/IP probably makes more sense than UDP, becase it should not be a very time-sensitive real time game.

Some links on network programming:
http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html
http://gafferongames.com/networking-for-game-programmers/

I think, last year, there was a multiplayer 7DRL - you should try to run it. It should be a relatively small program, and hopefully understandable.

Why I think that a 2-player game is better that an MMO? Because once you have the networking code ready (= once you can send messages between two computers), you will be able to actually implement a simple game to work on a functional time system for n>1 players. Which should be quite non-trivial to design. (?)

Eventually, if your code is general enough, you will be able to extend the game to support more than two players, with login/logout, and other MMO functionality. But don't try to do this until you have basic mechanics implemented. Make the core mechanics first, make sure that you can handle a simple game for you and your friend to kill monsters together. Then, try to think big.

Update: And forget about the database for now. First, make a generic roguelike, where you kill goblins, for two (or maybe more) players. And make it so that at least one or both players can connect to the game from another computer via internet.

55
Oh, I played that version with the wrong skills, probably )

Anyway, I think, you found a very good balance of the original game mechanics, depth, and style. Optimally balanced for a 7DRL, in the sense that you really did the right things, and did not waste time. It really feels like a complete game.

GH just have reviewed the game, so I had some time to think more about it. Maybe I should give it another try, considering that I did not play with the right initial hexes.

 

56
7DRLs / Re: Horddays (7DRL 2014 - SUCCESS) - devlog
« on: March 29, 2014, 08:36:11 PM »
More updates in the dev branch
Download this updated version: Win32 build.

The main goal was to make zombies' three senses work better, make good smoke and smell propagation, add new items. I think, the game is more difficult now.

Changelog:
* The Cannibal Corpse loudspeaker is a placable item.
* Added shotguns.
* Added smoke grenades.
* Item names are shown.
* More versatile level generation.
* Zombie spawning rates are randomized for each level.
* Smell and smoke are more realistic - walls act as barriers
* Fixed a bug for choosing zombies' direction to move
* Balancing rates



Plans for the future:
  • Message log as was suggested in the review.
  • Full 3D environment - most of the code supports it.
  • Zombie leaders.
  • Character development?
  • FTL-like next level selection graph (+ better and more realistic maps)
  • Parkour skills.
  • Food and other supplies to survive between levels?
  • Sound and music?

57
Design / Re: Usefulness of general math parser in your roguelike.
« on: March 24, 2014, 05:28:20 AM »
Awesome. Did not know that Wesnoth does something like that, but I played it ~ 3-5 years ago, and they could change the game quite a lot since then. Maybe, I should give it a try again.

58
7DRLs / Re: My first year: Find Yer Treasure! (7DRL 2014 - Success!)
« on: March 24, 2014, 01:45:28 AM »
Hi Eponick, can you describe what the potions do? Except for the healing potion and the warp potion, which are pretty obvious.
Also, I could not figure out what the Levels give you. Do you get extra HP or extra speed?

Also, I wish there was a way to drop bad potions, becuase without that, the inventory gets filled with things like dumbing potions pretty quickly. I don't want to drink them, but I have to.

59
Design / Re: Usefulness of general math parser in your roguelike.
« on: March 24, 2014, 01:35:53 AM »
When using formulas like this, you should really tell the player what the damage is going to be. The dice roll expressions (NdM), although, imho, unnatural for computer games, are still pretty good at conveying this information to the players.

Not sure is it a problem for you or not, but if I had such complex airthmetic expressions for damage, I would do the following: for each weapon, show the histogram (the distribution) of the damage, something like this:
Code: [Select]
    # #
  # # # # # 
# # # # # # # # #
1 2 3 4 5 6 7 8 9
Then, no matter how complex the computed expression is, the player can visually see the odds.
And the histogram can be sampled once from ~100-1000 trials, you don't really need to derive the formula for it. (Unless you do some wierd distributions like the one suggested by Hi, but you can really stick to the good-behaving ones)

Hi: Do you mean the Cauchy distribution?

60
7DRLs / Re: Horddays (7DRL 2014 - SUCCESS) - devlog
« on: March 22, 2014, 05:09:52 AM »
Updates in the dev branch on github:

* Smoke now blocks player's and zombies' vision.
* Added wind - smell and smoke are carried away (+ a UI wind indicator).
* Item generation rates are changed.
* Reduced sound perception rates.

Once I implement more stuff, I'll make a windows build again.

The master branch remains unchanged until the end of the reviewing period.

Pages: 1 2 3 [4] 5 6 7