Dungeon Master Forum

(Idea + Pros - Cons)

Multi-state items ( Parallax@ idea) :
for waterskin, compass, torch, doors, switches etc.
+ A physical item in the dungeon = An item in the code
+ Allow some tricks with items
- Doesn't replace existing features like "class" & "qswap", because they are needed anyway
- Make those multi-state item less easy to be quick-swaped (because if you swap them with non multi-state items you end up with bugs)

Inventory as a new type of "subrenderer" ( name: "renderer" ? )
using objzone etc. to define the inventory.
+ allow more customisation of the inventory
+ allow dynamic modification of the inventory
- can mess up everything, especially if it overlaps with subrenderers
- can be complicated, because it requires some hardcoded things to get more flexible (inventory slots etc.)

Full screen "renderer" (follow-up of previous idea)
allow a renderer-type screen, like scroll / chest / object information, but full screen and with additional functionalities ( ? )
+ allow events, pop-up menus ...
+ allow sooo many things !
- complicated, too !
- what if people decide to pop-up a special chest fullscreen : no access to inventory at the same time... that could lead to bad design.

A function that pauses the game but NOT the mouse (ie blocks everything including party movement, party sleep, spells etc, but NOT inventory / party interaction) very useful for events !!

More flexible skill system ! ( less hardcoded ! )
Allow to add new skills, new hidden skills, initialize and change all skills of characters, and display them.
+ allow to emulate almost any DM-like !
- very complicated / maybe not possible

As if my to-do list needed to get longer.

Joramund wrote: Multi-state items ( Parallax@ idea) :
...
+ Allow some tricks with items

What kind of tricks?
Is there anything that, really, multiple items, exvars, alternate icons, etc. can't do pretty easily?
I've thought about this one more and the amount of work required to implement it seemed to vastly outweigh the actual benefit.

Joramund wrote: Inventory as a new type of "subrenderer" ( name: "renderer" ? )

Yes, I've been interested in this one already, the previous thread on customizing the inventory had some good ideas in it.

Joramund wrote: Full screen "renderer" (follow-up of previous idea) allow a renderer-type screen, like scroll / chest / object information, but full screen and with additional functionalities ( ? )

This will probably get done sooner or later too. For one thing, I don't want the "front door" to be hardcoded forever. Secondly, being able to show intro/plot/etc. screens would be nice.

Joramund wrote: A function that pauses the game but NOT the mouse (ie blocks everything including party movement, party sleep, spells etc, but NOT inventory / party interaction) very useful for events !!

So it would allow mouseclicks, but nothing else?
How about mouseclicks on dungeon objects? Can the party pick things up? How about changing the gamestate in general?

Joramund wrote: More flexible skill system ! ( less hardcoded ! )
Allow to add new skills, new hidden skills, initialize and change all skills of characters, and display them.

Hmm, in order to do this one right, the designer would have to have almost complete control over the inventory and stats screens, because all of those new stats would have to be displayed somewhere...
If the new skills are all hidden, you could use character exvars (ch_exvar) to store them.

Sophia wrote:As if my to-do list needed to get longer.

Multi-state items ( Parallax@ idea) :
+ Allow some tricks with items

What kind of tricks?
Is there anything that, really, multiple items, exvars, alternate icons, etc. can't do pretty easily?

ask Parallax !
I just mentioned this one for the record. I was the one who argued against it on FlashChat, remember ? (after Par was gone, of course )

Sophia wrote:

Inventory as a new type of "subrenderer" ( name: "renderer" ? )

Yes, I've been interested in this one already, the previous thread on customizing the inventory had some good ideas in it.

As I stated, it was more to introduce the more general idea here :

Sophia wrote:

Full screen "renderer" (follow-up of previous idea)

This will probably get done sooner or later too.

Hehe, then i suppose most other custom ideas will be doable with that one.

Sophia wrote:

A function that pauses the game but NOT the mouse (ie blocks everything including party movement, party sleep, spells etc, but NOT inventory / party interaction) very useful for events !!

