So I was thinking about piracy and DRM the other day, valid concerns for any indie PC developer. Piracy of straight-up PC games is rampant nowadays, even more so than when I was a kid copying games from my friends. Indie developers in particular don't have the resources to implement complex DRM schemes, patrol the Internet looking for readily available pirated versions, or sue anyone who does pirate the games.
Now, I won't get into the morality of piracy or anything along those lines, but I will say that, as a developer, I want people who play my games to pay for them. So, I had the brainstorm: MMORPGs (Massively Multiplayer Online RPGs) eliminate the piracy problem by moving all game logic onto _their_ servers. Why not do the same thing for a single-player game, and introduce the SPORPG (Single Player Online RPG)?
Now, there are various levels to which one could take this (hairbrained?) scheme. I could keep all game logic, levels, and everything on my server, and implement the client as just a dumb rendering client. This approach would virtually eliminate piracy; only someone who duplicates (or actually breaks into my server and steals) my logic code, levels, etc, can pirate the game. But, now I've got to deal with a lot of the MMORPG issues, like network lag, synchronization, etc.
A simpler design would be to treat my server as something like a secure file server. The game logic is run on the client, but whenever the player enters a new area, or perhaps even when he encounters a new type of creature (or whatever), the client goes to the server and asks for the level file and any associated assets (like graphics). Naturally the server would require a valid login, and could perform security checks like making sure a bunch of people aren't using the same login.
I like this simpler design, because it really wouldn't be too tough to implement. Piracy would be possible; if the pirate retrieves all of the levels and assets from the server, he could then hack the client code to have a non-online version of the game. However, if he missed some parts of the game (in a non-linear RPG, this is entirely possible), his hacked version would be gimpy; a player exploring parts of the game that he missed would get a broken experience.
So, from the player's point of view, positives:
The game has basically implemented auto-patching of game content; the client would just grab new level and asset files as needed. Bugs in the client executable would still need some sort of patch program to run, though.
The player's games can get saved online; no worry of lost files or whatever. In fact, as long as the player can remember his account, he can switch between computers, with seamless game saves.
The demo version of the game would be the same as the full version; all the player needs to do is create (and pay for) an account and he can access the full content, right from within the game.
I could easily implement community features, like online, player-generated hints, online high-score lists, chat, whatever. Since we're online, it's just a matter of how much code to I want to write.
The player has to be online to play. In some ways, this really sucks. But maybe in this day and age, it doesn't suck too much; isn't anyone who is going to pay money for an indie-RPG likely to have a decent Internet connection?
Level loading could be pretty slow if the game is trying to send a bunch of content. We can keep the files pretty small, and be careful about not re-sending files, but there is an issue here.
Oh well, just a brainstorm I had. Not sure if I'll do anything with it or not.
Merry Prankster Games announces the release of 10 Fantasy Fights version 1.0 (Beta)! More information or download here:
10 Fantasy Fights is a demonstration game by Merry Prankster Games. In 10 Fantasy Fights, you control a party of adventurers though a series of 10 fights designed to exercise all aspects of the SENG game engine. You will rapidly advance from a simple battle of a single inexperienced warrior against lowly minions, all the way to controlling a mighty band of legendary heroes against a near-invincible demon lord.
10 Fantasy Fights is a single player computer role-playing game for computers running Microsoft Windows. 10 Fantasy Fights is evocative of the classic CRPG games of the 90s, but updated to run well on modern computers, using modern technology.
Pause-able, Real-Time game-play - 10 Fantasy Fights runs in real-time for maximum realism, but allows you to pause the game any time to issue orders to your adventurers.
Party-Based - In 10 Fantasy Fights you control up to 4 main heroes, and can control additional summoned creatures.
Custom Game System - 10 Fantasy Fights uses the custom SENG RPG system, which will be familiar to pencil-and-paper RPG players, but updated to work well in a real-time computer environment.
Character Development - 10 Fantasy Fights features over 80 skills, hundreds of spells, and hundreds of items to customize your heroes to your liking.
3D graphics - 10 Fantasy Fights uses a fully 3D graphics engine to provide a detailed, dynamic environment for your adventures.
Varied Adventure - 10 Fantasy Fights will lead your party through 10 fights with widely varied environments and tactics.
Free - 10 Fantasy Fights is a demonstration game, and is free for your enjoyment. Please give Feedback on the game so we can improve our games in the future.
Give 10 Fantasy Fights a try! http://www.prankster.com/10ff
Temple of the Abyssal Winds, the classic-style single player role-playing game, now with Mac support!
You can download it for free in the Mac App Store, or get more information (including for Windows) on the TotAW website:
(If you have any more ideas where I should announce 10FF, please feel free to drop a comment or email!)
Well, a few people have downloaded 10FF now, but so far the only feedback I've gotten is a sarcastic thread about my use of "real-time" and "realism" in the announcement I wrote. I must remind myself that this stuff takes time.
So, how many times have you hit this in an RPG: You're the latest in a long, familial line of butt-kicking heroes. Roegner Smashfist the Fourth, or what have you. You complete a character-specific quest, and win your ancestral sword, wielded through the years by your completely awesome paternal forefathers. "At last, the Greatsword Mighty Dragon Chopper is mine, as it was my father's before me!" But then, you level up a few times, and all of a sudden "Mighty Dragon Chopper" isn't quite so mighty any more, and you replace it with "Longsword +2" or some such nonsense.
Why, the last RPG I played through, NeverWinter Nights: Shadows of Undrentine, had just that. I picked the dwarven thief/priest as my henchman/companion/whatever. Dorna, maybe? Anyways, there in her inventory was "Dorna's Axe". Or maybe it was a hammer. I never had her use the thing, but I loyally carried the axe around for the whole game. Maybe she was attached to it, or, who knows, maybe later in the game the thing would turn out to be important. It never did.
Anyways, my point is that throughout fantasy in other media, a character is often defined, at least in part, through some part of his equipment. King Arthur had Excalibur, Bilbo Baggins had Sting, Xena the Warrior Princess had, well, to tell you the truth I never watched that show, but I bet she had something. But in the computer version, characters are regularly cycling through their equipment as they find bigger and better stuff.
In terms of gameplay, for an RPG where the character is progressing in levels and power, it totally makes sense for the equipment to improve as a part of the logical flow of the game. But thematically, it is a big limitation for the characters to always be turning over new equipment. There is a definite conflict here.
Describes how Lord of the Rings Online (LOTRO) has implemented a new system of "legendary items" that level up, improving in strength and adding new powers as they go. Part of the design involves finding new items (gems or somesuch) that you find in the game as treasure, that you can meld into slots on your legendary item giving new powers. So the legendary items are sort of a hybrid of allowing you to level them up in a controlled fashion (like a typical character system), but also maintaining the "hunt for treasure" aspect of equipment collection that is important to most RPGs.
I think this design totally maps over to a single player RPG as well as a MMORPG; in fact, it could map even better, as the items (and item level-up quests) can be tailored much more carefully, story-wise, to the characters than they could be in a MMORPG. Add it to the list of SENG features! Sadly, probably for v3 (I'm working on v2), as I have more than enough to do in the engine, let alone actually making a full SENG game.
So, pathfinding has been a long-time issue with my SENG engine. The traditional pathfinding I've used is heuristic based. Something like:
Move straight towards the target.
If you hit a wall, walk along the wall until you pass the corner of the wall, and then go back to (1).
If you hit something else while walking along a wall, turn around and try to go around the wall the other way.
If you hit another actor, pick clockwise or counter-clockwise, and go around that actor until you are clear of the actor.
Generally, pick the direction that will be the shortest path to the target.
However, if the actor is already going around _you_, pick the same direction as him.
If you hit another actor while doing this, go the same direction around the second actor.
If you hit something else (wall), switch directions.
For example, in this picture, the actor wants to follow the green arrow. It will follow the red path and successfully reach the target:
This heuristic works very well in many situations. It goes around actors and pillars very well. And (also important), in terms of performance, it is very inexpensive.
However, there are a few little issues. The first is that when an actor runs into a long wall (sadly common in things like houses, castles, etc), if he chooses to go the wrong way, he wanders off into the distance aimlessly. Actually, not aimlessly... very directly and without pause.
The second, and even more annoying, is that if the actor runs into a little indentation in a barrier, he will happily run back and forth within that indentation pretty much forever. This is bad when the barrier is a wall, but if it is something like a river, the actor may be mere feet from his target, with the path to the target in plain view for all, but he simply bounces back and forth.
For example, in this picture, the actor wants to follow the green arrow. It will follow the red path, and run back and forth forever:
The final straw for me was when I discovered such an indentation on the last level of 10 Fantasy Fights. It is entirely possible to get the Big Bad Boss stuck in this indentation, and shoot arrows at him until he drops, at no danger to the party.
Next time: What I did about the pathfinding issue.
In it, a critic of his "Frayed Knights" demo proposes the option to eliminate the town level altogether, replacing it with simple menus for shopping, and cutscenes for plot exposition. This is certainly a reasonable suggestion; as a game designer, you should always be looking to cut out extraneous gameplay that slows down (and bores) the player. If a town could better be modelled as a set of quick-acting menu options, the player can get through his shopping and what-not, and get back to the action quicker.
A couple of examples of this:
Sid Meier's Pirates (both new and old) use a menu system for towns. In this case, the player can flow easily through the town options, and the quick flow through the menus is well suited to the lite-RPG system with simplistic shopping and quests. From http://compactiongames.about.com/library/screenshots/blscreens_piratesscr10.htm:
On the other side, Freelancer had a gorgeous, fully 3D, animated system for modelling the space-ports. Your character would walk around, interact with various NPC characters; your spaceship would launch from the space-port. However, the choices that a player could make were quite static, nothing more than a simple tree that could easily have been presented as a set of menus. Ultimately, I became bored and frustrated at having to watch the same animations (pretty as they were) over and over, when I just wanted to buy a bigger gun and get back into space to blast some more bad guys. From http://www.firingsquad.com/media/gallery_image.asp/82/5:
On the other hand, many games model their towns as just another level, using the same gameplay as the rest of the RPG. For instance, in the Infinity Engine games, your party walks around the town (same as a dungeon), and shopkeepers are the same kind of object as a monster. So, to shop, you walk up to the shopkeeper and initiate conversation, at which point you may talk to the shopkeeper, or you may enter into the shop interface.
This gameplay was very effective in Baldur's Gate 2, where the town was an active location of adventuring. From http://www.sorcerers.net/Games/BG2/Screenshots/image.php?image=Baldr025.jpg, the party in the theatre of Athkatla, where they can end up launching a quest from the basement:
On the other hand, from the same series, in Icewind Dale, the developers spent a lot of time creating a beautiful town nestled amongst the roots of a giant tree (can't remember the name of the town, sorry). However, while there were a few quests and encounters of note in the town, the thing I most remember was my characters running from one side of the map to the other, zig-zagging through roots the whole way, just so I could sell some loot at the store, or buy some new healing potions. This would have been a much better experience if the town had either been simplified into a smaller, easier to navigate map, or replaced completely with a simple menu system. From http://www.sorcerers.net/Games/IWD/Screenshots/image.php?image=SP_IWD044.jpg:
So, as a game designer, there are two main considerations you need to take in your design. The first, obviously, is in good gameplay, whether it be streamlined or deep and nuanced. If the town is just a place to shop and pick up quests, then a menu system might be a good idea; the player can make her choices quickly and clearly, and get to the action quickly. On the other hand, if the town is an integral part of your game, with interlocking quests around every corner, then modelling the town as part of your main gameplay can definitely be a good approach.
The second main factor is cost; important for all designers, but maybe more so for indies. The simplest menu system is pretty inexpensive to implement. However, what about the cost of art? If you have ten different towns, do you need different art for each town? Does each NPC need his own portrait? And, if your main game interface has a lot of animation and interaction, maybe your menu system needs to have 3D animated graphics as well (like Freelancer), to avoid looking ghetto. At the same time, designing a level for each town may be expensive as well; unless each town is providing nuanced interaction and choices, maybe a full model is too expensive, and a simpler menu system would work well.
As for my project, "Untitled SENG Game", I considered two main options. First, obviously, is to just make the town use the existing gameplay engine. The second option is to use the (existing) overland travel interface to provide a menu system for the locations in the town, and jump directly from there into either a small level for a location for an inn, or right into the conversation interface for a simple shopkeeper. Either of these options is relatively inexpensive; I can design town levels pretty easily, so using the gameplay engine is not too bad. And I think I can produce decent overhead maps of towns in a reasonable amount of time, so the travel interface would work OK as well. (If I had to produce decent art for street-level town views, I'd need to hire someone, and the cost would go up dramatically).
In my case, I really enjoy the nuanced gameplay in something like Baldur's Gate, where the town _is_ part of the game, not just a shopping menu. So, given that the costs are relatively sane for either option, I prefer (for this game, anyways) to use the gameplay engine for the town gameplay. If I were making more of a hack-n-slash game like Icewind Dale (or, even more so, Diablo), I would go with more of a menu approach.
Well, after much effort and convolutions, here is the pile model from 10FF rendering in the iPad simulator:
Although I don't have texturing, lighting, or animation working, this is actually using the game's rendering code, which is a big accomplishment. Adding the proper rendering stuff in should (cough cough) actually be relatively easy, because it's just a matter of plugging in the iOS specific bits to the already functional graphics rendering code.
I discussed the "Escape Problem". Today, what can an RPG designer do about it?
Certainly the easiest solution to the Escape Problem is to do nothing about it. Instead, just treat the problem as a normal part of gameplay. If the player can exploit Escape-type behavior, that's just good strategy on his part! If the monsters can exploit the behavior, that just makes them all the more dangerous. Roguelike games often take this approach to the Escape Problem.
Game Design Around It
A designer can also tackle the Escape Problem by designing monsters and levels to mitigate the problem, instead of trying to make up game rules that solve the problem generally. An example of this is the boardgame Descent:
In this case, the player characters can perform two actions on their turn, while monsters can only perform one, so "hit and run" behavior (part of the Escape Problem, as I defined it in the earlier post) by a player is expected and normal. The game works around this by providing the monster player with lots of expendable monsters (fodder, so to speak), to attack the players with; the monster player is meant to try to surround and overwhelm the player characters, rather than fight them on an even footing.
Allow Moving Targets to be Attacked
Another potential solution is to allow a character to attack a target if the target was recently in range, even if it has since moved out of range. For instance, in a real-time game, it may be that A starts attacking B (and displays the attack animation), but then B moves out of range before the attack completes. We could just allow A to finish the attack anyways, eliminating a lot of the Escape Problem behavior. As far as I can tell, the Infinity Engine (Baldur's Gate, etc) games take this approach to some degree.
One negative to this approach is that we trade a gameplay problem (the Escape Problem) for a display problem. Now A appears to strike down B even though A's sword clearly doesn't reach B. This behavior is apparent in the Infinity Engine games as well.
Yet another solution is to add to your game design a system of "Opportunity Attacks": if B takes certain actions within range of A, A gets to attack B even if it isn't A's normal turn to attack. A concrete example; if B tries to run past A, A gets a free attack on B outside the normal context of A's turn.
I'm most familiar with this system from Dungeons & Dragons, though I believe the original concept of Opportunity Attacks came from tabletop miniature gaming. It makes a lot of sense in turn-based games (like D&D), though computer RPGs based on D&D (like Neverwinter Nights) have implemented an Opportunity Attack system as well.
At last, my own solution to the problem as implemented in the SENG engine. As soon as an adjacent character A initiates an attack on character B, B gets "stuck" to A and cannot move until A's attack completes. Thus if B decides to move into range of A, A is guaranteed to be able to complete at least one attack on B, even if B would normally be able to move out of range. Once the A's attack completes, B is unstuck and can move again.
There are some other minor details: A gets delayed briefly after attacking so B can escape if he wants. Also there are some additional rules in the case of multiple attackers. But I've been quite happy with this system, as it allows characters to run away (or past) enemies, but allows the enemy to delay and attack, thus mitigating the most exploitive consequences of the Escape Problem.
I hope this discussion of the Escape Problem, and possible solutions, has been useful and interesting. As you design an RPG, you must consider the problem to avoid imbalance and exploitive behavior, but there are many ways to deal with the problem in your designs.
The RPG Anvil column deals with the design and development of CRPGs, and is published whenever I can convince my lazy ass to type one up.
I had to show a screenshot of the very start of the beginning level, as I don't have the touch events wired properly yet and you can't move at all. The discerning eye will also note some face culling issues. And perf is crap. But definite progress.
Figured out (I believe) the issue with the app store. My code was barfing on displaying the chapter price, in a non-US locale. I still couldn't get the bug to exactly manifest, but by changing the locale (in code), I got it to blow up in the same place as the crash report from the app store review. So, here is TotAW displaying a chapter price in pounds.
I found some other places in the code that might have similar issues, and fixed them all.
So, back into app store review, as soon as I do a little more testing, and fix a couple of other minor issues that came up in the meantime.
Let's see how I stack up! Bold if I've played it, Italics if I haven't.
Dungeons & Dragons (PnP) - Haven't played in, oh, 25 years (not counting computer versions), but definitely where it started for me.
Wizardry (series) - Not sure why this made it instead of other like minded games like Bard's Tale. I guess the series went on longer. I'm guessing not worth going back to play now.
Ultima (series) - I've completed 4 (a classic), and played 3-7. I really should go back and play 7 all the way through.
Wasteland - Awesome, awesome game. The setting (post apocalyptic) made it really novel.
D&D Gold Box series - I finished "Pool of Radiance", and played another one or two. These were competent, but less engrossing for me than some others.
Quest For Glory - I played a bunch of the Sierra adventure games, but not this one.
Might & Magic - Played an older one, never finished, didn't really make a big impression.
Nethack - Never really caught the Nethack bug; preferred Moria or Angband, or even old-school Rogue.
Elder Scrolls (series) - Finished Morrowind. Fooled around with Daggerfall, but after it was too dated to be much fun. Waiting for a more powerful laptop before I take on Oblivion.
Baldur's Gate (series) - Still the best single player RPG I've played. I'll avoid waxing poetic so as not to bore regular readers, who have probably heard enough about BG already.
World of Warcraft - Can you believe I've never played this? I really should, just to check out the craftmanship if nothing else. But I never have had the time or desire to get sucked in.
Well, I haven't played a single one of these, so no point making comments. Here's the list:
Mother, a.k.a. Earthbound
Square's 16-bit RPGs
Tales games (series)
I suppose I should go back and play one of the Japanese RPGs, just to see what's up. Final Fantasy 7, maybe?
Anyways, 8 for 21. What kind of an RPG designer do I think I am, anyways?
I'm going to link myself today. Some years ago, I ported the roguelike Omega to Windows. Today, I packaged up the source code (someone finally asked); link here:
Omega is a roguelike game which started a few years after the genre-defining games NetHack and Moria (later Angband). Omega features exploration, with a countryside map, whereas in most roguelikes the path is pretty well defined (down the next set of stairs). In addition, character development in Omega is partly driven through interaction with the world, not just a matter of gaining experience and levels. (I've heard people refer to this as "plot", though that might be a bit of a misnomer). I don't have any direct evidence, but I suspect the design of Omega was influenced by the Ultima games (maybe Ultima III?), merging that with roguelike sensibilities.
From a game design perspective, on the one hand, Omega is very compelling. The exploration aspect is very well done; there are many interesting locations to visit and discover, all with their own unique identities and rewards. The impression you get of influencing the world is wonderful; for instance, all of the guilds have their own Head (the Duke of Rampart, for instance), but if you progress far enough, _you_ become the Head of the guild. Now, if you look pragmatically, not that much changes in the world when you do ascend to that position. For me, at least, these features give the illusion of a deep and fully-realized world that is often lacking in even large commercial games.
In addition I should note that Omega hasn't undergone active development in quite some time, and was never that popular, so it has suffered in comparison to more popular roguelikes. The inventory system is byzantine, and now-standard features like line of sight, or intelligent running, are absent. Monster memory? What do you think notepad is for? So, if you're looking for a great, polished game to play, Omega might not be for you.
Ultimately, I would categorize Omega as a fascinating failure. The design of exploration, both of the world and the game system, is really interesting. Unfortunately, paired with the permanent-death style of roguelikes, makes for a frustrating playing experience; you hear people complain about insta-deaths in Omega, and for a good reason. There are (almost) always good ways to avoid the insta-deaths, but unfortunately the way to avoid them requires many hours of play, many deaths (even of high-level characters), and deciphering cryptic hints. (Or heavy reference to the spoilers, which, to be honest, is probably a necessity to play). As an example, being put to sleep by a monster is almost always fatal. However, there is an easy way to become permanently immune to sleep; eat a szechuan pepper. Good luck figuring this out without spoilers!
I would contrast this with the exploration-heavy game Ultima IV, which in a lot of ways has a less compelling exploration mechanic; there are many interesting locations, but the aspect of affecting the world is much less in U4 than in Omega. However, the insta-death problem is absent in U4, and even if you die the game very forgivingly brings you back to life with only minor penalties. As such, Ultima IV is a much more satisfying experience for all but the most challenge-driven players.
Welcome to the Merry Prankster Games Blog. GameDev.net is my latest attempt to run an ongoing blog to chronicle my development efforts.
Introduction: I'm Geoff Dunbar, a long-time computer programmer with occasional indie-game flurries of interest. Merry Prankster Games (http://www.prankster.com) is my one-man indie development effort, specializing in single-player RPGs (at least lately). My most recent game (demo, really), was "To The World Tree" (http://www.prankster.com/ttwt), a mediocre entry in the Independent Games Festival. More recently, I've been working on updates to the TTWT engine, with the intention of making a full game at some point.
My goals for this blog are two-fold. To detail my progress on Merry Prankster Games development projects, for the people interested in the nitty-gritty progress on our games. Second, to discuss interesting aspects of game development that I run into in the course of my projects, for fellow indie developers and other interested parties. I will update the blog at least weekly, on one or other of these topics.
As I mentioned before (here in this very space), I've been focusing this summer on making code change to the SENG engine. I've just about wrapped up the user-interface changes, so I can share some screenshots here.
For historical purposes, UI v1 was an MFC-based UI, and as such, looked very "Windows", and very bland. Here's the HUD ("Heads Up Display", meaning in-game interface):
And here's a dialog; a store dialog, in this case, but representative of the overall look:
Looking back, I don't think they're that bad. But everyone I asked disagreed with me; I guess no one wants Windows in their RPG.
UI v2 was a completely new interface. As an aside, I've maintained pretty clear boundaries in the engine code between gameplay engine, graphics, and UI. As such, I've had a lot of success dropping in a new UI without having to touch much other code. Yet another instance where good code design (well, good for me, anyways) and modularity proves its worth!
Back to the interface, v2 was recoded, written directly on top of DirectX and Windows messages. I heavily used the D3DX extensions like ID3DXSprite. Here's the HUD:
And here's a dialog; once again, the store dialog:
This UI drew mixed reviews; anywhere from "functional but bland", to "it looks like an old DOS game". I thought the "DOS game" comment was unnecessary piling-on, but still, clearly a revamp was needed. I'm OK with the HUD, even still, but I agree that the look of the dialogs was pretty poor.
Now that I had the code in DirectX, changing the look was pretty easy. I was already pretty happy with the "feel" of the UI; things were nice and snappy, drag-and-drop worked properly, and so forth. So, I came up with the new design principles:
Make the UI look more modern, with a white-on-black look, and removing the bland backgrounds. I didn't copy NeverWinter Nights, exactly, but I did want my interface to look more like that.
In the previous UI, I tried to make the UI scalable, where the dialogs would get bigger or smaller depending on the resolution. They looked OK at the small resolutions, but looked funny at the higher resolutions that most people would play the game at. I dumped this idea, and went with fixed-sized dialogs for v3.
Also, in the previous UI, when displaying an item, spell, or other things like that, I tried to display the icon, name, and other information right in the UI. This led to largish UI elements that were hard to fit properly into dialogs. In v3, I put these things into a 48x48 element, and displayed most of the information in a hover window.
Here's the new HUD; this is actually pretty similar to the old HUD, but with the new look:
Here's the new store dialog:
And here's the new inventory dialog:
I'm pretty pleased with the new look. One note I would make is that I'm still using the icons from the old UI, which are too dark for the light-on-black look. I'm still only going to have a few icons, so, for example, all swords will have the same icon. But, I support icon coloring now, so a magic sword could glow light blue, instead of the generic gray of a normal sword.
Unfortunately I've changed to engine too much for "To The World Tree" to work with the engine anymore, so I can't release a demo with the new UI, so you'll have to live with the screenshots. As always, comments and questions are welcome.
The first, and very valid, point that he makes is that if you want to learn to program, starting with graphics programming is a difficult way to do things. In addition to just learning how to program, you'll also have to learn a bunch of math and computer graphics theory. Math with things like geometry, trigonometry, linear algebra. Computer graphics involves stuff like polygonal primitives, texturing, lighting, animation, etc. Unlike Shamus, I did go to college to get a CS degree, and almost every CS or math class (or even physics) I took has some relevance towards graphics programming.
When I was first programming back in the early 80s as a Jr High student, the school had a lab with some Color Computers. Inspired by "classics" such as Pyramid 2000:
I took to programming text adventures in BASIC (the Color Computer booted directly to BASIC). That was a great way to learn; simple enough for a Jr High kid to actually do it, but I could still make something "interesting" in just a short period of time. The key lesson for me was just to learn that a computer exactly follows whatever instructions you give it, and to learn how to turn my thoughts and plans into those instructions.
I'm not sure what the modern equivalent of that is; I'm completely out of touch. Making a match-3 game or Tetris-clone in Java? Something in Flash? I just don't know. Shamus recommends C++ for learning graphics programming, which I think is a terrible idea. Too much complexity, too much rope to hang yourself with.
Next, Coyote has an article on cursed items in RPG design:
Out-and-out cursed items. The items that look like a nice magic item but is really completely negative. Like sword that looks like a Longsword +3, but starts attacking you as soon as you wield it. Popular in old-school D&D, not so much anymore.
Mixed-blessing cursed items. So, maybe this time the Longsword +3 is a nice item, but every once in awhile it attack the wielder instead of the target. Items like this have always interested me, if done well.
Story items. By taking the Longsword +3, now the player has to go on a quest to find the Holy Grail. These items are used to move the plot or quests along in the plot of a game. A valid tool in a game designers workshop, though they can seem heavy handed and arbitrary if not done well.
Anyways, good article.
While searching for a picture of a cursed item (didn't find anything good), I ran across this article about cursed items:
MMORPGs tend to be the heaviest users of addiction based design; after all, they get a monthly fee if they keep you coming back:
RPGs in general, though, also feature luring the player on with the promise of "just one more level", "just one more item", and so forth. Diablo 2 perfected the formula, but any RPG designer should keep this in mind when designing his game. After all, making the player want to keep playing is our goal, and we should use any tool we can!
So, I was fooling around with a new Merry Prankster Games logo. The whole skull thing was OK, although something of a fantasy RPG game stereotype. But the old logo could use some work. Here it is in banner format:
So, given my "strengths" (cough, cough) as an artist, 2D not so much, 3D OK, I decided to try the iconic children's blocks theme. A little more playful and less grim than the old one. In banner format again:
I suppose I really should hire a professional to do a real logo. Maybe when I actually have a game to sell I'll worry about that.
Anyways, I'm going to mull over the new logo for a few days and then replace the old one if I still like it.
As I mentioned in a previous blog entry, I read the book "Game Design Workshop". Full title "Game Design Workshop, Second Edition: A Playcentric Approach to Creating Innovative Games" (that's a mouthful!) Obligatory Amazon link (what do you mean I don't get an affiliate kickback??):
I finished the book yesterday, and I thought I'd share my thoughts. Lest the title of this post ("Book Review ...") confuse anyone, this is not a well thought-out, carefully written review; rather it's just my uninformed off-the-cuff thoughts.
"Game Design Workshop" has 3 main parts, plus a series of articles interspersed throughout the book. In the absence of any better plan, I'll talk about these parts individually.
The first part, "Game Design Basics", sets the table for the discussion, defining terms, talking about the structure of games, and so forth. I found this section moderately interesting, but perhaps a bit academic and theoretical for my taste. Games obviously have a great breadth of scope and design, so it might be too much to ask for this section to provide a concrete overview of the elements of game design, but that's what I wanted, damnit.
The second part, "Designing a Game", the largest part of the book, is pure gold. Definitely recommended for any aspiring game designer. Even though I have some game design experience under my belt, it was both informative and reinforcing to read thoughts on the nitty gritty process of designing a game. Get the book for this part.
The last part, "Working As a Game Designer", disappointed me. This section is clearly aimed at the "high-school kid who thinks he wants to be a game designer" crowd, so I guess I'm not the target audience, having worked in software for (groan) decades. But I found it superficial and skimmed over it.
Last, there were a number of articles spread through the book, mostly "Designer Perspectives". For the most part, these were "meh". I might really enjoy reading a long article or book about Will Wright's thoughts on game design, but 2 pages isn't really enough to present much information. Though I did really enjoy the slightly longer article by Richard Garfield on Magic the Gathering.
So, if you have some interest in computer game design, sure, go ahead and read the parts of the book that look interesting. It's mostly well written and informative, and how many good books on game design are there, anyways?
Thinking about treasure lately. When I set out with the SENG engine (the game engine behind Temple of the Abyssal Winds), I was just going to make up any treasure you found by hand. So, in the quest where you defeat the orcs, something like a 10000 gold reward is needed. I would look through the available items, think quizzically for a moment, and say, "Ah yes, how about a Greataxe +10, 2 healing potions, and 800 gold. Sounds about right!"
Well, this turned out to be tremendously boring once I had done it twice. So I introduced an algorithm. In the game file, chest X has 10000 gold worth of treasure, and the game would generate the treasure automatically. Much less boring.
My current algorithm is to generate items randomly (less than the amount of treasure), until we get somewhere between 50% and 75% of the desired total amount, and give the rest as coins. Here's an example:
In this case, 10000 gold was desired, and we ended up with:
A Greatsword +5, worth 2350.
A Masterwork Greatsword, worth 350.
A Quarterstaff +5, worth 2300.
A scroll of Ice Storm, with 800.
And 4200 in gold.
So, that works OK. And I'm definitely not going back to the "by hand" method! But, this method has a tendency to generate a bunch of mediocre to poor items. It would certainly be more exciting if one good item were to turn up more often (at the expense of all the blah items). It would be super-exciting if, once in awhile, a great item (worth more than 10000 gold, even) showed up.
Anyone have any experience with RPG treasure generation that they liked? Other thoughts?
Back from vacation. Sadly still no visible progress. I've done a fair amount of code replacement, replacing Windows-specific code with platform-independent versions of the same code:
Replaced D3DX math code with CML math code (http://cmldev.net/).
Replaced D3DX model-loading code with AssImp model-loading code (http://assimp.sourceforge.net/index.html).
Replaced D3DX particle code (ID3DXSprite) with my own sprite code.
It all works on Windows, and should all work just fine on iOS. Next piece is the model rendering code. Luckily my rendering is pretty simple, so I'm not too worried, but it's still a big change.
Hopefully next time, I'll at least be rendering 10FF models in the iPad simulator.
10 Fantasy Fights is a Merry Prankster Games demonstration game. For more information: http://www.prankster.com/10ff
Merry Prankster Games is desperate for feedback! Please post in the comments below any feedback you have on the game. Or, if you are shy, email directly: [email="email@example.com?subject=10FF%20Feedback"]firstname.lastname@example.org[/email]
See the first comment for some suggestions on what I'm looking for in feedback.