Heath

I think it's interesting to compare games you love to previous games that probably inspired them. The Legend of Zelda, for instance, could be viewed as a really big, graphical expansion on Adventure, and Adventure is a graphical game inspired by text adventures. Zelda did not have the same hardware limitations as Adventure, and both had to make use of what limitations they did have.

And in that sense, you come to realize that of course, there is always room for improvement, but you might first need to appreciate why things were done the way that they were.

This is a video game idea that a few others and I trying to develop.

• There are a number of heroes to select from and each of them carries a unique skill-set that gives them their own role on the battlefield (similar to MOBAS).
• From a deck of heroes, each player would select a only a team of four.
• From there they would place each card on a specific position. The layout of the field is comprised of four positions: one at the frontlines that provides no attributes or changes to the card, one that is place a bit further back than the first and gives the card 15% damage taken reduction from all sources. The last two are placed at the very back and provides the card that is placed on it a 30% damage taken reduction and also a 30% damage dealt reduction.
• At the beginning of a turn, the player receives a certain amount of points that can be used to cast abilities. Certain hero abilities cost more than others.
• The player can also choose to skip his or her turn and pool the points for the next turn.
• Item cards are randomly drawn by each player, one per turn. These can be used to increase the damage of an ability for one or more turns before it expires.
• There are also item cards that can be used defensively such as blocking all damage for one hero on the next turn. Item cards would remain hidden to the opponent.
• In terms of progression, the player can level up the heroes they play and choose from a tier list of bonus effects on their hero's abilities.
• The game could be played solo 1v1, 2v2 with each player being in charge of 2 cards, or 4v4, each player being in charge of one card.

What would make someone want to play this game or what would make someone not want to play this game?

It sounds straightforward enough that you could prototype it in Python pretty quickly.

Are the two bases against each other or in cooperation? If they're against each other, then either base is hurling missiles at the other base which needs to intercept them. If they're in co-op on opposite sides of the screen, then there must be a common enemy between the two bases.

If they're working in co-op on opposite sides of the screen, then what would drive the human players to work together? If one player is destroyed, what happens? The other player has a game of Missile Command all to his own. Game is over and starts over when that player is done.

Another option: Put the two players as turrets in the center of the screen, back to back. Player one faces up, player two faces down. If either one is destroyed, the game is over, and it starts over.

Let the player(s) choose which set-up they want, and you'd have an action game.

Heh, Jungletoe is my internet username I chose when I was 11 because I was trapped in a jungle in Runescape and needed a new character. It doesn't really fit my theme either.

Okay.

Is it possible to just stick with "Project Ember" as the actual game name? Until now, I've been using it as a temporary name, but Project Zomboid seemed to pull it off.

Hmmm... I don't know about the "Project" part of it, but "Ember" does sound sort of like "Empire", after all.

edit: Jungletoe's catchy enough. Plus, you wouldn't need to worry about another domain name.

Yeah, buggy broken games are definitely worse than bug free ones. Look at ET and Superman 64 compared to Ocarina of Time or Super Mario 64. Two of them went into the trash heap, two of them were instant classics. So you could say that on a quality level, a game can be better than another. Although Skyrim was one of my favorite games of all time and it was really buggy. You could also look at quality of design and determine that one game was better than another... In the end though I think you could analyze all those points and always come up with a conflicting argument. So if you define the purpose of games to be entertaining people then the "better game" would be totally subjective. Just like one painting can't be truly "better" than another.

Ah, Superman 64. That game had a lot of problems during development, and there is some video of what it would've looked like on PSX, had it had more time. In that version, Superman does not fly through rings all day long, but it's hard to say from the footage that it would've been on par with the best games of the time. We'll never know. What we got instead was Superman on Nintendo 64. Oh boy did it suck. Oh boy was it clear the programmers either did not know what to do with the system they were programming, or were rushing a piece of junk out the door.

