• 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.

PhilLiu

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

119 Neutral

About PhilLiu

  • Rank
    Member
  1. If you're looking for a relatively trivial solution, create a set of predefined objects, randomly scatter them around the planet. An object can be anything from a dungeon room to a mountain to a tree. This solution for procedural generation is useful for creating meaningful features. Oftentimes, procedural generation a-la-minecraft generates a plethora of meaningless features. It may be pretty and cool at first sight, but after a couple of hours it quickly becomes stale.
  2. [quote name='Silverain Development' timestamp='1339700876' post='4949249'] [code] // Chain Lightning Pseudocode ChainLightning.effect(Attacker,Target){ Attacker.state = ("Casting") Draw lightning from the Attacker's sprite to the Target's sprite Target.state = ("Hurt") Target takes (Attacker.Intellect / Target.Lightning_Resist) damage Target.Hit = True show the damage done on the screen, over the target's head while(Target is not null) { OldTarget = Target Target = NULL check tiles within 2 spaces of target if(tile contains a unit that is hostile to the attacker and has not previously been hit){ Target = found unit Target takes (Attacker.Intellect / Target.Lightning_Resist) damage Target.Hit = True Target.state = ("Hurt") show the damage done on the screen, over the target's head } } } [/code] [/quote] Ok, you seem to not understand what I was getting at. You need to generalize what you're doing as much as possible in the context if your game, not write a new language. That means things like variables, loops, properties, etc. should be kept to a minimum. You define a set of rules in the context of your game and have your parser execute the programming logic.
  3. serialized classes are huge. avoid them when dealing with anything that has fields other than raw types.
  4. LUA does the job fine. If you absolutely must define your own language, I suggest reading up on parsing: [url="http://en.wikipedia.org/wiki/Parsing"]http://en.wikipedia.org/wiki/Parsing[/url] Then, you can make your own pseudo-language that is simply used for your game and therefore easily usable: [CODE] Filename: ChainLightning.spell "Chain Lightning" required $caster $power $cost decrease MANA of $caster by $cost select $a in range(4,$caster) select $b in range(1,$a) select $c in range(1,$b) damage $a by $power damage $b by [$power/2] damage $c by [$power/4] [/CODE] This type of language is easily parsable and readable by the average non-programmer. The disadvantage is the strictness of the syntax and lack of power, obviously.
  5. Average players do not go to 100-200 meaningful APM; they hover around the 100 range. I don't think APM is the same as multitasking, but multitasking increases the required APM of a game. By contrast, DotA can be played with 60 APM even though top players spam over 150 APM. As far as straying from the Action RTS design, that's a design choice that is ultimately up to the developer. I've mostly given my opinion from an Action RTS fan about the subject, so take from that what you will. I really do not have the experience in non-conventional RTS games to offer any advice on the subject.
  6. A is viable C can be circumvented D can be circumvented You need to implement A in such a way that it is expandable, though. For player satisfaction, consider having a Gamer ID and a Character Name. Your character name will be your interaction label for all NPCs, but your Gamer ID is your interaction label for all system related things such as friend adding, etc.
  7. If you want trajectories to look something like WC3 projectiles, I can help a bit: Just have the linear ones move in a straight line towards the target at a constant speed in each step. Have the ones with a trajectory do the same thing as the linear ones, but calculate the height at each step using a parabola and fitting the two points to the curve. Solve y = c(x-a)^2 + b, where c is your arc constant. Effectively, you are translating your predefined arc to fit your two points. There should be only one solution. (2 equations, 2 unknowns) Now, to correct for the target unit moving is relatively easy. Simply recalculate the amount of X distance you have left, find the amount it has increased, and subtract that from the x value you use when calculating your y position. This will result in a gaussian-function-like curve.
  8. I guess the general sentiment in this thread favors the older RTS-style games. I apologise for my generalization, then. Since I'm a fan of more standard RTS games, I speak from experiences such as C&C, AoE, WC, SC, etc. However, I do feel like it's fair to assume that your target audience will include people like me. In my opinion (and with no offense intended, I understand conflict of opinions can be touchy) you're imposing mechanics from very specific RTS games onto the genre. For example, Majesty is a different take on the RTS genre compared to most RTS games. You might enjoy the gameplay, but I have never even played it. I will use your definitions for micro and macro from now on, though. To reference micro-light "standard" RTS games, AoE would be a prime candidate. Unit pulling is still effective in AoE, but less so because of the large mix of melee and ranged units melee units will be taking most of the hits and it is obviously silly to pull melee units taking damage from ranged units in AoE. Positioning micro is also lessened because of the formation options. Queueing units is relatively not punishing. It also emphasizes gameplay based on your definition of macro, where a large portion of thought goes into unit selection and technology. Certainly this is not an APM-fest by your standards? But the points I made about heroes also applies to AoE. I wouldn't want to spend all this time on maintaining a hero, because it means my influence is more localized to the hero than multiple map positions. I want to worry about what buildings I'm going to build and where they are positioned. I want to worry about scouting my opponent. I want to worry about finding resources. It is definitely viable in AoE to send a couple of units to defend a position, and not have to maintain them. This is generally achieved through static defenses, walls, and ranged units. On the other hand, micro is definitely important in AoE when you're attacking, because you need to prioritize targets. From what I gather from your posts, your order-only gameplay is no different from standard RTS games and can have APM applied regardless. You can still order retreats (I would hope), so in the case of a large map, superior APM in order to watch and evaluate multiple battles at once would still beat out those who have low APM and are slow to react. Really, how one would minimize the amount of micro required in an RTS is by automating it. For example, in SC2, if units didn't cost resources to queue, had infinitely long queues, and had order-based controls to the point where stutterstepping is not effective, then it would pretty much match your expectations of an RTS?
  9. You expect to develop a competitive video game to appeal to super casual gamers? There are casual league of legends players, but a session takes on average 35 minutes. I wouldn't expect someone who is on the casual level of angry birds to enjoy playing league. To appeal to "angry birds" casual gamers, your game probably needs to meet the following criteria: 1. Start and stop the game at any time 2. "Pause" the game 3. Easy to learn and teach 4. Make player feel good about themselves 5. Appealing visually To appeal to competitive gamers, your game must have the following: 1. Deep strategy 2. Involved mechanics (enough to separate skilled players from for-fun players). 3. Matchmaking 3a. Ladder rankings 4. Clear, easy to understand visuals. A game with involved mechanics and deep strategy is not easy to teach and learn. A PvP game with matchmaking and ladder rankings will not make a casual player feel good about themselves. This is pretty much impossible, and you will not see this happen at all. You will, at best, attract the non-competitive avid gamers with a competitive game. They expect: 1. Game is fun 2. Game is decently challenging 3. Game is visually appealing. This is why SC2 and LoL are so successful. They inherently offer a challenge by making the game PvP and matchmade. They always get a challenge that is not terribly easy or terribly hard. SC2's ladder system allows people who aren't good still feel good about themselves (leagues), as they can progress in their own league/division and not worry about their global ranking. This keeps the non-competitive gamer coming back because they want to progress. On the other hand, the best players are in a national league of the top 200 players. This keeps the competition strong. Now, to address your problem: If your game is 1v1, penalize the other player for leaving by assigning him a loss and decreasing his points (like sc2) If your game is XvX, penalize the leaving player by blacklisting him as a leaver after a certain leave:game ratio. If the player is a leaver, pair the player with only leavers until they salvage their leave ratio to be better than the limit. For example, if the acceptable leave amount is 4% and the player exceeds that amount, they would have to reduce their leave % to something like 3% before they get un-blacklisted. If their leave ratio becomes too high, ban the leaver. This will definitely NOT appeal to casual gamers, but it will appeal to both competitive and non-competitive avid gamers.
  10. 1. Make the left/right characters visually distinct. 2. On the introduction of the left character, give the player a REASON to move left. 3. On the introduction of the right character, give the player a REASON to move right. For example, in the earlier games without tutorials such as MMX, there's a wall to the left and an open highway to the right. Why would you move left? The only viable path is to the right. It's open and it looks safe.
  11. The 2D castlevania (metroidvania) games I believe have "coded" dynamic animations. Large monsters were drawn in parts, and their parts were animated through image transformations, sort of like a model system.
  12. Your question is not very clear. It seems that you are trying to generate a path from point A to point B when B is only accessible from A via a diagonal jump? If so, there exists no path containing of only vertical and horizontal movements that get you from point A to point B, so your algorithm is correct to return no path.
  13. [quote name='AltarofScience' timestamp='1337891348' post='4943004'] I totally disagree that RTS games are about macro management, although I would prefer it if they were. Most popular RTS games are micro APM fests. Its turn based strategy games that are about macro, like Dominions. Majesty actually was mostly about macro but its not a traditional RTS. [/quote] SC2, unarguably the most popular RTS, is very macro intensive. A large portion of APM goes to macro. Micro is only important and APM heavy in specific situations such as marines vs banelings, zerglings vs hellions, etc. However, if you mean to say that popular RTS nowadays are not about macroscopic decision making and strategy, then I can agree with you. However, non-micro RTS games I have played suffer from the issue of poor AI, making it extremely frustrating for players. Also, no matter how non-micro you TRY to make the game, the element of unit pulling will always exist in any RTS. (Pulling a low hp unit out of range of the enemy, then sending it back in). EDIT: Also, leveling in separate spheres is too complex. A better implementation of the same concept would be to just create a hero that specializes in each sphere, so you can make the decision when you recruit/train the hero. The total war series (although not truly RTS) does this, and it works brilliantly.
  14. [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]What is your preferred growth system in RTS games, if any?[/background][/left][/size][/font][/color] Heroes should grow via neutral objectives or enemy deaths (such as in wc3). This design encourages player interaction. The growth can be in the form of experience points items, or straight up stat increases. It is also important to restrict snowballing of heroes, so make sure that there is a punishment for letting a hero die, scaling with the strength of the hero. [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]Do you support leveling in separate spheres?[/background][/left][/size][/font][/color] I'm not quite sure what this means? [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]How do you prefer skill systems?[/background][/left][/size][/font][/color] I prefer skills to be either predetermined or easily selected. [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]General thoughts on heroes/growth systems?[/background][/left][/size][/font][/color] [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]Overall, hero complexity in an RTS should be kept to a minimum, because an RTS is largely about macromanagement, multitasking, and strategy. Forcing a player to spend lots of time on setting up a hero will make the game less fun, I feel. Part of the reason I personally did not like WC3 was because of the hero system. It was always optimal to get an early hero, because everything that you kill without a hero present is wasted EXP. It was impossible to scout most hero abilities, so you don't know what ability their hero has selected until you are fighting against it. For example, it is nearly impossible to know that an orc player is going for BM harrass. You can only make an educated guess. [/background][/left][/size][/font][/color][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]Generally, heroes are very difficult to deal with without a hero of your own, which makes a hero-less build not viable. [/background][/left][/size][/font][/color][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]Heroes in SC2 campaign are implemented in a much more desirable manner (except for Tosh, but he's a special case). They are largely low-micromanagement, but they feel good to use. They are strong, but mortal. I feel like if there was some way to produce heroes in game, as long as they were balanced between races, they would fare fairly well.[/background][/left][/size][/font][/color]
  15. Make a camera vector and keep it updated with the code: [code] camera.x = min(max(player.x - camera.width/2, 0),world_size.x); camera.y = min(max(player.y - camera.height/2, 0),world_size.y); [/code] Moving your background instead of moving your player is extremely non-dynamic and difficult to debug around. Instead, simulate a camera by drawing what's on screen RELATIVE to the camera. so, you would draw player.sprite at (player.x-camera.x, player.y-camera.y).