> I also thought that they might be in a temporary state, like having
> their eyes shut. So the first task of the Captain would be to wake
> them up. Dunno about the VR screen, the purpose of the Faz VR doesn't
> make it necessary.
The idea is that they don't want to leave their VR even to talk to someone outside it. That's how deep they are.
--
You received this message because you are subscribed to the Google Groups "project6014-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/project6014-dev/-/YSwb0xzi6XYJ.
To post to this group, send email to project...@googlegroups.com.
To unsubscribe from this group, send email to project6014-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/project6014-dev?hl=en.
It's good to have a solid background that we all can agree upon... but
it's IMO much better if everything is not explained in-game and
there'll indeed be mysteries. Too wordy in-game dialogues that leave
nothing to the player's imagination tend to kill suspension. However,
we developers need to know how (mostly) everything happened. It just
somehow always shows in a story whether the writer has thought the
world through thoroughly or left blanks in the design.
In general, I like Ariel's idea backed up with Joris's background
story. The thing I disagree with is having them be starfaring species.
For them (or their AI) to be capable of lifting the
slaveshield/sending ships through it defeats the idea of having the
whole VR at first place. But since that was only a suggestion for
solving the "infinite computing power" problem, they need not have
spaceships.
The computing power could also be explained in such a way that the
simulation's accuracy varies: The AI doesn't have to simulate those
parts accurately which no Faz is actually watching. The far-away
stars/systems whe Faz aren't currently in (in the sim) are just
modeled as rough mathematical equations. Whereas the locations where
there are more observers (Faz homeworld) is emulated more accurately.
I also would make it so that the Faz are able to reproduce in the real
world. (Or more like, the AI/servitors are breeding them since the
real-world-Faz are of course unable to move when connected to the VR).
If there were no living Faz we couldn't have any of that cool
altered-bodies stuff.
Damon's story actually shares a lot of same thems as Ariels and
Joris's. What I like better in A&J's version is that the Faz aren't
aware that their physical bodies have been altered (whereas in Damon's
version they started it all by starting to enhance their bodies). This
way it would become as a greater shock to them to see their miserable
state in their real world. It would also make the player's decision
more dramatic: whether to allow them die happily or wake them up to
the real world.
The player could be unsure of what to make of the VR system the Faz
are connected into once he cracks the slaveshield. He/his scientists
would realize it's some kinda VR but would be unsure of what's going
on in there. He could think it's some kind of extra-enslavement device
the Quans have set upon the Faz and think it's only right to free the
poor bastards.
Haha, once the player awaken's the Faz, the very first lines could
indeed be the:
"Why do my eyes hurt?"
"Because you've never used them before." (+ a couple of smart-ass answers...) :D
Jaakko
About the Melnorme game that the Spathi are playing, and which shares
the same codebase as the Faz VR:
Now you're talking! I like this stuff. It's cooky and fun in a true
SC2 way, but still sounds plausible in the game universe.
- So, the Melnorme sold this proto-VR game to the Faz before shit hit
the fan and the Faz got slaveshielded.
- The Melnorme have also recently sold this game to the Spathi. Upon
visiting the Spathi SB the captain gets an enthusiastic talk about the
game from the Spathi who are enjoying it to the max. At this point
however, the player disregard this just as another funny
non-significant dialogue snippet.
- After visiting the Faz planet and seeing the suckers in sleep, the
player can ask the Melnorme who the hell are these guys. The Melnorme
are reluctant to tell, arousing suspicions. But they don't reveal
anything yet.
- The captain could have his coders tap into the computers of the Faz
and obtain sample of what's running in there.
- After some time the computer wizards at starbase have deciphered the
code and it could feature the name of the program at some comment
line, which happens to be same or similar to the Spathi game's. The
hackers can also hint that if they had access to the source code they
could do a lot more with the stuff.
- Now you can head to Spathi SB and confirm that it's the same game
they're playing there. It will become evident that whatever is running
on the Faz VR is of Melnorme origin.
- Then you can meet the Melnorme and confront them about what's going
on. They'll crack like eggshells.
Jaakko
Yeah, overtly explained backstories kill interest and flow of the
game, so they should indeed be kept in writer's head for the most
part.
Jaakko
What do you need from it?
> Yes, it is under the GNU Library General Public License which is
> completely compatible with the GPL.
Okay... I thought I saw that parts of P6014 were under a CC license, not GPL. Is that content, and thus not linked and exempt from the exclusivity of GPL?
> What do you need from it?
My parser is heavily using singly linked lists, and the whole concept will require replacing/extending the [GS]ET_GAME_STATE macros with something dynamic. Thus, we're going to need sets, and the numeric flags will need maps.
The C preprocessor can take something like GET_GAME_STATE(ANDROSYNTH_HOSTILE) and put the ANDROSYNTH_HOSTILE part in quotes so that by compile time it's a string... right? If so, we can just change the macro to the glib set equivalent, and either have a special case for loading old savefiles, or break save compatibility.
Luke
I don't mind if you ask for second opinions. But I personally am
satisfied we can use glib.
> What do you need from it?
> My parser is heavily using singly linked lists, and the whole concept will require replacing/extending the [GS]ET_GAME_STATE macros with something dynamic. Thus, we're going to need sets, and the numeric flags will need maps.
>
> The C preprocessor can take something like GET_GAME_STATE(ANDROSYNTH_HOSTILE) and put the ANDROSYNTH_HOSTILE part in quotes so that by compile time it's a string... right? If so, we can just change the macro to the glib set equivalent, and either have a special case for loading old savefiles, or break save compatibility.
I made a recent change to generate an in-game table from state names to
their offsets in the state bitmap, using the C processor trick. It's
not optimised yet. I'll probably use a simply hash table for that.
Some of the variables are used in very tight loops so access needs to be
fast. I'd prefer to keep the direct access by code symbol, e.g.
ANDROSYNTH_HOSTILE instead of "ANDROSYNTH_HOSTILE", rather than putting
them in a table and having to look them up by name.
Games are going to get broken every time we add a variable anyway.
That's the downside to keeping those direct symbols. I say don't worry
about that for now though, since I'm keen to get more content in before
embarking on more code rewrites.
So, if we add a function called int GetGameState(const char *name)
is that going to be easy to wire into your dialogue engine?
At this point I assume we're going ahead with your engine, but we may
want to tweak it once everyone else sees how it works/is implemented.
Okay.
> Some of the variables are used in very tight loops so access needs to be fast.
I guess it makes sense - In my game, I separated some things out from the table, like the team's location and whether they were in their ship or not. I just had the getState(...) call check for those variables before hitting the table, and when the variables were to be accessed quickly, it didn't even used getState(...) but accessed them directly. It sounds like you're planning to do that here. If so, I concur.
> So, if we add a function called int GetGameState(const char *name) is that going to be easy to wire into your dialogue engine?
Yup, that's half of what I'd need.
Similarly, we'd need a void SetGameState(const char *name, int) which does the reverse (but refuses to change things that it doesn't make sense to change (if any - even the date and location should be mutable)).
I'll amend the language so that all flags are numeric and any positive value is 'true', and setting a flag without a value defaults to 1. That way you only need to write the one pair of access functions.
> At this point I assume we're going ahead with your engine, but we may want to tweak it once everyone else sees how it works/is implemented.
Yeah... my code may or may not be a stylistic atrocity. I think the structure is sound, since it's based off of code that works.
Luke
Each measure contains the binary representation of the measure number, letting the least significant bit be 'Do', the 2s bit be 'Re', the 4's bit be 'Mi', and so on. Each is to be played in sequence, given equal duration. So, measure 7 is a triplet Do-Re-Mi, while measure 8 is a whole note Fa. A tempo with musical sense gives each measure 3/4 of a second.
A good place to loop is at measure 64. That way, the first time you hit Ti, you resolve up to Do by starting over.
To make this work, we'd need a sample which includes all octaves so you can do an ascending scale upwards and end up exactly where you started on the 8th note.
I understand that you may have some trouble getting this in your heads - I can record it this, or maybe produce a little program that produces it.
Do any of the races fit the description I gave? Friendly and mathematically inclined? Maybe with the proper electronic sample, it'd work with Mmrnmrhrm?? Or perhaps one of the less well-defined races, such as the FleeingRace, or any other that is so far defined by its role in the story.
Luke
I tend to be as pessimistic as Mark on mathematically generated music. I'd be interested in hearing what Luke's proposal sounds like, but it's already clear some measures will yield awfully dissonant chords. Maybe some well-chosen alterations would resolve it but then that's another job completely.
B.
----- Mail original -----
De: "Ariel Azia" <ariel...@gmail.com>
À: project...@googlegroups.com
Envoyé: Vendredi 27 Janvier 2012 09:01:15
Objet: Re: [Music + story]
> When I said "living like a god"... Well, isn't that what gaming is about?
No. Those who think gaming is about living like a god either end up
starting a shooting spree in their school or end up being Jack
Thompson.
> You can die a million times without worry. Your gaming character can have
> all sorts of magic or super powers. You save the girl, the world, or
> galaxy multiple times. It's the same sort of thing.
Every character behaves according to the rules layed down in game
concept and code. Normally you can't do anything with these rules, and
you're progressing on a prescribed succession of events. While you're
controlling your character, none of these are in your power to change,
so you're not a god.
>I'd go with the Faz playing the first game, and wanting something with
>"Better graphics". Though calling the Melnorme/Spathi game bad for you
>while we're giving the player more of that game may be a little ironic,
>some might find it to be a little sacrilegious. We'd be insulting the
>player a little. I'm okay with this though, as long as we don't go "Jack
>Thompson <http://en.wikipedia.org/wiki/Jack_Thompson_%28activist%29>" on it
>(preaching that games are evil)
If we'd insult the player why go with the Faz complaining about
graphics or anything in the first place? The Faz don't have anything
to say, they just have a game from the Mael-Num they expand into a VR,
and 20000 years later they believe that it's the one dead serious
reality.
On Jan 28, 2012, at 5:35 PM, Benjamin Wack wrote:
> I like it ! But it does not fit the comm screen format at all ; aren't you worried there will have to be much much filler on the sides ?
>
> Le 28/01/2012 16:32, Gergely Sinkó a écrit :
>>
>> I dropped the chair and progressed with the capsule. I'll put the cables back ...
...
--
You received this message because you are subscribed to the Google Groups "project6014-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/project6014-dev/-/iTSCwHu5VZ4J.
--
You received this message because you are subscribed to the Google Groups "project6014-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/project6014-dev/-/XTvqg8KV4-IJ.