In that sense, Superman 64 has something in common with its hero's second film, Superman II. Good movie, no? Go check out the Richard Donner cut and see if it isn't better, if it doesn't make far more sense, if it doesn't flow much more nicely than the theatrical version. Sometimes, what we get is just inferior to what could've been.

Interesting idea - Do the NPCs already have pre-existing relationships before the game begins? Bob and Joe are friends, Charlie doesn't like Joe, everybody hates the manager?

That's what I was thinking, but something about that may have to be randomized so that it's not the same puzzle every time.

What about having to deal with the emotions of distraught NPCs immediately after a disaster? What comes to mind is the Chilean Mining Disaster a few years back, where supposedly the mental health of the miners, as led by the mining foreman, played a important part of their survival.

Great idea! Maybe each level is a different scenario? New guys come in, Charlie's girlfriend left him for the company pencil pusher, etc.

A construction site would also offer many good ways of getting rid of the bad blood

Chris Crawford's game Balance of Power would end with a black screen if you brought the world to nuclear war, and some text would say, "No, there is no animated mushroom cloud with parts of bodies everywhere. We do not reward failure." So, if your team ends up killing each other, I think it's game over.

The first thought I have is that, for this to be a "game" and not an educational simulation, you need a primary mechanic and a goal. If we run with the construction site thing, that gives us the goal - complete the building. It also gives us subgoals in the various jobs that need to be done, which is great.

The good news is that my goal is not to make a construction site simulator. I wouldn't even be the right person to do that. The goal is to have the player lead a team to accomplish some visible task, and efficiently mete out some problems in the group.

Primary mechanic? Organizing your construction teams for maximum efficiency. Certain people don't work well around other certain people.

And talking to them, too.

Sometimes they rub each other the wrong way. Sometimes pairing up two slackers encourages them to slack off even more. Sometimes their combined experience isn't enough for the task at hand, etc etc etc.

The trick is to balance the information you give the player with the information you withold, I think. Unless you want to completely simulate human emotional behavior, you need to heavily abstract it. That might lead to altogether too much predictabilty, though, unless you get that initial balance correct. My thoughts? "Professional" information should be given: Skills with various tools and tasks, experience and work ethic, etc. "Personal" information is hidden though, and heavily affects how a person works within a team. Thus the job of the player (manager) is to suss out enough of a person's hidden personal characteristics to put them in the best group possible, and THEN balance the combinations of people and groups to make an effective set of teams.

Interesting. But I wonder if the construction goal will start to override the goal of managing people. Play-testing is a must. I'm not interested in modeling the human psyche, either, so there will be a lot of abstraction to keep things simple.

At least, that's the first idea I came up with. Modeling that personal behavior in ways that is at once believable and unpredictable (more problems come out under the stress of close deadlines, for instance, so problems that might not have shown up before suddenly appear) is the meat of the game and needs to be nailed.

I agree. Thank you!

I really like the idea of a construction site! Modern settings have a special place in my heart.

I was really worried about that when I posted this. I don't want fantasy, I want to do something a lot more grounded, so it's great to see some interest there!

Like Telcontar said, I feel that having the player discover or some how figure out the workers traits would be a good way of managing them, even if it is just trying to glean those traits based off their interactions. Having each worker have something like a name card that you can check off what traits you think they have. Like Joe could be moody and Max is an extrovert, making the chance of them fighting a bit higher than if either was paired with the introvert slacker Mike.

Then, having their traits unknown at first but giving a list of possible traits for each worker will help the player feel less lost in the process and once they master the system, they will know exactly why. It'll give them confidence and satisfaction from playing the game, which is pretty dang cool.

If the workers have random personality traits that work well with some while completely clashing with others, you probably wouldn't need to have pre-determined relationships since those relationships will appear based on how their traits mesh. An angry, alpha workaholic being paired with 2 passive workaholics could get along great but 2 alphas together and you have a mess to clean up.

