This is a list of questions about various aspects of the proposed "Cyberhack" game. The original list of questions is shadowdaemon's; I've added my views and
prefixed the lines with the version of this draft I added them.

/* I added my personal answers, short ones, into the text
 * -vendu
 */


* What is the basic gameplay style? RPG, RTS, "programming game", or something else?

1: I was thinking perhaps a programming game... Maybe with simple RPG-
   characteristics and I suppose team play etc. would bring in some aspects of
   strategy. As always, let's keep the conversation open. :)

2: Now that I think about it again, We should most likely have RPGish elements
   in the game. Individuals could have their own characters, things such as
   companies their own, and so on. I think I'd like to greate a reasonably large
   scale arena for people to play together, socialise, and so on.

* Will the gameplay take place in the real world, cyberspace, or both?

1: The conversations so far suggest we should probably concentrate on
   cyberspace. Although the player should probably be able to trade stuff and
   favors, but it was pointed out we probably don't want to deal with minor
   details such as eating, drinking, and sleeping.

2: There should be places in the real world, too, for people to meet each other,
   trade their goods, and so on. Social environments could be places like
   pizzerias or cafeterias; people could get together to hang around.

2: One thing we need to know is what our environment is like. Is it post-nuclear
   war wasteland, urban city, what? Also, we need to have depth to our
   characters. The way this can be done for movie scripts and such is to
   describe the character's background (like, try with yours) and think about
   how she would react to different situations and the skills & abilities of
   the character could be based on this. Sporty characters would learn martial
   arts better, for example. Science students and such would be good at solving
   problems like picking locks, breaking ice, and other creative parts of break-
   ins. :P

* What display method will be used?  2D, 3D and text have all been suggested.

1: We might be better off the further we can push the answer. Try to decide the
basic engine so that the graphical display is abstracted so we can choose
between different user interfaces depending on where we play. Would be kind of
cool if you could play even on dumb terminals if you happen to have some
around... =)

* The game will likely include an inbuilt programming language (CHPL - CyberHack Programming Language), what form will this take?  ASM, C, scripting language?

1: I was thinking of something C-like (no OO-constructs or anything to
   complicate things) with the possibility to do assembly. I suppose scripting
   might be useful for analysing code behavior (automagically) and such tasks or
   for utilising existing code snippets for the newcomer-programmers.

2: The machine simulation needs to be relatively realistic and complete. I think
   we could use C-, assembly-, and bytecode-interfaces. The bytecode would be
   interested when run as if machine code; you could generate illegal
   instructions and other anomalities in code. The host might use such things
   as signs of either programming mistakes or malicious intent and act
   accordingly; the method of self-destruction to protect data etc. could be an
   EMP (electromagnetic pulse). Extremely hazardous takeovers could trigger it.
   The system could monitor certain machine signals/events for this so for
   example, a division by zero would just make the failing program lose the
   battle. My suggestion for such events; POSIX- and Unix-signals can be seen in

   	   http://vendu.users.anapnea.net/chpl.txt

* How complex should the CHPL be?  Will there be a way for non-programmers to create code using a GUI?

Such a GUI is not a bad idea. Personally, I like writing code by hand but it's
probably quite error-prone for less-experienced programmers, and to be honest,
to a point for anyone. =) I suppose we'll see about this once the CHPL starts
taking clear form.

* The game will simulate computer systems to some degree.  How complex should this simulation be?

At user level, I think not too complicated; not cluttered with minor details
and features. I suppose under the hood, the CHPL should allow some creative
expression to add interest in the form of more variety in the software (to make
it more challenging to beat).

* These systems will be networked together so a way to simulate real world computer networking is required.  Again, how complex should this simulation be?

It would probably be interesting to simulate packet-based traffic to a degree,
but I think it's unnecessary to do details such as packet checksums... In basic
form, source and destination addresses and ports alone might take us far (and
of course the data to be transmitted; we need simple protocols for things such
as DNS requests).

* The gameplay will be multiplayer, how to implement inter-player communications?

IRC has been suggested and indeed, I think text-based communication would be the
best for many if not even most of us. Others could of course use something such
as Skype on the side to coordinate team efforts.

* CHPL will be used to simulate computer warfare, should an "all-or-nothing" (boolean) approach to handling conflict resolution?  Or will it be possible for a player to control only certain subsytems of a computer?

Here's an interesting one. I think it would be interesting to be able to
'hijack' boxen on per-service basis. My doc on CHPL, the draft so far, suggests
a few small ideas of what could be done intercepting services such as DNS.

* Will the game have AI and NPCs (non-player characters)?  Will there be public utilities in the game not controlled by players?

Hmm NPCs... This makes me think of 'characters'... I wonder how much of that we
need or if we'll get by thinking of programs and humans writing them. Surely
another interesting one. :)

* How will they in-game economy work exactly?

I don't think it should get on the way of the gaming experience too much. I'm
not much of a business/sales person; however, it would be good to be able to
trade code, hardware, and favors. Maybe other goods in the game through human
interaction of the players. And there could be non-player marketplaces for such
goods.

* How persistant should the game world be?  Single battles, campaigns, should the game world ever be reset?

This might be a per server/room decision. For quick games, single battles,
perhaps later campaigns with more of plots, and so on. Perhaps some worlds would
not need to be reset but hopefully evolve by time (by people installing harder-
to-beat programs to banks etc.)

* Will the game be coded so as to compile on multiple platforms (cross-platform)?

I'm totally for it to be as multiplatform as possible. Unix is easy, and
hopefully higher level interface libraries such as OpenGL will make it easy to
please users of other systems.

* Which coding language(s) will be used to create the game?  Which software libraries or engines will be used?

There are so many suggestions so far that I'll leave this one blank for now. I
vote for C, which I'd probably implement CHPL in; perhaps C++ when interface
libraries promote it, maybe Java etc. on the client side in other cases.
I suppose it would be fun to have a wide choice of languages to extend the game.
I feel it's the players who make most of the game. :) This is actually in
concert with the originally idea of human-lead RPG; I suppose it's spinning down
to a virtual world controlled by players. :)

* Which software will be used for the code repository?  Git, CVS, SVN?

I'll let someone else to decide, not very experienced with these as I've mostly
done one-man projects so far. Git seems to be hot and hip these days...?

* What license should the code be placed under?

For most of my code these days, I've been leaning to the FreeBSD (2-clause BSD)
side. Keep the basic code free and open, but perhaps allow gamehouses, if they
put serious effort in, to make a bit of money for their work on different
versions. Even in this case, I'd encourage light price-tags. :)

* Is there a need for developer "documentation space" like Google Docs?

This is an area we need to investigate. User docs might work as a Wiki, but the
developer docs... I think need to be clear and to the point or at least somewhat
funny if they get into ranting not to consume too much time to read.

Cheers, good questions dude,

Vendu