Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[dreadmullet]

Kerbal Multiplayer solves this problem in an interesting way. Maybe it's not completely relevant, but it's interesting anyways. Anyone can adjust their own time warp at any time, and it just works. Check it out:

The big problem that immediately comes up when allowing players to use warp whenever they want to is that forcing everyone to go into warp is unpractical, and otherwise your local copy of the solar system wouldn't be synchronized with other players (so the planets and moons would be in very different positions relative to each other for different players). KMP gets around this by allowing players to play in multiple timeframes (or "subspaces") simultaneously. You can sync with any player that's "in the future" relative to you whenever it's convenient.

That sounds complicated. Is it complicated?
For gameplay purposes, at least, it's actually really simple! Need to go to warp for a few years to position that shiny new Jool probe? Go ahead! Want to build a new space station with your buddy afterward? Just sync up and you're good to go. That's it.

What happens when I'm not in sync with someone else?
You'll still be able to see those players and what they're doing in-game--you can chat, send screenshots, share designs, etc, but you won't be able to interact with any in-game vessels that those players control. Vessels from the past or future turn translucent so that you know that you won't be able to affect them. If the other player is in the past, KMP tries to predict where they'll be in the future and shows their ship at that location. Keep in mind, though, that since the ship is still being manipulated in the past, the predicted future location can rapidly change. If another ship has been manipulated in the future, you're effectively just watching a recording of events that have "already happened" play out.

[Tardigrade]

I've been meaning to learn Python for a while so finally bit the bullet and am currently working through the libtcod tutorials on RogueBasin. Once I finish the tutorial I'm planning to start playing around with some basic crafting and construction, and it's got me thinking more about how DF works under the hood. Is there some obvious reason why constructions and buildings should be defined separately that I am missing, or is a construction simply a building that doesn't have an interaction option?

I know this might not seem like the best place to ask this, but I am asking to help me understand how best to add constructions and buildings to my planned roguelike. If anyone knows of a roguelike written in Python with crafting or construction implemented and with source code available, I'd also really like to know about it.

[Retropunch]

I've been meaning to learn Python for a while so finally bit the bullet and am currently working through the libtcod tutorials on RogueBasin. Once I finish the tutorial I'm planning to start playing around with some basic crafting and construction, and it's got me thinking more about how DF works under the hood. Is there some obvious reason why constructions and buildings should be defined separately that I am missing, or is a construction simply a building that doesn't have an interaction option?

I know this might not seem like the best place to ask this, but I am asking to help me understand how best to add constructions and buildings to my planned roguelike. If anyone knows of a roguelike written in Python with crafting or construction implemented and with source code available, I'd also really like to know about it.

To be brutally honest, I don't think DF is the place to look for guidance on interface/mechanics. Whilst DF is a technical marvel (and generally fantastic) a lot of the systems have been cobbled together over time and are buggy/wonky/counter-intuitive.

I'm unsure what you want to do really though. I mean in terms of planning you just want to create the best, most common-sense hierarchy of classes and sub-classes that you can really.

[Anvilfolk]

It's probably overkill for a first project, but word on the game development community is that you shouldn't use OOP design, but instead entity-systems or component-based design. Just thought I'd mention that!

I don't really know how to answer your question, but your guess seems to be pretty good. Constructions probably have less functionality.

[Antsan]

It's probably overkill for a first project, but word on the game development community is that you shouldn't use OOP design, but instead entity-systems or component-based design. Just thought I'd mention that!

iirc the roguelike tutorial for python/libtcod already uses entity systems, although I don't remember them being named that. It's something that already is in python's way of doing OOP.

[Tardigrade]

To be brutally honest, I don't think DF is the place to look for guidance on interface/mechanics. Whilst DF is a technical marvel (and generally fantastic) a lot of the systems have been cobbled together over time and are buggy/wonky/counter-intuitive.

I agree entirely; in my opinion DF is easily the most innovative computer game of the last decade but nothing is perfect. I'm not planning to copy DF, but I think it's fair to say there are only a limited number of ways to implement crafting/construction systems in a roguelike, and since this forum is full of mostly helpful people with great ideas who have collectively spent a few hundred thousand game-hours using this one I thought this would be a good place to ask for insights into what works and what doesn't rather than learn entirely by trial and error. 

