ID:265496
 
For Nadold, I'm trying to think of a way to make houses a half-way decent size. I'm thinking of making the house a 20x20 square, well, ~15x15 when all the walls are added. Houses would be used to salt and store meat, store food, or just put your belongings in. Or, for that matter, to relax/sleep in. Every house would have the same frame, but whatever you put in it, only you can move/modify.

Sound good?
Where are the houses being located? (In another z-level with the same dimensions as the main map?)
In response to IainPeregrine
I'll be using swapmaps, so size really isn't a problem. :|
In response to Hell Ramen
Swapmaps, eh? Just had to one-up me, eh? :P

The system sounds fine, I look forward to seeing it.
In response to Hell Ramen
Are you loading chunks onto a big map, or are you using many small maps?
Yar, give players a choice of what their house will be like. Maybe 4 different designs.
In response to Elation
Elation wrote:
Yar, give players a choice of what their house will be like. Maybe 4 different designs.

Let them design it themselves! They can place walls, and floors, and everything as they see fit, and have money for.
In response to IainPeregrine
Generally, for this kind of thing, I home-brew a system. Back a long time ago, early in 2005, I started a project with some friends called Redwood Falls, a game inspired by Hedgerow Hall.

I used this completely innovated burrow system using datums and a .dmp dump library I wrote a LONG, LONG time ago. Then, I made an option at run-time to use either swapmaps OR my system. Swapmaps ran almost twice as slow.

Why? Because I made my system only save turfs that had changed since the last time the file was saved. Plus, my files were about half the size of a normal swapmaps savefile. Why? Again, I made it ONLY save the type value of CERTAIN turfs in the burrow (only the ones that the player had actually modified, and had not caved back in), and then save the objects individually. The burrow walls were once again re-generated at load time. All-in-all, I saved my computer about 256KB per file, and about 5s or so of lag.


Alright, now I know it sounds like I'm tooting my own horn here, but I do have a point, and I'm getting to it.

I'll quote Lexy when I say: "I'm notoriously anti-library.". Libraries are not built FOR YOUR GAME, therefore, they will RARELY be the 100% perfect fit for your game. Often, they will not be nearly as streamlined as a well-written system for your game, and your game alone.

I suggest handwriting a .dmp dump utility so you can edit houses on the fly, and then creating your own saving system, only saving the things you know you need to save.

Alas, it's your decision, enjoy!

(And I suggest programming a building system with rules and such. For instance, depending on the foundation, the house can be x floors, and depending upon the foundation, the type of roof, and the number of floors, support beams can be x number of tiles away:

no foundation:
1 story house, any material, supports every 3 tiles.

stone basement:
1 story house, any material, supports every 5 tiles.
2 story house, any material, supports every 3 tiles.

Concrete foundation:
1 story house, any material, supports every 9 tiles.
2 story house, any material, supports every 5 tiles.
3 story house, any but stone, supports every 5 tiles.
3 story house, stone, supports every 3 tiles.

You get the pattern.

Anyway, Ter13 ~Out
In response to Ter13
Well, I'm mostly anti-library too, the only libraries I use are the ones that input in easy functions (most of AbyssDragon (nick.cash, I think)'s libraries).

I was thinking of creating an easy save system for the maps, but that's if I don't make it a tad bit complicated...
In response to Hell Ramen
Hell Ramen wrote:
Well, I'm mostly anti-library too, the only libraries I use are the ones that input in easy functions (most of AbyssDragon (nick.cash, I think)'s libraries).

Why reinvent the wheel when you have a perfectly good wheel in front of you? Libraries are great things. Sometimes though, with libraries such as SwapMaps, the library provides general support for pretty much everything where a certain game would only need a small subset of the features it provides.
In response to Jon88
Another problem with libraries is when the writter defines all the library's functions, variables, and objects directly under the root node. This results in your object tree being to cluttered to be of much use. I use Deadron.XML, but because of this problem I don't include the library until I absolutely have to.

Instead, I much prefere to have everything defined under a custom object type. For instance, I could have defined my load_map() proc (and it's support procs) directly under the root node, yet defined it under /dmp_reader instead. If included in a project, the nodes under /dmp_reader are still accessable, yet they don't clutter the object tree.

[Edit: Not that my little bit of code is more functional, or 'better,' than Deadron's... by no means. It's just conveniently placed under a custom node.]
In response to IainPeregrine
Agreed; datums are the way to go when making custom systems. If you can make a datum handle everything for you, then you are set.

In most games, I even make combat handling datums, a statistic datum, and AI package datums, so that I can attach an AI package to an NPC that is essentially the same type as the player. Using different datums for the same player type extends the functionality of the game. ALl I do is loop the Client movement controls into a special AI package called "controlled", and I can then attach it to the player, and allow him to control himself. This also makes it exceptionally easy to take control of NPCs from a GM or Administrative standpoint. Let's say you want to move a shopkeeper out of the way for a few minutes, you can quickly and quietly walk him into the back room, and then revert back to your mob.

Or, you can even swap control with another person's player with extreme ease.