Jump to content

  • Log In with Google      Sign In   
  • Create Account

haegarr

Member Since 10 Oct 2005
Offline Last Active Yesterday, 02:13 PM

Posts I've Made

In Topic: Reading multiple datagrams from UDP socket

27 August 2016 - 04:28 AM

UDP is about datagrams. It has no conception above that, especially not how to concat datagrams nor how to distinguish them after concatenation. 

 

However, it is not clear to me *why* you want to do so. What does "all the messages" mean exactly? A sequence of messages from the same source? A soap of messages from different sources? What should happen if one of them is missed on transmission? Such questions need to be handled as well.

 

IMHO we're speaking of stuff belonging to the application protocol layer!?


In Topic: What's a room?

21 August 2016 - 10:50 AM

A room as a compound (not necessarily an entity as in an ECS) may have

 

* a NavigationComponent instance (navigation graph or mesh), to be installed with the NavigationServices;

 

* a set of ColliderComponent instances, perhaps tagged for specific usages, to be installed with the CollisionServices;

 

* a set of PortalComponent instances (of the entree or exit kind, interconnecting rooms inclusive positional mapping), to be installed with the NavigationServices, used as another level of navigation;

 

* perhaps a LocationComponent that gives the room a name, a location on a map, or such a thing

 

* ...

 

Not a RoomComponent makes the entity a room, but the collection of more generic components. We are not speaking of a strict and explicit typing here, but of a kind of duck typing.


In Topic: Modal GUI and ongoing events

21 August 2016 - 10:28 AM

IMHO: From an UX point of view, your GUI has a design flaw when it regularly causes such a break. Why should a modal dialog appear without a causing user interaction? You should definitely avoid that. It can be accepted in seriously problematic situations, but then the pointer's shape should be your least problem. That said, what are the specific use cases you have in mind?


In Topic: Xml Dialog Tree For C++

30 July 2016 - 02:32 AM

A notice at the beginning: Also my opinion is that XML is fine as intermediary file-format, useable in automated processing, and for small enough problems.

 

AFAIK the sample in the OP is not a well-formed XML document as it lacks a root element. Let's say it looks more like this:

<?xml version="1.0" encoding="UTF-8"?>
<dialogtree>
  <dialog id='1'>
    <message name="Boss" text="Testing the dialog system!"></message>
    <response condition="True" nextDialogue='2'>
      response text
    </response>
    <response condition="False" nextDialogue='3'>
      response text
    </response>
  </dialog>
  <dialog id='2'>
    <message name="Boss" text="Testing the dialog system!"></message>
    <response condition="True" nextDialogue='4'>
      response text
    </response>
    <response condition="False" nextDialogue='5'>
      response text
    </response>
  </dialog>
</dialogtree>

Looking into the DOM the standard way is done by using XPath. There is TinyXPath, not exactly an active project, but the features you need are not challenging, so good chances are it will work fine for you. Then looking for the <dialog> with id=2 would then use an expression like

   /dialogtree/dialog[@id='2']

if the level of the dialog element is known, or perhaps

   //dialog[@id='2']

if not. However, on success it returns the addressed node.
 
Of course, XPath is sufficiently complex in itself. Iterating the DOM "manually" using TinyXML's build-in TiXmlVisitor class is possible, too. Your specialized class instance then decides on a node-by-node basis whether the currently visited node is the wanted one, and remembers the once found node. This is, AFAIS, the way of doing things as is intended by TinyXML itself.

 

Not related to browsing DOM, but nevertheless worth mentioning: whitespace handling. In a declaration like this (notice the indentation just made to let XML look user friendly)

    <response condition="False" nextDialogue='3'>
      response text
    </response>

is the text you want to display with whitespace like in this string (also notice the line break, please)

"      response text

       "

or without leading and trailing whitespace like in this string

"response text"

 
The distinction between wanted and unwanted leading and trailing whitespace is not really possible here. A better approach would be to make all text() within respective nodes be wanted text, so that the given example would probably look e.g. so:
    <response condition="False" nextDialogue='3'>response text</response>

In Topic: Help creating an interactive story game

26 June 2016 - 02:01 AM

A "motion comic" is defined to be a comic like presentation of graphical content but augmented with basic animations and perhaps sound within the panels. It will ever have user interaction to advance the story and may have interaction to examine pictorially given details (to mimic the look-at / examine functionality of IF / TA / GA). Such interaction has no impact on the story.

 

Now, It may have interactions that leads to different story paths and endings (a.k.a branching story). This is close to the CYOA approach mentioned by alnite above. Due to the narration being done in (partly) animated comic panels, this approach consumes much time of artists and requires great attention on continuity checking. All potential endings are pre-defined, and the particular reader sees a single path through the story.

 

Another approach is to tell the story in parts, so that one part is published per time unit (e.g. a week). Each part ends on a branching point, and the readership is enabled to vote online how the story branches and hence advances in the next coming part. This approach to influence the story is not directly depending on the motion comic media, but it reduces the overall amount of work drastically. At the same time it has, obviously, other hurdles.

 

Graphic adventures (or GA for short), often implemented utilizing the point-&-click interaction style as mentioned by Alberth, are a different thing. They and their text variants TA and IF are based on a concept where the player is in a room and can examine and interact with the things therein and finally leave the room through one of the exits. Notice how different the media is. In a motion comic, the story is narrated in a sequence of panels, each one allowing to express a dramatic composition with camera settings and scene composition and such, while a GA does not do such things.

 

In other words, the artistic expressiveness in a motion comic is much greater, while in GA the interactive part plays a bigger role. Interestingly enough, the authoring systems available for GA can also be used to design a motion comic (although I doubt a bit that all that nice effects seen in motion comics can be done with them … but maybe).

 

Allowing the readership to contribute content to a story driven motion comic - well, ATM I cannot really imagine that it will work well. Can you share your ideas with more details?


PARTNERS