So it would allow mouseclicks, but nothing else?
How about mouseclicks on dungeon objects? Can the party pick things up? How about changing the gamestate in general?

Well, something like freeze time would do the job, except the party arrow movement should also be blocked. Of course if it's not possible to change the game state (such as moving objects around etc.) it's not very interesting.

Sophia wrote:

More flexible skill system ! ( less hardcoded ! )
Allow to add new skills, new hidden skills, initialize and change all skills of characters, and display them.

Hmm, in order to do this one right, the designer would have to have almost complete control over the inventory and stats screens, because all of those new stats would have to be displayed somewhere...
If the new skills are all hidden, you could use character exvars (ch_exvar) to store them.

Well, if I can add hidden skills it's ok, but I still think some people will want to be able to display them... So want to be able to modify the "stats" subrenderer.

Joramund wrote:

Sophia wrote:
As if my to-do list needed to get longer.

Multi-state items ( Parallax@ idea) :
+ Allow some tricks with items

What kind of tricks?
Is there anything that, really, multiple items, exvars, alternate icons, etc. can't do pretty easily?

ask Parallax !
I just mentioned this one for the record. I was the one who argued against it on FlashChat, remember ? (after Par was gone, of course )

How do I get blamed for this again?
As far as I know, anything that it would be nice to have multi-state items for can actually be done with classes and quickswap.

Basically, every time you need to change the 'state' of the item you quickswap it for the new state so it retains all of the other properties, exvars in particular, and anytime you want to detect any of the states you test for the class instead.

So if you want to make a compass crazy you quickswap all items of class 'COMPASS' with crazy_compass and when you want them back to normal you check the party orientation then qwsap all items of class COMPASS with the appropriate compass object.

If you ever create a battery-powered compass (like a GPS object, or a spell that magnetizes a rock so it pulls north but lasts only a certain amount of time, or whatever your twisted mind can come up with) you can qswap from one object to another based on arbitrary criteria and still keep the charge (an exvar) preserved from one instance to the next.

As far as I'm concerned, that's all I need in a multi-state item and it's just as simply done with classes and qswap. So yeah, it sucks that a RA sword has to be made part of both the SWORD class and the RASWORD class so both the riddles that have 'sword' and 'RA sword' as their answers, respectively will accept both charged and discharged RA swords as answers, but it would create trouble with multistate items as well, possibly even worse troubles since you'd still have to stipulate somehow that a multistate RA sword is still a sword.

Which reminds me: Can an item have several classes? That would be useful .

Ugh, I accidentially hit Edit and not Reply, and messed up this post. The poor formatting is because to restore it I had to cut and paste it from a cached copy of the page. It's my fault, not Parallax's. Sorry. -Sophia

Maybe new ideas should be split over different topics, because it will become messy really fast here

Parallax wrote:Which reminds me: Can an item have several classes?

Not easily, I'm afraid, at least for right now.
There's a lot of code that depends on the class being a simple string, and not a table.

Well, maybe something that checks if a word is present in the class string, so you could implement several classes by just typing something like :

class = "TORCH WATERSKIN SWISS_KNIFE"

Actually, no, I was just being dumb. "IF (item.class="X" or item.class="Y" or item.class="Z") THEN" works just as well and doesn't require multiclassing for items. That's what you would do to detect, say, torches in various states of burnout if there wasn't a TORCH class in the first place.

So yea, moving on...

Joramund wrote: :idea: Inventory as a new type of "subrenderer" ( name: "renderer" ? )
using objzone etc. to define the inventory.

This concept is known as a 'canvas.' It's simply a render target. You would treat a canvas in much the same way as a visual control; i.e., it has its own size and position properties, and you can implement other transforms such as scaling and rotation. When designed properly, you should be able to render multiple canvases to your final render target (ideally, a backbuffer or another canvas) while preserving transparency as needed. The key phrase here is "when designed properly," and it depends entirely on what kind of design you're shooting for.

But yes, the canvas approach would make this idea easy to implement.