Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Dec 2011
Offline Last Active Private

Posts I've Made

In Topic: Soulbound Items in MMORPGs

Yesterday, 11:24 PM

I think it's mostly to do with encouraging players to play certain content themselves and for making it harder to buy power. In a game where items are bound to the character when they drop, then you know that if you see someone wearing that item, they're at least competent enough to have run the dungeon where that item drops. Higher level dungeons tend to be more complicated as well as requiring better armor/weapons, so you really want players to learn from the lower level ones before they attempt the harder ones. It's not fun for anyone when a noob buys top tier equipment and joins an advanced group without understanding how to play the character.


Personally, I think a mix of bind on pickup and tradeable drops makes the most sense. Bind on pickup drops are important for encouraging players to progress through content in the right order, but if everything is bind on pickup then well geared players lose their incentive to run lower tier content. Whatever stage of the game you're in, there's typically only a few instances that are worth running at any given time because the others are either too difficult or the drops are worse than what you already have. (It's boring if you're stuck repeating only the same dungeon for a long time with no variety, and it's a waste of content if you advance past dungeons without playing them much if at all.)


The principle I'd suggest is that at any stage of gear progression, the player should be able to spend game money to improve their power level, (such as using valuable tradeable consumables or adding tradeable gems to BoP armor) however without getting bind on pickup gear a player should still be less powerful than an equivalent player that does run those instances. One could also argue for limiting tradeable drops to cosmetic items and other items that aren't combat related, but without items that are useful in relation to the game's primary mechanic (which is usually combat, although in some MMOs it could apply to some sort of crafting skill as well) a lot of players won't care - tradeable items need to be useful for players to actually want to buy or farm for them.

In Topic: Smooth outcomes/incomes in the game

28 December 2015 - 08:53 AM

Command and Conquer and Supreme Commander for example have a "streaming" or "pay as you go" resource system where you can add units to the production queue without currently having the money to complete them, and the game automatically spends the money over time as long as the player has some. It's also the system I'm using in my game, it's more complicated to implement but there are some advantages to using it. The basic idea is that, unlike games like Starcraft or Age of Empires, you don't have to wait until you have the full value of the unit to tell the game to start building it. So in that example, if a unit costs 30 resources you can tell the game to start building it whether you have 0 or 25 or whatever and it will start building over time as long as the player has money to spend, which means you'll never have to wait for the player resources to hit a certain amount before starting production.


This is the basic form of the equation I use in the production building's update loop:

resourcesSpent = (buildingQueue[0].initialCost) * (timeStep/ (buildingQueue[0].buildTime));

if(resourcesSpent > player.totalResources)
  if(player.totalResources < 0)
    resourcesSpent = 0;
    resourcesSpent = player.totalResources;

buildingQueue[0].remainingCost -= resourcesSpent;
player.totalResources -= resourcesSpent;


resourcesSpent = amount of money this production building spends on producing stuff this update loop

buildingQueue[] = a list of data on units to build

buildingQueue[0].initialCost = the total cost of the unit (e.g. 30)

timeStep = how long it's been since the last update loop (probably something like 1/60th of a second)

buildingQueue[0].buildTime = how long the unit would take to build if we didn't run out of resources during building (used along with initialCost to determine the rate at which resources are spent)

player.totalResources = how many resources the player currently has

buildingQueue[0].remainingCost = initially the same as to initialCost, when this reaches 0, the unit is completed and removed from the queue


There's more to it, like dealing with integer rounding, evenly distributing resources when there's a low amount and multiple production buildings, but the above code is the main part.

In Topic: Smooth outcomes/incomes in the game

27 December 2015 - 04:18 PM

I'm not sure I entirely understand what the issue is, but I think it would be better to separate the money coming in from the money being spent. (First add all the money coming in, then in a separate and independent equation subtract all the money being spent.)


In that equation, I'm guessing the 10 represents the number of farms? What happens though if the number of units and buildings is greater than the amount you're getting from farms? It would make sense for the player to be losing money in that case, but that case alone doesn't cover it.


Also, is this a real time game or turn based? If it's real time you can definitely smooth out the income and resource spending over time (spend a percentage of the cost every update based on how much time has passed out of an overall build time) rather than spending up front in chunks.

In Topic: Weekly Monster Reveals- What Voice?

24 August 2015 - 06:28 PM

I think either would work. Doing it as yourself might be the safer bet if the production values are low, plus you'd be able to talk more about how they affect the gameplay and what game design or technical challenges went into making them, but doing it in character as someone from the game world would be cool if it's well done, something like Diablo 3's lore journals: https://www.youtube.com/watch?v=BM1h2af-Z4s

In Topic: Real Time Strategy mechanics

10 August 2015 - 07:02 PM

I don’t think there’s anything necessarily wrong with generic as long as it’s well done and not a complete clone of an existing game. That faction upgrade system sounds like it’s enough to offer a unique experience and make your game stand out from others in the genre, and there’s plenty more you can do with small mechanical decisions to make your game feel different from existing games. Whatever the theme or gimmicks, I think the best strategy is to focus on the fundamentals and just make a really solid RTS game.


One problem I see with the second one is that it sounds too much like rock/paper/scissors, not in the sense of having a combat triangle of counters, but that by separating the production and battle phases, players will have to blindly choose a tech path and hope that they picked the right one to counter the other player, since they’d have much more limited opportunities to switch builds after seeing what the enemy is doing. It sounds like it’d run the risk of being too much of a simplification of the genre, and that could turn off the core RTS gamers who would otherwise be the main audience.