We're offering banner ads on our site from just $5!
HeathMember Since 11 Jan 2012
Offline Last Active Sep 18 2013 09:43 PM
- Group Members
- Active Posts 214
- Profile Views 2,616
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by Heath on 15 November 2012 - 07:45 PM
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.
Posted by Heath on 29 October 2012 - 09:07 PM
It sounds straightforward enough that you could prototype it in Python pretty quickly.
This is a video game idea that a few others and I trying to develop.
What would make someone want to play this game or what would make someone not want to play this game?
- 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.
Posted by Heath on 14 October 2012 - 10:27 PM
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.
Posted by Heath on 14 October 2012 - 09:48 PM
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.
Hmmm... I don't know about the "Project" part of it, but "Ember" does sound sort of like "Empire", after all.
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.
Posted by Heath on 14 October 2012 - 09:45 PM
Posted by Heath on 14 October 2012 - 09:21 PM
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.
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.
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.
Posted by Heath on 10 October 2012 - 08:42 PM
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.
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?
Great idea! Maybe each level is a different scenario? New guys come in, Charlie's girlfriend left him for the company pencil pusher, etc.
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.
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.
A construction site would also offer many good ways of getting rid of the bad blood
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.
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.
And talking to them, too.
Primary mechanic? Organizing your construction teams for maximum efficiency. Certain people don't work well around other certain people.
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.
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.
I agree. Thank you!
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 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!
I really like the idea of a construction site! Modern settings have a special place in my heart.
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.
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.
Put the pressure on to get the results you want.
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.
Just my thoughts, but now get to work! I wanna play it.
Posted by Heath on 04 October 2012 - 06:30 PM
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.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.
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.
Posted by Heath on 02 October 2012 - 12:02 AM
Yeah, attrition. Relying on quantity of resources rather than intelligence, or quality of challenge.
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.
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.
Posted by Heath on 29 September 2012 - 03:46 PM
Fancy that, reward your paying customers with DLC.
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.
These two do not sound mutually exclusive to me, and it also sounds like you could tie this into Kickstarter, or something like it.
Make open source games. Ask people to pay what its worth if they like. Pirates torrent it?
Word of moth advertising! Thanks pirates!
Posted by Heath on 29 September 2012 - 02:57 AM
Posted by Heath on 20 September 2012 - 10:32 PM
6. In a platformer, press "up" to jump.
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
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.
Posted by Heath on 17 August 2012 - 03:07 AM
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..."
Posted by Heath on 01 March 2012 - 12:13 AM
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).
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.
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.
Posted by Heath on 29 February 2012 - 02:11 AM
- 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?