The Hacker Project - a free online game

Official Groups would be awsome so that it is easily managable.

Can't be implemented as there is no way to limit it.

How about the following rules for a group:

1) It costs 5000 HPD and 1000 AP to create a group (Numbers made up). The person who does so becomes the leader
2) The leader can invite people to join the group OR the leader can accept applications to join the group
3) All members of the group are aware of the following things:
3.1) The names of the other players in the group
3.2) If a process is owned by another member of the group
4) Members of the group (perhaps only a subset chosen by the leader) can send messages to the entire group
5) The Leader may spend 500 AP to hand leadership to another player in the group


This would allow a group to coordinate, without providing any major benefits.



If people want to give benefits to groups, some include:

1) The Leader may purchase/upgrade a Group Server. Every member of the group has Admin Access to it, but no member can use it as a Gateway.
2) Members of the group may trade control of Virii.



Some possible disadvantages of groups might include:

1) There is a file on the Leader's server. "Reading" it (a special action) gives the person the name and IP of every member of the group.
2) The group messaging feature requires a small (100 MB) program. If a person outside the group downloads it, they can "listen in" to the messages, without being a member of the group.

I think that kind of update at this stage would be too big, although it would probably, imo, iron out some of those "less wanted" features such as the virii limiting  :16:

Aside from that, imho it sounds like a great idea as most other games of this type have something simiilar in-place (although they have been running much longer than HP).

Zac, did you read my mind? I was just too lazy to put it down...

Laziness and hackers don't mix. The same goes for game developers.

If we were playing Pardus, you'd be risking a Forum ban for not having thought out the idea enough.

When I read your listing of group features, the first thing that came into my head was how much they resembled the alliances in Pardus.

The only question is, is your group affiliation visible or hidden, or can you choose.  I like the listing of the stuff on the leader's server but that seems a bit off, maybe having the IP listing on the group server (which only makes it more easy to get to for someone who is new to the group, maybe need special permissions to access it...)

In Pardus only senior group members (determined by whatever criteria you want) get to send messages to the whole group, that would be useful and could be applied to the IP listing so that only senior members get access to that information, you wouldn't want that up for grabs to just any new player.  Maybe they could... oh I dunno... "hack"... the listing in some way though to get access if they are not a senior member.

Now that's something new and something good. This will make teamwork viable.
How about Group FTP Gold Server where you have around 100GB file storage that can be downloaded by members of the group? Files from this server however can only be downloaded to the Group Server to prevent abuse and to allow other groups to hack the Group Server and make damage from it.
 :14:

And also Group Notes where groups will be able to use as subforums so we don't need to use another forum for this. They can place notes of targets servers, new server IP's, IP's of target players etc...

And also Group Logo that can be displayed (can be hidden) on the servers belonging to the group.

The Group should be limited to 3 initially and the Group leader must pay additional cash to increase the number of players that can join the Group. The increase should be incremental like 50,000 HPD to create a 3-player group, 20k to add another  player, 40k for the next player, 60k for the next player and so on...

And to implement teamwork, players should be able to upgrade the Group Server as well as donate cash to the Group Fund that can be used to upgrade the Group Server or research softwares for the Group Server. Donating to the Group Fund should be charged 20% tax. Viruses installed from the Group Server will be credited to the Group Fund and cash from the Group Fund can be distributed evenly to team players also with 10% tax.  :laugh:

Each player should only be able to join one Group and should be prevented from joining another Group after around 5 days?

Group Logo and Group Information should also be displayed on the left menu.

I disagree with trading controls of the virii as this could present new unforeseen problems.  :5:

Raven, I like it and also agree that trading virii control is just asking for issues.  You can just have them cap it anyway...

Given I've been playing Pardus for over a year, it's likely a few ideas slipped in. However, almost every game allows chatting with the entire alliance/guild/crew/whatever.



The big things I'd like to see for this game is the following:

1) Membership is secret to the outside. Unless you are in the group, the only person you can be certain of being in the group is the leader
2) Membership is program-oriented. Each group has the following associated programs:
2.1) a Membership ID program. This allows you to recognize the servers and processes of other group members
2.2) a Chat program. This allows you to participate in chat/group messages.
2.3) a Registry program, that lists the name and IP of every server with an ID program or Registry program
3) Groups can buy/upgrade a collective server. No one could use this as a Gateway.
3.1) the group has an Access program, that allows them access to the collective server.



The things I'm not sure about are group exclusivity (can you be in multiple groups) and group size (should it be limited). Given the above, what I suggest is:

