RTF

Members
  • Content count

    189
  • Joined

  • Last visited

Community Reputation

127 Neutral

About RTF

  • Rank
    Member
  1. Sword of the Samurai did this to some extent - the stats of your current character were conferred to his son once the parent got killed(and if you didn't have a child it was game over) But the son would always have lesser skills than the parent so you had to train him up again. It was more like having extra lives than anything else.
  2. RPG design question

    Well, just look at what's going on with the data in each method. Doing it your way, you'll lose whatever was going on in the last state and start from a blank slate each time. This is probably fine, if it's a first game. Doing it the book's way just involves extending the state concept so that it can save detailed information about where it was - and if you have a complex enough engine that can be useful. But it's really more of a thing that you add when you come to a point where it's needed, than a "must-have."
  3. It is often said that games should be easy to learn so that new players can "jump right into" the action. Recently I've been through a couple of discussions that refined my ideas on what makes a game enjoyable after the tutorial-mode phase of "these are the basic concepts." I think learning plays a substantial role, and I think this may be an excellent test for defining a "good" game. I haven't found a failure case yet. The general idea that I've whittled it down to is that, in an ideal game, each progressive step in mastering the game should feel as accessable as the previous one. Players should be able to evaluate their progress easily. Advancement should help to uncover new aspects of play, and ideally should offer some sense of accomplishment. My rationale is this: Players are not frustrated by chance failure(unless it's of the kind where you lose some game record of your progress like stats or plot advancement, or when failure is built into specific mechanics). What *does* make them frustrated is repeated failure and being incapable of understanding why, or how to overcome the specific challenge. And people can become addicted to a game they otherwise hate because they always think advancement is just around the corner. In FPS games, there is a division between obvious failure(in straight deathmatch) and non-obvious failure(the realistic/semi-realistic games). When I think back to games like Counter-Strike, it now seems like everyone playing is gambling - hoping for the big round. Few people have any idea of how to advance their skills, so they let probability do the work for them. Sooner or later, the big round comes, and there's satisfaction, but it's only temporary. Games like Quake don't allow this because the skill division is always entirely clear; no(or infrequent) teamplay, no randomized shooting, and a complete focus on comparing abilities. As a result fewer people play the traditional games now because it's painfully obvious just good a 'good' player is, and the learning process feels particularly arduous since it requires going out and getting beaten over and over. In any RPG the advancement is almost entirely through stats and plot; this makes them very accessable to anyone who is willing to put in the time, leaving only the caveats of grind. In Bemani(music games), the progression from the most simple songs to the most complex ones and the process of getting perfect scores is always straightfoward; reading abilities, dexterity, and timing are all tested in as direct and obvious a fashion as possible. The difficulty and grading systems always leave enough room(up to the designed limits) so that advancement is "just around the corner." For most people, it really is; the component skills are practiced 100% of the time the game is played, with very little downtime, so even small, irregular play sessions can add up. Anecdotally, many players of these games claim not to have started out with great interest, but found it so addicting that their interest became second-nature. The reason why our tastes in gaming all vary, if this concept is taken as fact, must be because of our differing learning abilities. Only a minority of people will ever be great at any one game, but people are turned off not by their maximum potential, but the marginal difficulty of advancement. Whether or not the game is actually easy isn't really the issue; it's the illusion of accomplishment that's the key. And the most accessable games will offer this hope to a broad range of players. Also, this implies that story and scripting aren't really factors to help or hurt replayability unless they are constraining the game's challenge. If by the end of the first game the player is playing to finish and not out of addiction to the gameplay, they aren't likely to play again unless they can easily return to some area they liked or make a different choice.
  4. The RPG-maker program I have in mind is based in spirit on the groundwork laid by Stuart Smith's "Adventure Construction Set" and Chris Hopkins' clone-of-sorts "Adventure Creation Kit." It is written with Python/Pygame, will be public domain open-source, and should have a project set up to develop a community and continue improvement when I get it to a releasable state. The main thing I want to preserve from these two programs is the great accessability they have both for the player and the creator; the core gameplay is kept to the basics of dialog, puzzles and combat with only one PC controlled at a time. Premade graphics and object definitions make quickly setting up a scene a simple matter, while the customization abilities are good enough to keep each game unique. Games made with them are roughly described as "light-RPG" and they both really hit a sweet spot for me when I was younger. (But ACK was newer and more powerful and so preferred, albeit buggier) What I would like to do is to find a starting point where I can do what the earlier programs did, but a little bit better, with room to non-destructively expand creator power later. GCS and moddable-game design is a field that isn't often touched here, but is worthy of a lot of consideration - I believe it straddles a line somewhere between software architecture and game design. This post is in part meant to help me work through my own design and make clear the parts that aren't clear yet. So while I would love to see commentary, I do this for myself ;) Both programs lay down some pretty solid ground rules: the game is, in a general sense, turn based(although in ACS there was a real-world time limit, linked to your per-turn movement allotment). The maps are strictly tile-based 2d maps, with only "chunky" movement within the grid allowed. The combat system is fixed and has little nuance to it, but remains fairly flexible because of strategic differences in weapon abilities as well as simple numeric changes - for example, in ACK you can define "cone," "beam," and "bullet" types of ranged weapons. In both programs the game is primarily made within an IDE that uses simple list and menu choices and built-in tile and map editors. Much of the gameplay is produced through the elegant use of "have item," "on use" or "on drop" commands built into objects - with these you can unlock doors, mine for gold, read scrolls, etc.. ACK also has a classic Ultima-type dialogue engine, and very basic scripting abilities. The specs written into the code as of now are something like this: -Chunky tiles and turn based system, as in predecessors; one upgrade is the use of time units as in some Rogue-likes; each turn an actor takes one action, but their next turn only comes around after so many time units have passed dependent on stats and the last action. -All game objects("Things") are given a Python dict(hash table) of properties that are relevant to gameplay. Many properties are assumed by the engine to exist in the current code. Part of the plan is to allow gameplay scripts(which are an undefined thing atm) to exist as a property. So an example Thing might contain: "name"::"Man" "isalive"::"True" "desc"::"Some average joe." "tile"::"man" "strength"::5 "dexterity"::5 "talkto"::("dialogue", "joe") "death"::("drop", "gold", 1) Something I just came up with while working out this example is that I can pretty easily parse the tuple objects - the ones in parenthesis - as more complicated actions, without necessarily making it the de-facto scripting language. Instead, I can get by with built-in actions like "dialogue" and "drop" at first, in effect duplicating everything the earlier programs were doing. Then, later on, I can introduce "script" as an action to maximize flexibility. Another thing is that while there is a human distinction between attributes like "dexterity" and actions like "talkto," this isn't going to necessarily be seen by the program. Some actions could return values and trigger other actions. Pretty complicated stuff. -Map tiles("Blocks") are also given properties. Until just now, I was going to include additional property dicts for per-turn and on-entry events(to change the values of the affected Thing) but that could instead be handled as an action or script in the main property dict under "perturn" and "onentry". See, writing these things helps! -Combat will start fixed. Later it may turn into a script...but the issue there is with graphical effects. It'll require the addition of actions for all sorts of effects to duplicate that functionality. -The interface will also start fixed to match the combat system. This too can probably be changed later. -Things like inventory and the general turn-based-movement procedure will probably stay fixed. Some items I need to think about more: -a simple yet flexible combat system to start from -vehicles and how to make them work -portals to different maps -multi-tiled things(like large enemies....or vehicles maybe) -various user-interface choices
  5. Variations on a theme.

    I'm not entirely sure, but it sounds as if you want to take the existing gameplay of these classic games, preserve it 100% and slap some theming over it. If that's what you really intend -- well, I've seen it done before. You don't want to try, and here's why. For games with designs as simple as Chess, the abstract gameplay is central to the experience. In those cases, the game has lasted so long because it defies the requirements of setting or story. Theming is a luxury; the players, unless they are completely new, are interested by the board positions and opponents, not the grain of the wood or the quality of the gold plating on the pieces. Consider a different, more modern type of game, such as Tetris. Tetris is not made significantly more interesting through the graphical effects unless you are about 5 years old, no matter how many fireworks or sexy ladies you cram into it. It's the same problem in both cases. That doesn't mean that theming is bunk in all cases, though. But you absolutely *have* to start meddling with the gameplay, and link them together, for it to become meaningful. What theming does is build a two-way bridge between the real world(or fantasy worlds) and the gameplay; we can both learn from it, and put our previous knowledge into it, by associating the theme with the game effects. If there's an imbalance there, where there's too much theme and too little game, or too much game and too little theme(generally not the problem - we can theme almost any game), it becomes unsatisfying; our minds will have to work harder to play the game properly. That's no good; better to add something special to the gameplay and try to make it a memorable experience.
  6. I think the move to "managed code" is inevitable for most programmers - unless you're working on a very low level. Even then it might end up that you get microchips that run the appropriate "flavor" of bytecode in a native form. Defeats the point of virtual machines but there were LISP machines back in the day too... Whether it's C# or C++ or Python, I dunno. All three are ALGOL derivatives, so there seems be a natural progression in going from one to the next; Python is the "slowest" at the moment of course, but I'm a big fan of it for hitting the target of "simple yet powerful," and it lets you put in C modules, so with you can get equivalent performance in the input/output area as any project in C using the same libraries. For an indie working in 2d, PyGame is a perfectly acceptable library, though software rendering performance at high resolution/color is limited if you make a scrolling or other render-heavy game.
  7. Indie Developing

    Having existing material changes the situation a little. That means you should be able to draw on those communities for some help. Also, if your goals are modest enough, BYOND might be helpful: http://www.byond.com/ It's not pretty and has a somewhat inflexible feel, but it's a decent platform for online games, and it has a lot of tools to assist you; graphics and map editing, a built-in programming language, even some hosting IIRC. I don't know their community very well, but if you ask there you might find people familiar with it, who might be better persuaded than the jaded hotshots around here ;)
  8. Quote:Original post by Wavinator Unfortunately, I think you have the same problem, whether you broaden or deepen your world. Either there is more territory, or the small amount you have is filled with many interaction points, all of which have complex rules and stats in order to foster a wide variety of interactions and strategies. ... If you want a small world that has a lot of offer, you're going to have to deepen something. Perhaps you make a bazillion NPC behaviors, or items that can be combined in a multitude of unique ways to get past environments whose stats alter. Your other alternative is to create really pretty, really simple games without much depth but which you or players can frequently update in some meaningful way (I'm thinking of all the Soul Caliburs). You play to people's desire for fashion and style, like Soul Calibur did with its costumes and one unique character per console (Link, Spawn and I forget whoever else). OK. Here's something I got once I thought about it some more: everything takes some amount of content, but there is a cost/benefit ratio that depends on the kind of content and the player - and, this is the big part: all kinds of content have diminishing returns, and the rate of decline depends on how spread out the content is. Story is an example of how this works; a few lines of text vs. million-dollar cutscenes - in the end, you still save the world, and there ain't much getting around that. But small scraps of stories(detail), we know, can add up to a greater effect than one continuous epic quest(breadth), because the epic has to be very predictable to continue for so long. The smaller stories can vary a lot more, so they are more novel. Mini-games? Same idea; Wario Ware would be crap if instead of having dozens of "barely-qualifies-as-games" it tried to make four "big" mini-games. Secrets? An exception, maybe. Secrets tend to become less unique as they get more common, as there is little difference between getting 10 coins or 20 coins. But in general having more secrets seems to be a good idea, so long as they are not overblown and overemphasized as in Donkey Kong Country, where they become a percentage statistic, rather than really being "secret." This is probably what led me(subconsciously) to say that we needed to talk about "small" games, because they force you to split up your content usage.
  9. Indie Developing

    There are no shortcuts. Getting other developers requires a fair exchange, which means you have to bring something very definite to the table. That doesn't mean ideas - it means skills, including leadership ability. Once you have a team together you can discuss ideas and come to an agreement. But drawing together a group through the vision alone won't work; that's the stuff of fairy tales. Unless you were doing a clone, something already tangible, nobody would be interested enough. Nobody can share your own vision, which means that only the lone developer can succeed in crafting a "pure" design, one that was tossed around by nobody but himself. The trick to getting something done is to take each aspect of the development process, and over time make it something that you "get the urge" to do. Even if you say it's something you're not good at, if you keep at it you can cultivate an interest in anything. From there you get skills, and with skills you won't need other people.
  10. Big(or "Huge" as the case may be) worlds are overdiscussed here. What features would you add to deepen a small game world, one which is restricted either by setting(space station, island), or gameplay (rail-shooter, one-on-one fighter)? There are three "traditional" ways of deepening the world that I can think of: The main traditional method we all know about: story. If it's integrated well with the game, it can work, but I think it's treated too much as a "band-aid" solution. Unless it's the overwhelming centerpiece(as in a Final Fantasy, adventure game, etc.), the story only helps a game that was already good. Another old standby is the mini-game. It's a nice way to relax the tensions of the main game, and perhaps tie back into it with a reward or needed item, but it's not really something you build the game around, which you can at least do with the story. Finally, there's the secret. By pushing every wall or somesuch, you can get a little trinket. It's a pretty worn-out trick by now, at least to an older player. How can we expand on this list? (Remember, an answer that needs more content isn't an answer because it'll make the world bigger)
  11. a question about game art

    I don't know how the MS sprites were done, but I do know about the technique Capcom used in the original SFII(which many fighting games since have copied). They started with simplified line drawings, ones that would translate well to pixels. Then they scanned those, scaled them to fit, and drew the pixel outline over them. It's not the only way - you can start from scratch of course, or trace over a real photo for a rotoscoped look - but it's what worked for their production process. MS has smaller sprites so I would suspect they went from a character design straight to pixelled outlines. Once you have the outline, it comes down entirely to the artist's pixeling style and talents. You can use colored outlines, no outlines, anti-aliasing....and of course, nobody will shade anything in quite the same way. Traditional shading tries to get the most out of the smallest palette to avoid hitting technical limits, but you can ignore that and use Photoshop brushes these days, if you want :P If you are patient enough to make a good outline and have gotten a feel for how to shade objects(which can be transferred from other visual arts) then you will be able to do a good pixel; but it can take a very long time if the sprite's big! There are more resources, tutorials etc., but I don't have links handy; just go search for them, they're out there.
  12. Regarding Winning...

    To make a good game ending, it generally has to be a good story. Not in the sense of 'great literature' but it has to have conflict, rising action, climax, and then resolution. Where most games fall down is in properly building the rising action, and then in making the resolution satisfying. This is one of the reasons why games generally have to get harder as you go along - otherwise you would have no sense of release from the resolution. Similarly, the resolution can have its own gameplay; it's an opportunity for the player to reflect on his accomplishments, and the game can cater to those needs by showing the consequences of previous actions, a "where are they now" sort of thing. Statistics and gratuitous fireworks are aids in letting the player sit back and sigh following this great release of tension. The player must agree that the game really was over, as well. This means that the basis for the gameplay should come to a complete stop following the resolution; if for example you were shooting people or commanding armies, you should have no reason to anymore; the war should be over. If that doesn't happen, the player's left empty, his personal story unfinished.