It's probably overkill for a first project, but word on the game development community is that you shouldn't use OOP design, but instead entity-systems or component-based design. Just thought I'd mention that!

iirc the roguelike tutorial for python/libtcod already uses entity systems, although I don't remember them being named that. It's something that already is in python's way of doing OOP.

Thanks for the advice! The tutorial does use composition rather than inheritance, if that's what you mean (I'm not a computer scientist so there may be a further distinction there that's going over my head). It's an excellent tutorial series in my opinion, although it uses global variables more than I'd normally like to. It takes you just far enough to generate something you can be proud of but with plenty of directions to go.

[Anvilfolk]

I quickly looked at a tutorial for Python and libtcod that I googled and it didn't seem to. Can you link the tutorial that you are talking about?

[EnigmaticHat]

I've been meaning to learn Python for a while so finally bit the bullet and am currently working through the libtcod tutorials on RogueBasin. Once I finish the tutorial I'm planning to start playing around with some basic crafting and construction, and it's got me thinking more about how DF works under the hood. Is there some obvious reason why constructions and buildings should be defined separately that I am missing, or is a construction simply a building that doesn't have an interaction option?

In DF the reason is that constructions are functionally part of the terrain, while buildings are off doing their own thing.  So a constructed stone floor is dealt with by the same systems that affect a natural stone floor, while a door is handled by other systems.  Buildings are not allowed overlap with each other, so having constructed floors be buildings would be a problem.  Obviously that's just how DF does it though, you could handle it however you want.

[Tardigrade]

I quickly looked at a tutorial for Python and libtcod that I googled and it didn't seem to. Can you link the tutorial that you are talking about?

It's probably the tutorial you found, but it doesn't mention composition until Part 6:
http://www.roguebasin.com/index.php?title=Complete_Roguelike_Tutorial,_using_python%2Blibtcod,_part_6#The_components
As I said above though, I'm still not entirely sure whether using component classes is enough to make it an entity/component system.

In DF the reason is that constructions are functionally part of the terrain, while buildings are off doing their own thing.  So a constructed stone floor is dealt with by the same systems that affect a natural stone floor, while a door is handled by other systems.  Buildings are not allowed overlap with each other, so having constructed floors be buildings would be a problem.  Obviously that's just how DF does it though, you could handle it however you want.

The no-overlap rule is a very good point; that hadn't occurred to me. I suppose since placement is also blocked on impassable tiles (walls etc) anyway, you could devise a system without the explicit no-overlap rule that would allow buildings to overlap as long as the impassable tiles themselves didn't overlap. This would let you build on constructed floors, install a chair in your workshop, or superimpose two workshops with complementary footprints. I may see if that would work in practice.

I have a long way to go before that, though. Today I am adding a magic item vending machine to my dungeon

[EnigmaticHat]

So does anyone know the conditions which cause windows to decide a program is not responding?  I'm attempting to make a rougelike(-like?  its hard to tell at this point) where you control multiple characters and this involves a long enemy turn.  During this turn, windows frequently switches to greyed out "(Not Responding)" mode, even though the program is still very much working.

[Skyrunner]

I'm not sure of the specifics, but I think that programs regularly respond to a Windows system query which is done in the main thread. If you want it to not freeze, you need to use multithreading and put the long turn into a separate thread.

[EnigmaticHat]

That was the problem, thanks.

[Xgamer4]

So I've decided to jump back into roguelike development by attempting to develop a My Little Pony themed roguelike (not that I'm at the point where theme has any real affect on what I could show). I jumped over to libtcod from PyGame this time around (I just wanted a console that mostly just works - I didn't want to deal with partitioning sprite sheets, or mapping blocks of pixels to sheet size, or the other little tiny things that individually aren't too bad, but altogether are just kinda a pain), too. 

I've been working on getting a level/map set up and working. After the requisite hardcoded maps to get things like field of view and movement working, I decided to have the generation just go through each tile and place a tree 50% of the time.

It's really impressive just how nice a simple algorithm like "place a tree 50% of the time" looks. Though this probably wouldn't work so well for dungeon walls, or other things we expect to have order.

(Note: map size is just this small for testing)

[alexandertnt]

It's really impressive just how nice a simple algorithm like "place a tree 50% of the time" looks.

The KISS principle is something that is all to undervalued in the world of programming.

[EnigmaticHat]

The only problem with that is the potential for unwinnable situations.