I think that makes a lot of sense. I'd imagine this information can be play-tested a little bit as a kind of card game or board game, too. Not really any construction, of course, but you could have players role-play a little bit. Each player who plays a worker takes a "skill card" and also a "personality card". The final player is the boss, the player in the computer game, and he gets a copy of each player's "skill card" and goes about managing his team. Maybe have a board to show where each player is on the site, as well.

My only other thought is finding ways to force the workers to work together. If there are enough things to work on, then they could just be separated and won't need to interact. If you make it so some tasks can't be completed without 3 or more workers and tasks are dependent on one another, then you have a pretty simple system that has a high chance of chaos going that I think would be a really fun resource management game.

Put the pressure on to get the results you want.

Just my thoughts, but now get to work! I wanna play it.

Right on!

or perhaps you're developing for a system that requires such attention to detail, and you must concern yourself with excess bits and bytes, you're welcome to do that, too.

There you have nailed it my hoby is to program for very limited micro controllers I enjoy making limited hardware doing impressive things sometimes I even program in assembly but I use c alot too.

I like that hobby. I keep the C64 programming manuals as PDFs in my Ubuntu One cloud, and I've fiddled a little with NES programming. It takes a whole different mindset from current PC programming.

Always make the final boss (with no particular weak points) a matter of shooting him until he keels over, then a quicktime event. Repeat. On harder difficulties, take this, but make it three times longer per level.

Yeah, attrition. Relying on quantity of resources rather than intelligence, or quality of challenge.

That reminds me of the opposite, actually, and that makes me think of the original Syphon Filter. You go through all these levels and all these bosses, you're getting head-shots, you're sniping, you're blasting through enemies, you're... generally trying to figure out where to go next... and eventually you get to the final boss. If I recall correctly, all it took to kill him was a gas grenade. It's the last thing you'd think to throw at him, but if you did, it ended really, really quickly.

And that is neither attrition, nor a really acceptable challenge. It was just anti-climactic.

Instead of requiring your players to go through intensive procedures to play the game, offer your paying many small (perhaps weekly) updates. New level, new dungeon, bug fixes, new quests, etc. In many cases content that could (if the game was built in that direction) pushed out very quickly. But _NO_ DRM required to play. An account would be required to get the update, and have the updates specifically keyed to their computer.

Now of course, the hackers will eventually patch the add-on content as well, but it would be behind that of your paying customers. These customers wont HAVE to get the update, but odds are if they have access to an internet connection they are going to want to. The pirates, though they will still pirate, will be behind in the updates. will have to constantly patch and repatch, and eventually the convinance of your distribution method may even convince those pirates that CAN afford your game, to do so, in order to stay up with the free content.

Fancy that, reward your paying customers with DLC.

Make open source games. Ask people to pay what its worth if they like. Pirates torrent it?
Word of moth advertising! Thanks pirates!

These two do not sound mutually exclusive to me, and it also sounds like you could tie this into Kickstarter, or something like it.

$60 is too much for any game, if you ask me, and it is definitely too much if it's only a down payment.

I remember some from watching AVGN:

1. Make the player's character long and difficult to maneuver. All obstacles kill and send you back to the beginning of the level.
2. Make the key to open next level to appear randomly and in random places, but only after an obscure event has been triggered (like touching an unmarked tree, three times).
3. Give the life bar 10 hit points, but even the weakest enemy will take 9 HP from the player.
4. Take a violent game and transform it into a Bible game!! (blood, weapons and enemies are exchanged for something nice) Don't forget to include questionaries at the end of each level.
5. Instead of creating a story related to the game's title, insert objects barely related. For example, if you want to make a game based on Back to the Future, make it a casual game about collecting clocks; for Star Wars the same casual game about collecting stars and guns.

Just watch the series, there are tons of ideas

