Resumed And Detailed: "Project Shock"

ID:87427
 
Dec 14 2009, 12:38 pm (Edited on Dec 14 2009, 1:51 pm)
Keywords: design, game, motivation
After my long tirade about the importance of thinking things through before putting down a single line of code, I made for a fair compromise: instead of starting a project over from scratch, I've decided to pick up a simple project of the past that is relatively "clean", figure out exactly what I want to do with it, and finish it.

So I am. After a day or two in the conceptual stage, I've a design document that can be conceptually played through from beginning to end. Any cool ideas I have while I'm making it go into a separate "brainstorming" document for later - for now, I'm just coding what's in the design document, which should produce a finished game.

Though it's yet to be fully coded, the overall GUI (like the design document it is derived from) is fairly set in stone, and will look like this. It's actually really implicit - just about anyone can pick it up and play it without much difficulty.

The game works like this: the players are playing individual characters who start off in the middle of a 5x5 grid of sectors. Their goal is to take over all the sectors in the game. This will involve quite a bit of a change of the game world as the players re-purpose it to their needs.

Your movements are queued ahead of time, you can actually see indicators on your screen telling you what you're queued to do, and they play out at the maximum speed your character is capable of performing each action. In this way, it's a bit of a thinking man's action game. It also makes extensive use of line of sight and resource management.

There are victory and defeat conditions. If the players take over all the surrounding sectors, they win, and how effective they were at producing this goal will be recorded on a high score list. However, there are various threats in these sectors that will try to thwart the players, and they get more belligerent the more progress the players make: it's possible to lose the game, too. Having a way to win or lose is, I feel, an essential part of a dynamic content experience.

My design also experiments with the concepts of advancement. Experience points and levels are sort of boring after you've played the nth game with them, and even grinding a skill-based advancement system eventually loses its novelty when you realize that you're still grinding. Advancement is instead based off of successfully taking over the sectors around you. Each sector accessible to you rewards you with a new ability.

To curb the obvious possibility of grief play, I have a built in "prestige" system where points are kept track to determine just how helpful players are being. Players who dip too far into negative prestige territory will bring about certain measures to prevent them from being a bother. It's my intent that this game will be auto-moderating. Yeah, good luck with that, right? To curb the creativity of the griefer, I suppose manual banning mechanisms will still be required, but at least this foresight will cut down on the need for it quite a bit.

For now, I'm going to use a static map. In time, I plan to use dynamic map generation that would enable a new adventure every game. However, the goal is to keep things relatively simple until I have a complete and playable game done.

It's looking good, so far. The central queued movement, ability, and device architecture is in place along with several examples. I have yet to complete the threats the players will encounter, but I expect it will be relatively simple.

Knowing exactly what you're trying to explain to the computer is much more productive. I'm probably going to start enforcing my "minimum ten changes made to the code before compiling and running it" procedure to bring about even more productivity, because I keep wanting to make little changes to it and then play with it a bit.

So, ETA? I'd like to promise to have at least a crude version up this week... but unfortunately, it's finals week, so that puts a damper on things. However, I should have something up "soon" - I'd be surprised if I don't have something up by the end of the year.
Dec 14 2009, 1:28 pm
The prestige idea is interesting. I have a concept like that built into SotS II, though it's entirely positive and doesn't account for negative actions.
Dec 14 2009, 1:55 pm (Edited on Dec 14 2009, 2:27 pm)
What I'm currently planning on doing is having the players who have accrued way too much negative prestige to end up as "regenades" who end up opposing the main players -- so, if they really want to undermine their fellow player, turning it into a PvP thing, they can.

Of course, because I'm trying to encourage the players to work together, being a renegade will carry its own down sides. They won't be as heavily rewarded in the long run, and they probably won't even be able to communicate.

It's tricky, though. I know a crafty griefer will figure out a way to game the system and undermine their fellow players if a lot of foresight hasn't been put into preventing them from doing so. A quick and dirty implementation of a prestige system could very well turn into a tool for a griefer to use against others.

So, for the time being, I just have the prestige mechanism getting implemented. I'll iron out the details as they come to light. The best bet might even be to have players be able to "vote" on their own on if somebody seems to be griefing them. Players are smarter than a computer at figuring out they're getting screwed.
Dec 15 2009, 2:06 pm
A voting system could backfire in that you could see all of the other players vote against the point leader in order to handicap them, that sort of thing. Maybe the easier thing is to identify the ways in which a player can screw other players and build in disincentives for as many as you can.
Dec 15 2009, 2:46 pm
A voting system could backfire in that you could see all of the other players vote against the point leader in order to handicap them, that sort of thing.

Very true. I was thinking maybe have a system where the player's prestige is only influential insofar as is matched by the computer's negative prestige... but even this might not be great because if a person is that good at gaming the system then it neuters the entire idea of voting to begin with.

Maybe the easier thing is to identify the ways in which a player can screw other players and build in disincentives for as many as you can.

Could be. Me thinking is that I'll just tread very carefully and add only as few incentives and disincentives as I feel I can reliably avoid being gamed.
Dec 15 2009, 2:55 pm
Some such incentives can be built into a relatively simple AI. For instance if you've got a basic monster combat game and a player has found a good place to "camp" and get easy kills, there are two approaches which can be used (and not exclusively, either): 1) Destroy some aspect of their camping spot like a wall or something, or break a lock door, to undermine their ability to maintain that position safely. 2) Send fewer enemies after them in that position, hurting their ability to score easily. If it's all about survival by hiding, then you can do the opposite and send more or tougher enemies after them.

It's really about brainstorming what's going to do the most good in terms of punishing or frustrating players' more obnoxious forms of behavior.
Dec 15 2009, 3:38 pm
A dynamic content threat generating AI was one of the things I was thinking I'd do (although, to keep things simple for the time being, I was going to assign spawn static threats). Those are pretty handy in that they do make it really hard for the players to game because you can't be sure what's going to happen next.