Group size is limited by the Registry program. It runs on the Collective Server, and can be researched by any member of the group. for every .1, the group can have 1 member in addition to the leader. This program uses (10 000 CPU + 200 000 Memory + 5Gb)*Level. People who download the Membership ID program without permission show up on the list as soon as the Registry has space for them.

You can only have one Group ID program on a server. This program is small (10 Mb, 50 CPU, 500 Memory at .1), and as long as it is running, you recognize and are recognized as part of the group. It is treated as a Virus for stopping, and can only be stopped by someone who has bounced through the Collective Server.

The Chat and Access programs can be downloaded without permission, and do not result in you being part of the group. They do, however, allow you certain benefits of being part of the group (and likely the enmity of the group, should they find an unauthorized copy of their software floating around).




The Chat program being stealable makes it so that some level of espionage is possible, and a creative hacker might even be able to manipulate a large group into helping him without joining, or even starting a war between two groups from the outside.

I like that, but I don't like this part:

"Group size is limited by the Registry program. It runs on the Collective Server, and can be researched by any member of the group. for every .1, the group can have 1 member in addition to the leader. This program uses (10 000 CPU + 200 000 Memory + 5Gb)*Level. People who download the Membership ID program without permission show up on the list as soon as the Registry has space for them."

I like this idea for group size limitation by research, but I don't like the part where people who download show up on the list as soon as there is space.  While it is nice, you are upgrading it to make room for a person to join the group, most likely.  "Oh Jimmy, sorry you can't join even though the space just opened up, we do know that Johnny has our registry now, so if you go delete it you can join... oh wait now Bobby is on the list, better go delete his too"

I would prefer the registry have some sort of logs that keep track of who accesses it, maybe gives you a chance based on your ip cloak level that you don't show up in the logs when you access it. 

1> Groups are already available.  Look at SGP.

2> Coordinated actions and effecient use of each member is already possible.  Look at SGP.

3> Before any more new "features" are added in the current issues need to be resolved.

I will give you that. However, I am willing to bet that SGP are not your average gamers. I have no idea exactly how you work (And would love to learn), but there are a few telling things that make you a poor model for what is possible in general:

1) You have limited your number to 6
2) You are all likely in the top 25 most active players
3) You are the 6 most powerful players.
4) There appears to be a high level of trust between you

For those reasons, you are not a good model for what people can do. One of my allies and I have a hard time coordinating because of schedule issues: we are rarely on together. Trust is harder to build and maintain as groups grow: I trust (for the most part) the three hackers I've had contact with. I don't think I could keep track of, let alone trust, more than about 10, without some way of recognizing them, and having them recognize me (and my virii: with Virus Capture, you can't know who's virus is whose). Finally, your power level means each of you can operate independently (and from multiple servers). I often wait on certain attacks so that I can coordinate, just so that I know I can take advantage of any surprises there might be (like a decent program, given my bandwidth seems to be always in full use).


There are a lot of issues that need to be worked out. However, I think a lot of us are hoping for a new feature before we start losing options again.




And Araeus: I see your point. In light of that, I'd change it to:

Group size is limited by the Registry program. It runs on the Collective Server, and can be researched by any member of the group. for every .1, the group can have 1 member in addition to the leader. This program uses (10 000 CPU + 200 000 Memory + 5Gb)*Level. People who download the Membership ID program without permission will show up on the registry at random if there is space for them: they are not part of the group, and legitimate members of the group supersede them on the list.

Some more things:

No group server can be used to bounce.

Each group has a special virii that, installed in other servers, disables people to see the logs that have members IP on them.

All the group shares the IP database and the password for remote gateways (only one of the group will bypass each server) but they need to bypass the firewall at least once to have admin. That means:

Any of the group can break the password of a not member gateway and the others will see "Firewall" not "Admin" at the IP DB. Then they connect to the server, bypass the firewall and the password gets downloaded in 5minutes after that. Then they get admin access.

Members can stop any action from a no member as if it was their own gateway.

A read-only system can be great. You can only use in one file of each type, and it takes 2 hours to change the file set that way (1 to set the file out, another to set the other file). Disadvantege: The file is publicly aviable, and anybody with admin can change the read-only files, but download can be stopped by a member by killing the process at the process page.

Any member can use his/her HPD to start a research/increase hardware as if owned gateway.

Members have always connection to the GS, under localhost and remotehost, implementing a grouphost that does not need members to make login (so admin logs are not recorded)

Only leader can change the IP of the GS.

I'm not sure I like all of those ideas:

Why shouldn't people use a group server to bounce? I know if I found your group server, I'd bounce through it before hacking, just to allow more people to find it.

A virus that blocks people from seeing a group's IPs completely seems way too powerful in my mind.

