Print

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

In the form of a MU* (as has already been tried)

4 (4.3%)

Empire building browser-based game, using the Frost and Flame engine or making it from scratch

10 (10.9%)

Adventure RPG browser-based game, using the Dragon Knights engine or making it from scratch

4 (4.3%)

A dungone crawler or maybe cooperative fortress builder client-based game using the Eclipse engine (would be real time, and have better graphics than browser-based games)

25 (27.2%)

Cooperative fortress building browser-based game, with traditional DF top-view 2D tiles

45 (48.9%)

a deviant of the cooperative fortress building browser-based game, were the tiles are grouped into bigger "sections"

3 (3.3%)

Other (propose it in the thread please)

1 (1.1%)

Total Members Voted: 92

[Poltifar]

Ok, I've been brainstorming some more, here's some more coding ideas for the game:

Each map, or node if we go with Vactor's proposal, is stored as seperate database tables. That way, people can develop their own maps and upload them, and we can try out stuff like map generators and other such stuff withough directly affecting the whole game, thus ensuring that if we make a mistake, it is much more contained.

Each map would probably have more than one table, one for the tiles, one for the creatures, and one for the items (basically each set of tables would be a sort of self-contained world). The tiles table would have ALL the tiles listed (yes, they would be BIG tables ), with each tile having not 1 ID, but 2, representing its location in XY, thus ensuring that we do not waste space and code to define both a tile ID and location. (ounce Z levels are in, we can either have 3 ID X Y and Z, or we can have each Z level act as a seperate 'layer', depending on what we do up to then). For the creatures and items tables, it will be a bit harder, since we need to have a unique ID for each creature and object across all maps, for when they move from map to map. Maybe we have that the ID is composed of 2 parts, something like 1953.003, with the second part being defined by the specific map the object or creature is created/first appears in (this would meen that each map would be given a specific ID too.)

This leads to a question I'm sure will seem VERY stupid: how do we define new IDs to creatures and objects that are newly created, while being sure this ID is truly unique and has never been used before? Do we keep a counter to count to which ID we reached, or do we check which IDs are not used every time a new object or creature appears and assign an unused ID to it?

[AltF8]

This leads to a question I'm sure will seem VERY stupid: how do we define new IDs to creatures and objects that are newly created, while being sure this ID is truly unique and has never been used before? Do we keep a counter to count to which ID we reached, or do we check which IDs are not used every time a new object or creature appears and assign an unused ID to it?

MS-SQL identity field or MySql auto-increment field.

[webadict]

Checking for open IDs seems like a waste when you'd only need to store the last ID used and use the next one. But it depends on how long you can play before you run out of numbers. Probably forever? I've not a clue. It just sounds less time consuming than searching for an open number, but that searching might be easier later on...

Now, it seems we're all over the map on this idea. Obviously, we have a BBMORPG. It deals with making a fortress.

Questions:
1. How do you make a fortress?
    1a. What do you need?
    1b. How do you leave a fortress?
         1bi. What happens when a fortress is abandoned or everyone inside dies?
         1bii. Can you find abandoned fortresses and settle in them?
2. How do you join a fortress?
    2a. Can you stop people from joining your fortress?
    2b. Can people sneak in and steal?
3. Do you travel on a map to other fortresses?
    3a. What map is that?
    3b. If you do not travel on a map, would you go there through a drop down list?
4. How do animals work?
5. How do sieges work?
6. How does trading work?
    6a. Can you trade with other players?
7. How do items work?
8. Can you make alliances?

Anything else?

[Poltifar]

There are probably alot more stuff to add, mostly sub-sub-sub categories inside the ones you already proposed, but let's start with these basics. For 1b and its subcategories, I think its simply that the map is saved as it is, wether there are any players on it left or not. So if everyone leaves/dies, anyone else that finds this fortress can just pick up from were the others left. Maybe there could be some item spreading and mixing, if there passed a certain X amount of time since there last was a player on this map...

Some of the answers I propose to some of the questions:

2a. Well people can't enter your fortress 'legally' if the dwarves inside the fortress are hostile to him/don't wish to let him enter, but he could linger outside or enter forcibly, which can lead to:

2b. Sneaking wil probably be implemented. Stealing is a more delicate matter, to account for game balance and such. Probably like Vactor proposed, it should be possible to only steal one item, or a certain amount/weight depending on certain skills... but we would have to give 'ownership' tags to items to determine which are the fortress's property. As for hostility to the thief, I think the game would allow you to be hostile wether a certain dwarf steals or not (imagine a 'no tresspasser' fortress kind of thing), so stealing wouldn't affect your ability to be attcked, other than labeling you as a thief.

