• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

PropheticEdge

Members
  • Content count

    132
  • Joined

  • Last visited

Community Reputation

150 Neutral

About PropheticEdge

  • Rank
    Member
  1. [quote name='Benholio' timestamp='1327591814' post='4906441'] Thanks guys, checking out Darkfall Online and ATITD! [/quote] ATITD is a goldmine for unorthadox, complex crafting systems and I heartily second its recommendation. I'll temper jbadam's point with my own take on doing something strange with equipment augmentation. A system like this, an upgrade system, crafting system, whatever, should exist to reinforce you game's core mechanics. Some games make really elegant combat their big thing, and really hone on in that aspect of the design. In order to keep it pure, things like crafting are left simple such that they support the combat. I don't think there's anything wrong with making a crafting system with deeper mechanics. In fact, I think it could be rather interesting. Just be sure that it jives with your design's overall sense of purpose. If it ends up being a confusing or clunky mechanic, it will hurt things. Onto the difficulty issue (some players may or may not get it), I'll suggest you take a look at this article. http://www.gamasutra.com/view/feature/6531/darwinian_difficulty_how_throwing_.php I really like the points in it. I'd puzzled over WHY people liked Demon Souls so much 'till my puzzler was sore, or perhaps more specifically, how such a difficult game was made with it also being highly enjoyable. I think your augmentation system, if it is a deep mechanic that people will have to learn , might benefit from a Darwinian curve. Meaning, don't let the player get by without understanding how the augmentation system works. Make it a requirement for progress at the very start of the game, and force them to learn it. Facilitate the learning, though, and make sure the system is fair and transparent to the user, but don't let them progress past level 1/the tutorial without really understanding how the system works. This way you can really bring that mechanic into the fold for your game and make it significant. It will make it easier to balance since you can assume the player is using the mechanic efficiently, so you don't have to worry about players that are kind of muddling through the game without knowledge of the augmentation system. If you let players do that, you run the risk of them hitting a point where they can't progress due to the game suddenly demanding that they know what they're doing with the augmentation system. It's harder for them to learn at this point (because they think they've been doing the right thing all along), and will get them very frustrated.
  2. I would say yes, have acceleration and deceleration as you're moving through water. You can make a fairly reasonable fluid resistance formula without a huge amount of trouble. You should consider giving the player the ability to do something to slow themselves down. For instance, think about when you're swimming in a pool. What do you do when you want to slow down? 1) Increase the surface area of your body perpendicular to the direction of motion to increase your drag. 2) Paddle your arms and legs in the opposite direction of motion. If you give the player the ability to apply some sort of braking force, then they can choose to stop reasonably fast or enjoy the floaty feel of being in water.
  3. [quote name='sam_hughes' timestamp='1317704009' post='4868854'] Except for the problem of too many layers of indirection. [/quote] Nah, just abstract it behind a clean API that hides the complexity of the indirection.
  4. [quote name='Acharis' timestamp='1317682563' post='4868741'] Hmmm, I was rather attached to the full numbers idea (like: an iron mine produce 5 iron), but I guess I could live with the efficiency being fixed point value I wonder how to write it on the interface, "coal mine produces up to 5 [b]tons of[/b] coal depending on the number of coal mines"? Or maybe write no numbers at all "coal mine produces coal"? BTW, it's nice that someone here has heard about Red Dragon. [/quote] Now you can have fractions without anyone batting an eye.
  5. [quote name='num3ric' timestamp='1317420931' post='4867751'] [quote name='freeworld' timestamp='1317415788' post='4867723'] On topic; What renderer are you using? is it built in house, if so then it's up to you to determine this question. As for OGRE, most likely yes. Most renderers, if they are designed with a little thought, and the well known ones are. They should be completely independent of the game logic/data. They usually expose their interface and resources need to use the renderer. It's then up to you to uses those resources how you see fit. Same goes with most third party libraries/sdks, they are designed to work by them selves, as long as your pumping them with the information they need. ie a render isn't going to work if you don't give it meshes to draw. But it will never require you to pass a game object with things like a health variable. Unfortunately when it comes to engines, they are typically all in one packages designed to work together seamlessly. I'm sure most of them can be torn apart to use the individual components, but that's not how most are designed. Last question, may you post what components you're trying to piece together? You never know, someone else has probably tried the same and could shed some light. [/quote] Right... Well, for the moment, I'm really looking around, searching for which components I should put together... I've made a visual prototype in [url="http://libcinder.org/"]Cinder[/url] and I enjoy the fact that it is not too high level (just one layer above OpenGL). I want fine grain control over the visuals (and possibly basic physics) and no limitations from a game engine. (That being said, I might have to convert it to Ogre at some point.) However, this is not very convincing for some teammates who would rather enjoy the comfort of a game engine, especially for the game logic/network/ai. Even if the teacher prefers that we build our game engine/logic ourselves, and even if our game is a non-standard RTS, I can understand how scary it is to do it from scratch, in C++. Therefore, I'm trying to see how we can resolve this. I would agree with this [url="http://stackoverflow.com/questions/3822707/game-engine-or-graphics-library/3823241#3823241"]stackoverflow post[/url] which explains when or when not to use game engines. In the comments, several librairies are mentioned :[color="#444444"][font="Arial,"] Ogre, FMod(or Caudio), RakNet (for network), OIS (for inputs). [/font][/color]So, I'm wondering if it really is feasible to use all of those librairies at once. Reaching a consensus for technical decisions isn't always easy, especially if we have different visions, little experience and poor guidance from our teacher. [/quote] Are you sure you won't have limitations from those various libraries? After all, an engine is simply a set of libraries. Once you hook all those libraries together you've created, more or less, an "engine". Edit: Also, don't to afraid to toss a prototype. They're just prototypes. Sometimes it can be tough to take a prototype and shoe-horn it into workable code; it might require so much refactoring that you end up recoding it anyway, or you might lock yourself into some technology that's not suitable for full scale production. You should really give some more details in your question. I get the feeling you're not actually asking the real question. So riddle me this, Batman: What are you making? Why are you making it? Is this going to be sold? Is it just for experience? Is it a student project? How much time do you have to make it? How big is your team? What is their technical skill level? Are they already familiar with other engines? Can they code in C++ proficiently, and are they already familiar with DirectX/OpenGL? Why does it need to be cross platform? (ties back into the "why are you making this" question)
  6. An unquenchable lust for profit and morals looser than Peter Jackson's old wardrobe. (Also some sort of and a HUGE backend to handle store transactions, social media integration and metrics gathering. In terms of actual gameplay programming, it's not that nuts.)
  7. [quote name='Waterlimon' timestamp='1317381351' post='4867527'] Yeah not having a built in currency mechanism would work, you could buy something with any item(s) as long as the seller accepts it. For normal players this is easy, but for NPC's you would propably need a big table of products with either fixed values, or values calculated from following the players trades and estimating the value of something. Best would be if the NPC's actually needed something, but that would require a closed system where the NPC's trade the stuff they got by selling to other NPC's or normal players. (Every NPC could sell anything + its primary product if they sell them to players) Of course you should include some options for currency, like different kind of rare stuff that is hard to get, and if you do get it, you can only get a small amount no matter what level you are. Also it must not have an use other than for appereance. [/quote] Whoops, forgot about NPC's. Those are kind of a big thing for me to forget about, too! Not sure what you'd do in that instance. I've only seen one MMO with a barter/self printing currency driven economy, but it didn't have NPC's.
  8. [quote name='LorenzoGatti' timestamp='1317372758' post='4867507'] My main realistic suggestions is to avoid generic names ("silver pieces", "gold pieces" etc.), not only because multiple coins can share the same metal, and even the same value, but to implement a [i]system [/i]of actual coins and conventional units that have proper names, practical roles, precise relations and interesting stories. For example, medieval England had silver pennies, silver halfpennies and silver farthings, not "silver coins". Shillings worth 12 pennies and pounds worth 20 shillings were natural and meaningful accounting multiples (pounds were one pound of silver); farthings worth 1/4 of a penny were the smallest subdivision normally needed; foreign gold florins worth 6 shillings were the right size for gold coins, and suitable for hoarding and large-scale trade. Later English coins show typical flavorful complications: [list][*]inflation, causing the appearance of silver shillings and a number of 5, 10, 20, 30... shilling gold coins;[*]gold value fluctuations, leading to varying exchange rates between silver and gold coins and, particularly, gold guineas settling at 21 shillings rather than 20 as originally intended and surviving actual coinage as a traditional accounting unit;[*]novel coin denominations, often short-lived, worth strange multiples of a penny, or with the same value as existing ones.[/list] [/quote] You know what would be interesting? Letting players mint their own money. Select the material, select the mass, make a coin out of it. Name it when you make it, too, and see what happens. Eventually you might see popular coinage types (crowns contain 8 ounces of gold, which is worth 60 silver doubloons, each containing 2 ounces of silver, etc) bubble to the top. Assuming this is an MMO, of course. If not, yeah, just make up coin names, or base them on historical names. Honestly, this naming business is just flavor anyway and the real meat is designing an economy that doesn't explode.
  9. [quote name='Caldenfor' timestamp='1317343421' post='4867413'] [quote name='PropheticEdge' timestamp='1317342742' post='4867409'] Any multi-precious-metal-coinage currency system must include Electrum or it's dead to me. Anyway, if you wanted to be simple, you really could have an undivided currency. Japan uses the Yen, and that's its only currency (at least in common usage. I don't think they have a wonky, esoteric subdivision lurking anywhere). 80-ish Yen is about a dollar, so it's really not that bad a way to do a currency. This would not be wholly accurate in a medieval European setting, but it would be simpler. Conversely, you could do currency by weight. Determine the price for an ounce of gold, and base the currency around that. Then you could have your characters carry around gold via its weight rather than discrete pieces, allowing for fractional quantities without breaking immersion. Just rationalize that you're splitting gold pieces as needed, and merchants are re-smelting them back into coins behind the scenes. Graphically represent things as piles of gold coins or little piles of gold dust/chips when the wallet starts getting bare. Other thoughts are to have bank notes without automatic conversions. You go to a bank, you plunk down 10k gold pieces, they give you a note for 10k gold pieces. That could be traded for goods directly, assuming something cost 10k, or you could go to a bank and claim 10k gold pieces from them. This would be a far more realistic approach if you didn't have a magic heavy world to accomodate for instant transmission of knowledge (and thus banking networks with unified account balances like we now have). Of course, this can all get very annoying for the player if money is too cumbersome to handle. Potentially. It could also be an interesting part of the game (I thought, in some way, currency having weight in EQ was interesting). However, you probably want to avoid goofy shit like players dumping mountains of gold on the ground because they'd become too overencumbered to act if they actually picked up money off of mobs. [/quote] Ultima Online had gold with weight determining how much you could carry. They eventually added checks. "Check 100000" and if you had 100,000 gold coins(the only currency type) a check for 100,000 would be placed in your inventory/bank. These checks weighed the least amount of typical items so you could easily carry large amounts of gold in check form. [/quote] Ahhhhh, cool! I didn't play much of UO, never saw the checks thing. Could you cash them back into gold?
  10. Any multi-precious-metal-coinage currency system must include Electrum or it's dead to me. Anyway, if you wanted to be simple, you really could have an undivided currency. Japan uses the Yen, and that's its only currency (at least in common usage. I don't think they have a wonky, esoteric subdivision lurking anywhere). 80-ish Yen is about a dollar, so it's really not that bad a way to do a currency. This would not be wholly accurate in a medieval European setting, but it would be simpler. Conversely, you could do currency by weight. Determine the price for an ounce of gold, and base the currency around that. Then you could have your characters carry around gold via its weight rather than discrete pieces, allowing for fractional quantities without breaking immersion. Just rationalize that you're splitting gold pieces as needed, and merchants are re-smelting them back into coins behind the scenes. Graphically represent things as piles of gold coins or little piles of gold dust/chips when the wallet starts getting bare. Other thoughts are to have bank notes without automatic conversions. You go to a bank, you plunk down 10k gold pieces, they give you a note for 10k gold pieces. That could be traded for goods directly, assuming something cost 10k, or you could go to a bank and claim 10k gold pieces from them. This would be a far more realistic approach if you didn't have a magic heavy world to accomodate for instant transmission of knowledge (and thus banking networks with unified account balances like we now have). Of course, this can all get very annoying for the player if money is too cumbersome to handle. Potentially. It could also be an interesting part of the game (I thought, in some way, currency having weight in EQ was interesting). However, you probably want to avoid goofy shit like players dumping mountains of gold on the ground because they'd become too overencumbered to act if they actually picked up money off of mobs.
  11. [quote name='calculemus1988' timestamp='1317247789' post='4866970'] DarklyDreaming thanks A major question is should I do my own engine or just use a framework like XNA or an engine like Unity. I guess it matters what kind of a job I am aiming for, not sure yet, but "AI programmer for games" I guess is what I have on mind so far. Based on that I guess I should use already available engines/frameworks and concentrate on the AI. You can't do too much AI so, still I would have lots of stuff to do. Any opinions, suggestions drop em... Cya [/quote] I will preface this with "I'm not an HR person", but I think what will generally matter more to a hiring personel than the specific engine/language you used is that you completed a game. So I'll toss an addendum onto Darkly's post that is. "Develop with whatever will let you finish the game in a reasonable amount of time." However, my above statement only assumes your primary goal is "I want to finish this game". There are other goals that could conflict with this, such as... 1) If you are looking to sharpen skills with a specific language/technology better, then this could be a great opportunity to dive into that. 2) If you know a prospective employer is looking for specific experience with a specific language/tool. There's a sliding scale on this since you can kind of cobble together an acceptable skill set at times (I got a job as an iOS game developer because I had general iOS app development experience and non-iOS game development experience. By their powers combined it was good enough for HR). 3) Special concerns matter greatly to you, such as cross-platform deployment. I will throw my chips into the pile by saying that engines nowadays can be big, big time savers and you will still learn a ton about the development process even while using someone else's kit. At the very least, libraries to streamline a lot of the gritty of graphics rendering can be a big time saver. Edit: Oh, there's this article I found on turn-based strategy game AI that was pretty cool. An RTS is different, of course, but maybe there's enough overlap that you might find something in here useful. http://www.gamasutra.com/view/feature/1535/designing_ai_algorithms_for_.php
  12. Nope, you don't need to be a good artist at all. What can help (but is not mandatory) is good communication skills. Of course, this is more "helping you as an employee" and not as a programmer specifically. Conflicts often arise when artists want something that technology cannot deliver, or that would be difficult to program to the point of delaying the project. It is helpful for a programmer to understand the aesthetic vision of the art department and be sympathetic to it, allowing them to nudge artists along a path that will satisfy their artistic needs while also being technologically feasible. You don't have to be able to draw or paint or model or animate, but just understand what the look and feel of the game is, what satisfies an artist, and what supports the overall experience you're trying to build for the user. Personally, I took some courses on film, basic art (just drawing 101 type stuff) and art history when I was in school. Am I good artist? Absolutely not. I do know about how art works, though, which is very useful when talking to artists. The same can be said for ANY discipline in game development. It is definitely useful to be sympathetic toward game designers, sound engineers and business types as well. It is quite common to run into development road blocks stemming from those disciplines as well. None of this is strictly required, though. It can be useful in small teams where people often wear many hats and you interact with the entire art team (all of like 2 people) constantly. I also imagine it could be helpful in a bigger team, but more so for people in lead positions. Not sure about that, though, never worked in a big studio.
  13. If you're going for the shamanistic route, why not go all the way? You play not as a mundane animal, but one possessed by a protective animal spirit. The currency (or crafting widget) you get is spiritual energy, life force, what have you that is collected from other living things (probably by beating them in combat). "Loot" isn't physical objects, but the spiritual essence of those objects. You don't get a bear claw as a physical piece of loot to stash in your pocket, you get the spiritual imprint of a bear claw to absorb into your spirit (totally an inventory with a different name). Depending on the machina of your choice, your spirit can simultaneously hold a fixed amount of these spiritual imprints. Maybe it takes a stronger will to hold them, so a lesser deity (low level PC) has a more limited carrying capacity than their stronger (high level PC) counterparts. You can make something analogous to bags if you want, some sort of spirit enhancer thing that increases your carrying capacity and can be swapped out/upgraded as you go. This could also solve the "Why can I carry a 200 pound suit of armor in my pocket but not two more potions" discrepancy by making everything metaphysical. You "equip" these items by attaching them to your core spirit. Pretty much just a different way of looking at equipment slots. The changes made to the spirit are manifested in the creature that it possesses. You equip the spiritual imprint of bear claws, your creature now grows bear claws. Want something with the body of a lion, wings and a scorpion tale? Go for it.
  14. I think having two tiers of quests is a really good idea and could help the player distinguish between the time investment/scope of the undertaking (and the magnitude of the eventual rewards) more readily. Many a time I've had my expectations broken in an MMO by being like, "Oh sure I'll kill these 20 wolves" then a few hours later finding myself ass deep in fel-evil guts as I save the world at the culmination of some convoluted quest line. Naming them "quests" and "favors" is cool, for one because it gives it a more medieval feel, and two because it maps back to natural language pretty well (we tend to think of favors as pretty small things in the English language). Using stars or whatever works too, but is really no different. It's just a more abstract system that provides the same information.
  15. [quote name='ApochPiQ' timestamp='1316654194' post='4864486'] There's nothing special about a PCB used in an arcade machine. They're the same as any other electronics: resistors, capacitors, transistors, maybe some relays or latches, the odd IC. Nothing magic. If you're interested in how electronics work, I recommend an electronics hobby community; GDNet isn't really specialized in hardware. I'm not sure where you get the impression that arcade machines are "full of chips" whereas consoles are not. Have you disassembled either of these things? I also don't know what you mean by "arcades" being "so much more powerful" than consoles. Usually, it's the other way around, by many orders of magnitude! Lastly, arcade machines are manufactured the same as any other electronics. There's typically a prototyping phase, then once the circuit design etc. is all nailed down, they do a couple revisions in "actual" hardware and then scale up to mass production. Secret: many arcade machines are actually built like general-purpose computers, with just really restricted functionality presented to the "user." Think of a typical arcade machine as a console in a fancy cabinet. In general I think it's hard to give good answers to your questions because they are very vague; could you elaborate a bit on your interest in this area and what specifically you want to know more about? [/quote] I get the feeling he's talking about old school, 80's type stuff, not modern arcades. Modern arcade machines are just PC's nowadays.