6. In a platformer, press "up" to jump.
7. If your character can only attack straight ahead, put all the enemies above and below him. The reverse works, too.
8. Getting hit by an enemy knocks you back, and usually into a pit where you die and go back to the beginning because you're a pansy.
9. It's best if you never explain or even hint at what to do or where to go.
10. Immediately at the beginning of the game's first level and with absolutely no heads-up, put a death-dealing obstacle.
11. No continues, no saves, and really long passwords that take forever to input.
12. Every area should look the same, with no proper sense of direction whatsoever.
13. If your character is supposedly the most powerful man on the planet, the man of steel, who can leap tall buildings with a single bound, then make almost the entire game about flying through rings.

I guess I go the other way on this. Oh well, an opinion's an opinion.

I don't really think games are a great way to tell a story in the first place, precisely because video games are very self-centered as a medium, and a really good story can have a lot of mundane things. I've never felt that I was being "dragged" through a good story, only through a stupid, pointless one. A good story, crafted by a human being, also has a point, and the best ones always have to be digested more than once, and enjoyed almost every time. A good story also usually has multiple roles, and even the main character's role can be pretty "mundane" compared to what you'd expect in a video game. (For example, Michael Corleone only kills 2 people himself in the Godfather, and the most hot-headed Corleone who gets the most action, Sonny, also gets murdered half-way into the story in a very big way. So neither character would be very fun to play. It's also funny how this generally self-centered medium usually requires a love of violence to be interesting.)

I've also been told that an interactive story puts more importance on me and puts me in the story and it's all me me me. (A recent ad for Halo 4 that I saw in a movie theater (!) was similarly egregious about this.) So? Why would I want that? I'm not all that interesting, and it's not like I'm going to save a fictional world anyway, or even enjoy wrecking it.

Yes, data can be generated. That's no surprise. But in the history of all randomly generated data, it's always been pretty easy to tell that it was generated, because the data repeats after a while whatever you do. You still need to hire artists and writers to fill in the blanks and give the algorithms something to work with, and at some point, you might say to yourself, "Boy, I wish there was an easier way to do all of this..."

Tip: Making a game only for your onw enjoyment never works. If you want to finish it make it for other people to play and enjoy (or for money or for whatever other external reason not directly related to you). In a long run sitting in front of TV is more enjoyable all the time, while making games has also the dark hours sometimes you have to survive, if you are doing it just for entertainment then of course you will always quit in the middle when you encounter the first obstacle.

I like this advice. Like I said, if I try only to entertain myself, I'll go on for years and I know it. It'll drag out and I'm never totally satisfied with it (which is ironic).

If I'm writing something for someone else, I'm much more pressed to get something done. And I'll very probably still enjoy it. In fact, one of the few open source games that I would call "complete" was Abe's Amazing Adventure, which was made for its author's son as a present. I always thought that was cool when I heard it.

Here are my observations, and you can choose to ignore this if you want, I don't mind.

• Every time I see a "chosen one" story, I personally always think of Life of Brian. What's funnier? Being the messiah, or being the guy who was born next to the messiah?
• You don't know who you are? You don't know who you are?! Oh dear Brian does this cliché get to me.
• I don't see a game, per se, just a setting. I also don't see any goal or focus for this game. I'm sure you have one, so what do you have in mind?
• Who is the main character, and who is the mayor? You could very easily take what you have and turn this into a Bourne Identity sort of thing, it just might not be as interesting without some spin to it, because that storyline and much of its elements ("He's an elite spy and he doesn't know who he is") are so played out now. If I were you, I'd start by not even making the main character a male at all. Make her a female, and now she is the missing piece to something. Just for starters.
• You should know that starting a project from a story or setting has some implications for the direction of the project that you wouldn't have if you had started it, for example, with a gameplay idea. But either way, you really need some sort of goal or focus for the project, just so you can direct your blows without hitting air, so to speak.
• You're writing this in C++ and you're just learning the language. Beginning programming then? That also has certain implications. Keep it simple, okay?