Allowing every member of a group to get past a Password Protect once one person does can easily lead to problems: One member of my group spends all his time cracking servers, and giving out their IP. The rest of us don't even have a Password Crack: we just go in after him. Since Firewalls go down instantly, but Passwords take minutes, if not hours, to complete, plus some APs; this gives us a nice benefit, and our Cracker gets the advantage of being undetectable (He never actually uses Admin access, so his IP never shows up).


Members being able to complete/kill other member's processes is a mixed blessing: I'd love being able to finish downloads that an ally initiated to my server, but it also makes stealing an ID program much more powerful.

I like the idea that the Leader can make some files Read-Only. Sure it protects the file against deletion: it also allows people to download it anonymously.

I thought I already implied that members can upgrade and run research on the Group Server: the idea is that they own it, but can't use it as a Gateway.

Having people always have a connection to the group server is irrelevant: if you can access the logs, you can also access the Registry, and so you already know who's part of the group.


IP changes on the Group Server should follow one of three rules:

1) Anyone can do it
2) Only the leader can do it
3) No one can do it

I'm against 1, and I prefer 3 over 2. However, 2 is not a bad idea.

When I first read this, honestly I was in a bit of a hurry and my initial thought was - so what is being proposed here that is new?

I think that to make a valid proposal for groups you need to make a comparison to what can already be done today and then to be explicit as to how that would work in the same or in a different way for groups.

Of the above the only thing which cannot be done today is point 5 - insofar as handing over ownership of the group would in principle also hand over ownership of the group server (something implicit, not explicit) and it is to my knowledge impossible to hand over ownership of servers.

Point 1 - You can create a group by gathering people around - this is an administrative point have to look into the effects.

Point 2 - Again an administrative point - I don't need an in game mechanism for this if I want to have members working together.

Point 3.1 - Simple to do by telling members of the group who is in the group. On a related note I would say that I would NOT necessarily expect everyone to be aware of who is in the group. As group leader I prefer to decide who is a known member (known to other members of the group) and who is a member who is not known to the other members. There are a number of reasons for this but in a hacker world I don't see the imperative need for everyone within the group to know who is in the group.

Point 3.2 - I assume you actually refer to it being an in game message when similar to the [owned] tag which appears next to your own processes, something such as a [group] tag which appears instead when a process is owned by a different member of the group. Fair enough but a bit unclear - you can easily let others know (e.g. through an offgame forum) which processes you run where, though admittedly it would be a hassle.

Point 4 again - a question of organization. Any self respecting group would have out of game channels of communication which would allow all to be aware of the actions - though admittedly having an in game mechanism would be nice.

Basically - all I saw to your initial proposal was the drawbacks, not any advantages.

The basic question is how exactly a group server works. Today I can easily create a server, pay for it and give the IP to my friends, let them hack it and voila... group server.

The question is what can be done beyond that point in particular how does the server behave with regards to:

1) Expansion of the server (only the group leader? All group members? All group members but a different cost than normal expansion? How do you handle gold membership benefits on group server expansion?)

2) Research on the server - nothing was mentioned at all on this until the last post - Should everyone be able to research, only group leader etc. (If all can research you could say have 5 members do 5 research processes on the same program to end up with a bigger program)

3) Admin access to the server - All members automatically? Decided by Group leader? Members who hack get access?

4) Password reset on server - Do all members automatically retain admin access? Do they lose admin access? (related to the first question). Who can in fact reset the password on the server (aside from someone with a sniffer daemon  :16:)

5) IP changes to group servers - is this even possible? Limitations on the IP changes? Who can start an IP change? How much would it cost? After an IP change are all members still automatically aware of the new IP or do they need to be notified by the Group leader (both have advantages)

6) Does a group server function as a normal server? (I would be tempted to say "yes" the only question is how much access to functions group members would have - for people outside the group it is simply "another server to hack" whilst for the actual owner of the server it is simply a server shared with friends, unless someone can see a reason why this should not be so).

Another question - is the group leader the only one who can create group servers? Can other members of the group create group servers too?

While I do have my own answers to most of the questions above, I simply want to put the questions on the table first - then to work through what is reasonable, what is needed and what is doable to see groups of some kind implemented. (hopefully  :7:)

I find the idea of a group registry which can or cannot be hacked to be very interesting, but a bit premature as I am not at all sure what you (ZacQuicksilver) are suggesting for a group to be (I think you have a more clear idea, but it's not coming across quite yet)

I am loathe to shoot down ideas, but I favor the current LACK of group tools. At the moment, trust is the major limiting factor, and I believe this adds an interesting element of tension to all but the most tightly knit groups. Transferring files is hard, and I don't think that should change. I know it is possible, there are groups doing it besides SGP.