Most other things are still hazy to me, except:
6a. I'm not sure how trading will work, but we can definitely trade with other players. Be warned, though, that 'trading' would rely on trust and intimidation, since you could scam or take items by force or steal or not pay the player for the item... basically, this game will be almost 100% free pvp (any objections? if yes, we can find a way to make it less hostile)

[Hawkfrost]

Wow, lots of posts!

And ASP sounds fine, I just wasn't sure what it was.
I know a bit of Basic, and I already downloaded most of the Expresses.

That node adea sounds perfect, along with the thief/stealing.
And members in a fortress together should not be able to fight unless they both set each other to "Grudge" in my oppinion.

[Istrian]

I would suggest avoiding trying to add everything to the first working version of the game. At first we should probably do only one fortress and no global map, no overland movement.

Most of what I say next is only my suggestions for the first version of the game.

New players spawn on the central tile of the map (later, when implemented, they would be able to choose to spawn on a 'gate' area, or a 'meeting' area). They are considered citizens of the fortress as soon as they spawn.

Players can leave the map either by dying (making death permanent would ensure avoiding overpopulation and overskilled dwarves, as well as homicidal ones) or by walking off the area, which has the same consequences as death : the character is destroyed.

When a player is disconnected his dwarf sleeps, hence the need to find/make a safe place to rest before going to sleep. Of course other players can pick up the sleeping dwarf and carry him to a safe place.

As for AI, I would suggest going for a very low AI and then only for wild animals (no pets yet). Siegers would be controlled by the devs.

No legal system in place at first, except a common vote to ban a player from the fortress (forbidding him to take anything tagged as belonging to the fortress). Of course the game would keep track of the value of items produced by a player and the value of items taken by him, and those would be available publicly on a signpost somewhere on the map.

--

As for my skills : PHP/HTML, Java, C, C++

[qwertyuiopas]

Now, heres the problems, if it is tile-based like DF:
HTML/PHP: Building on top of a player that has been inactively leaving the window open for half of an hour will be a problem when the player next moves.

FLASH/JAVA: MUCH more network activity/bandwidth and much more complicated to get the first version up(requires network code and a full interpretation system)



But if it is abstracted to "areas" that say "here lies these buildings, these items, and these dwarves", you would lose some of the greater possibilities and features that could be imported from DF.



So, yeah, problems in every direction, but on the other hand, every way is possible.

[Istrian]

Now, heres the problems, if it is tile-based like DF:
HTML/PHP: Building on top of a player that has been inactively leaving the window open for half of an hour will be a problem when the player next moves.

Then we'll have to give the players the ability to (non-damagingly) push a dwarf off a square.

[Poltifar]

Yes Istrian, we should only have one map at first. I just got a bit over-exited and got carried away, sorry...

I think there should be permadeath, not only to keep the fort's population low, but to also keep the 'feeling' of DF and other roguelikes as a whole. And I agree that leaving the map should delete the dwarf, but with a confirmation screen to the player incase he moves out accidentally (unless the dwarf was taken out unwillingly)

For the AI, the first version of the game shouldn't even have sieges or traders/liasons, just animals that randomly step in a certain direction every X seconds, except if a dwarf is in a certain range of them, in wich case they charge at him. Also, please, no advanced pathfinding. That's probably the most annoying thing to program in AIs, and also the most speed-killing.

And yeah, dwarves should be able to carry/push other dwarves, or atleast, in the first version, if the dwarf somehow gets stuck somewhere, the admins should have some way of teleporting him out (to be used only in valid cases of being stuck)

Ok, now for some more questions, that webadict didnt have in his list:
1-How does combat work? (A seperate screen opens or something, or just like in real DF?)
2-Do we go with the energy system, that gives energy while the dwarf 'sleeps' (is logged off) to perform actions, or do we use a time system, like 2 mins to mine one square? Maybe a combination of both, so that not to allow people to be logged off for 10 days and then log in a use all their energy to suddenyl mine a whole fortress in a few seconds?
2.1-If we use the energy system, does food/drink replenish energy, or is it a necessity to keep the dwarf alive that is seperate from the energy? (I would go with the second, to keep people from hoarding food and eating them all at one time and getting tons of energy, and also to oblige people to have to take a bit more care of there dwarves, they're not just work slaves ya know )

I suggest trying the first game out in a browser based version (whatever language we end up using). If we feel that this is innapropriate, we move to flash/java, since we would have a better idea of what the game should be like by then.

[webadict]

I think a limited energy system would work fairly well in this case, much like the KoL, but slightly changed. Maybe there's a max energy that could depend on your Agility (where being Perfectly Agile lets you get twice as much energy than normal). Since energy is replenished either while you are logged off or every day (I'm not sure), you can accumulate a certain amount of energy and use it without abuse where one might stay off for a week and have 7 days of energy to use. The max might be about two and a half days of energy (depending on Agility).

