Majorlag

Members
  • Content count

    30
  • Joined

  • Last visited

Community Reputation

100 Neutral

About Majorlag

  • Rank
    Member
  1. The user interface could be made such that the player never really needs to remember any syntax. For instance, you could use pull down boxes to choose control structures and dynamically add other gui controls where it makes sense. Something like: (WHEN)(Skyranger is Resupplied): (IF) (Base Supplies)->(Ammunition)->(Rifle Clips) is (Less than) [20]: (ORDER) (Ammunition)->(Rifle Clips): [10] Where the parenthesis indicate pulldown boxes and the brackets indicate number fields. Imagine that the form starts with a single pulldown box and that new fields are added dynamically. Obviously the language would need to be simple enough to not overwhelm the user with options and so that it can be parsed on the fly to generate the dynamic forms. Huge pain in the ass? Yeah probably, but doable. I think a better strategy would just be to play test a bunch and add the simpler features that are overwhelmingly requested by users. Like in this case you'd just add a checkbox for "keep supply at this level".
  2. Making Turn Based games less boring.

    I once played with the idea of a system similar to a simultaneous system. The game was such that the player only had to move one unit, so you'll have to change some of the details. Each player was given 10 seconds for their "turn", which all players did simultaneously. During this time they would designate the movement of their avatar, which way he was looking for targets, and how he should react (fire, duck, retreat) if he saw any. After the 10 seconds is up, everybody's moves are carried out for 10 seconds, and then its back to decision time. Basically, it was real-time with 10 second breaks every 10 seconds. The game never really got off the ground so I can't say how it worked or didn't work in practice. Another option is to time turns (as others have mentioned), but give the players something to do during the other players' turns. If a traditional RTS was made turn based, this would be things like designating sites for new buildings, selecting research priorities, queuing up unit production, etc.
  3. Casual game - multiplayer only

    I think the key to what you're going for is that the gameplay is simple enough that anyone can learn to play well fairly quickly, but flexible enough that it can be mastered. Yeah, I know, its the old "easy to learn, difficult to master" thing again, only its even more important in multilayer because people who play casually and for fun don't want to spend several hours a day practicing their twitch skills just to feel like they have a chance at victory. A handicapping system can accomplish this, but is a bit uncreative. Mario Party does it with lots of randomness. I think the key to making a "casual" shooter game would lie in placing the emphasis on tactics rather than twitch skill. No instant kill weapons, players take a lot of shots to bring down, maps are objective based, that sort of thing. It is likely that "hardcore" players will hate it though. I've played a few mods that were on the right track, only to be turned into yet-another-twitch-shooter by a "hardcore" community pissed because their awesome FPS twitch skills didn't let them dominate the casual players.
  4. My RTS

    The savefile download wasn't working earlier but seems to be working now.
  5. What Turns The Mundane Into Gameplay?

    Quote:What Turns The Mundane Into Gameplay? Introducing a leveling system and calling it an MMO.
  6. Methinks it would be more useful to put limitations on other aspects of the game. Especially if you've never finished a project before. Writing code with only booleans is just going to be painful, not inspiring. Heres my suggestion for limiting yourself: Limit yourself to making a game that only takes about 30 minutes to play from start to finish. Limit yourself to simple sprites-on-a-background graphics, and less than 10 keys (or 8 + mouse) for input. That should be simple enough that you can actually complete it before you get totally bored with the project.
  7. My RTS

    It looks interesting, but like the others I can't seem to download it.
  8. I'm going to go ahead and say it, because the others seem too polite. I apologize in advance for being so blunt about it, but: Quit acting like an arrogant prick. You seem to think that you know everything there is to know about game design and as such believe that it is your right to have your vision made. You don't even know how much you don't know. You have no experience, no way of knowing the pitfalls of the real development process, no way to know how to deal with unforeseen problems, no way to know how to deal with outright failure. Thats why you have to work your way up, its a learning process as well as a way to prove yourself. Incidentally, this: Quote:Here's some homework: buy a deck of playing cards and make a new game with them every week. Write a blog about it. is the greatest idea ever. Be sure to do a full postmortem analysis of each game to maximize the learning. Seriously, I love this idea. I don't necessarily agree with the "stop playing so many games" thing though. You can learn a whole lot from other designer's successes, and even more from their mistakes. I'd say play lots of games, and don't be picky about which ones you try, but don't spend very long on any given one. Its about exposing yourself to a variety of ideas and thinking about why the work or, more often, don't work.
  9. I Want To Be a Game Designer...

    Why worry about programming and art if what you really want to do is design? You don't have to make computer games, there are lots of types of games out there. Tabletop games, board games, sports, card games, whatever. One of the elements that makes a great designer (IMO) is the ability to work within the limitations of any given medium. Once you have an understanding of design concepts then the medium shouldn't really matter.
  10. I just don't like the java VM. Its always seemed kludgy and virtually useless to boot. Its not a big deal. Anyways, with the new information you gave, it seems that it is a game of triage, basically. I'd guess that would be mildly amusing for a short time. The player would find the optimum priority queuing too quickly, I think, and then be bored. You could try things like having different colored balloons inflate at different rates, to give the player more options to explore in their internal priority queuing. Or have some balloons (obviously visually indicated to the player) that instead of merely popping and no longer giving the player points, could have really nasty effects, but also give mad points while inflating. There are plenty of options for expanding the concept.
  11. I'll be honest: I didn't actually play your game because it appears to require java, and I detest java, so I don't have it installed on my machine, and the machine I had access to with java didn't like your site in either Firefox or IE, so I'm just going to use my imagination. I'll try to describe my thought process in detail so you can see what assumptions I've made that may be wrong. Of course, I may be so totally off-base that nothing I post here will help in the slightest. It seems that the problem would be that total amount of... well I guess helium or air... in play would always be increasing. I can temporarily reduce a balloon's size at the cost of spreading out the lost air to the other balloons, increasing their size slightly and keeping the total amount of air the same (which then increases on its own). This system, obviously, will reach a point where it will be impossible to continue. If you think about it, this isn't all that different from a game everyone is familiar with: Tetris. The field of play in Tetris is always gaining blocks, and you merely get to arrange them and delay the inevitable collapse of the system. Except of course that Tetris offers a way to continue indefinitely by removing blocks from the field when they form a complete horizontal line. Like I said, not sure if that observation will help since I haven't actually played your game.
  12. Ideas are cheep. Everyone has one and a good number of them sound good in theory even though they're terrible in practice. Actually designing a game that people want to play is hard, the same way writing something people will want to read is hard, the same way painting something people want to hang in their home is hard. Its not all plot devices, macguffins, level design, and texturing. Those are all parts of a game, like background music is part of a movie, but there is a core element that remains when you strip away all that and it is usually referred to as gameplay. Thats where the real magic is, thats what people play games for, and I didn't see anything about it in your post. It sounds to me like what you have is ideas for a story. Thats fine, but don't think thats all you need. BTW, game companies do look to the community. At least the good ones do. The CS and TF teams were hired by Valve (IIRC), for instance.
  13. Alternative Visuals - Feedback Needed

    I had a similar idea a while ago where I was considering how I could allow a certain game to be accessible to blind players. Nothing ever came of it, but I was reminded of it when I saw Be The Wumpus on happypenguin.org, and of course again with this thread. Anyways, aside from providing an accurate simulation of how sound works it seems to me that you would also have to take care to train the player properly early on so that they won't be overwhelmed by the complex interactions of sound and environment later on.
  14. Deliberately poor graphics?

    I'm in the same boat as the OP. I didn't get excited about the PS3 or XB360 because all the ads emphasized their ability to deliver awesome graphics and the games that were confirmed for them were mostly sequels with better-graphics-itis. Of course, that means I have to wait for Braid. Anyways, I find that as long as a game has a consistent style to graphics, the fact that it isn't using the latest in $500 video card rendering technology is ignored. Take for instance The Power (http://www.64digits.com/games/index.php?cmd=view_game&id=4751) or An Untitled Story (url=http://www.gamemakergames.com/?a=view&id=6278), for example. At least thats true of the kind of people worth making a game for. There will always be a segment of the population that lives on hype and "good graphics" and makes games like Halo successful.
  15. Complexity vs Simplicity

    I agree with what others have said here. A lot of complexity can arise from seemingly simple systems. Just look at Go. Its very simple to learn, but the simplicity of its rules leads to a system so deep and complex that the best Go playing computer ever only managed to beat a professional (8p) with the help of a 9-stone handicap (compared to earlier computer performances, this was a radical improvement). Another example is Conway's Game of Life. Again, very simple rules leading to complex results (it is actually turing-complete).