The amount of energy to do things would be determined by your skill, Strength, and whatever equipment you are using.

To do simple combat, why don't we just use Strength to determine damage, Toughness to determine health, and Agility to determine dodging, plus whatever equipment you are wearing to determine defense and attack and skills to determine accuracy and critical (with some defense and attack).

For equipment, you should get one head slot, one body slot, two weapon slots (or one weapon and one shield), and a legging slot. If we wanted, there could be a neck slot, an arms slot, a hands slot, and a feet slot. This could be changed later on to take on a "weight" style of equipping, where you can wear more than one of any slot, if you can carry it.

Food and drink can replenish energy, but there could be a satiation/thirst bar, where you can only eat or drink until that point (see KoL again for this). To limit abuse of eating, the Leader can set limits on who can eat what/day.

I also think dwarves should be sorted by profession, so as to let the leader choose certain settings based on profession (or customize professions).

[Poltifar]

Personally, I don't like to idea of having a leader that has special abilities like sorting and such in the first version of the game, since ther is only one map, and thus would be only one leader...

[webadict]

Everyone could have the leader ability in the first version, or rather, they would have the ability to do anything. Later on, you can set the limitations of the other workers. Everything else seem fine?

[Istrian]

There are a few "powers" we could give to the leader without too much imbalance :

1) Production mandates : the leader has access to an inventory of the goods of the fortress and can decide to set a production mandate (he can choose to let other dwarves look at the stocks screen). Every dwarf in the fortress receives the mandate. Whenever a dwarf produces a mandated item he can drop it in a special "mandated items" bin which is created alongside the mandate and placed somewhere on the map (most likely placed by the fortress leader). Then the mandate counter decreases by one.

2) Global messaging : while any dwarf can send a message to any other dwarf (I'd say by writing a letter and then bringing it to the receiving dwarf, or the dwarf's mailbox), only the leader can send a message to every single dwarf in the fortress in one click and without the hassle of looking for the concerned dwarves.

As for professions, there is no such thing as "setting" them, each player chooses what he wants to do and the leader gets a summary of the best skill of each dwarf.

[Poltifar]

Webadict, yes, everything seems fine, with maye some modifications. The Agility skill is already used for movement speed and fighting, so I think we should put energy increase in another skill instead, and make it only slight increases as not to unbalance the game (since almost everything would depend on energy, having even a bit more than other players could make a big difference.

The idea of skills affecting how much energy is required to do skill-related things is perfect, and would be much better in the long run that having a single skills increase energy in general, because each dwarf would preferably limit himslef to doing what he has high skills in to increase productivity of the fortress as a whole.

The slot equipment system is basically what I had in mind, since a more DF-like system would be too much of a hassle in programming and balancing in my opinion...

For food and drink, other than the leader mandating rationing of food, we could simply put that if a dwarf eats when his food bar is already full doesn't get any more benefits.

For combat, yes, these skills are what will be used. But my question was more like: Since it would be energy-based game and not real-time, how can we implement DF's combat system? IE if a player attacks another one, would he attack every time he clicked the button, or would there be time interval between each attack? If there are no time intervals, players with fast connections could spam-attack a player and he might not even have time to react (since the page would have to be refreshed for the attack to be shown...)

Production mandates also seems a nice touch, as well as global messaging, but I think communication between non-leader dwarfs should not only be limited to letter sending. If both dwarves are next to each other and not sleeping (both players online), they could just use an in-built chat system.

[webadict]

Since there is already limited control in the DF fighting system, just keep the control limited.

Using a turn-based fighting style, you can:
1) Attack NPCs
2) Attack other players that are offline
3) Attack other players online
And then log the results.

For all of the above, you would use the same system where each battle would be randomized (including a possible retreat). No actually clicking would take place during the battle, only to start the battle.

2 and 3 should be rare and only applicable during a siege. And since sieges won't be in the first version, it should work.

When you are attacked, a link should come up that says so, with the events logged inside. As for how retreats would work, I'm not sure.