Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 01 Feb 2008
Offline Last Active Oct 29 2012 04:02 PM

Topics I've Started

[UI] Message Panel Positioning

23 May 2011 - 11:19 AM

I'm creating an RPG rogue-like that has a main graphical panel that shows the terrain, monsters, etc.

Some messages are displayed on the graphical panel e.g. damage amounts that float upwards and fade WoW-style. The main graphical panel takes up about 1/6th of the screen space. Think 600 pixels square on an average 17" display.

In conjunction with these is the verbose message for each event that is written into a separate message panel. It might read something like:

The evil wizard casts a spell...
Creature X is burned for 85 pts of damage.
Creature X is dead!
Creature Y is burned for 18 pts of damage.

There are potentialy a lot of messages (perhaps dozens in a single combat round with many participants) and they scroll past pretty quick.

Where would you put this message panel in relation to the main graphical panel and why?

Any preferences on size, usage, or other UI feedback pertaining to this topic?

GameState / Animation Skew

08 May 2011 - 03:54 PM

I have a game that features combat in a tactical, turn-based manner.

There is a GameState singleton and it has a list of Mobiles.

During a single turn in battle each Mobile can choose from a variety of actions including movement and attack. Each of these actions is animated. You can see smooth movement as Mobiles move from one tile to another and you can clearly see from where attacks originate from and who the victim is.

During the processing of a turn, several Mobiles will take their move e.g.:
Mobile 1 moves closer to its target Mobile 7
Mobile 2 attacks Mobile 1
Mobile 3 moves closer to its target Mobile 1
Mobile 4 attacks Mobile 1, killing it

The big design problem is that there is a skew between the existing GameState and what is displayed onscreen. Animations must be played before the display 'catches up' to the GameState.

In the above example, note how Mobile 1 is already dead after processing the turn but the player should see all the animations before seeing the corpse. I process several Mobiles at once because during a big battle of hundreds of Mobiles, no-one wants to wait while each and every Mobile takes its turn and is animated.

How would you design such a system at the programming level? Do you:
a) change your GameState singleton immediately but delegate the painting of the Mobile and corpses to the animations?
b) calculate the change but do not apply it to the GameState until after the animation is complete?
c) other?


04 July 2010 - 05:19 PM

My game centers around you, the player, and involves a heavy traditional RPG aspect.

The game itself will cover a real-life span of about 40-50 years. You begin the game as an adult (low-mid 20s) and eventually will die of old age in your 70-80s (assuming you aren't eaten by a slavering grue before then). The game takes place during ancient times and so I could shorten that and still have it fit into the theme.

I am wondering how I can enforce this limit and still have it palatable to the player. Here are some possibilities:

1. You suddenly keel-over dead at a random age. Hard-core!

2. You develop old-age implemented as a disease and thus know your time is numbered. Perhaps it can be implemented in a manner similar to increasing corruption in ADOM. Thus as you get older, you gain more and more ailments (cataracts, brittle bones, memory loss, etc.) until you're so old that you croak.

3. Your fate is determined by the stars and the exact pre-destined date for you to enter the afterlife is foreseen and known much much earlier in the game.

4. If you do not complete the main goal of the game by a certain age then the king summons you and the game ends.

5. You live indefinitely but the longer it takes past a certain age, the lower your overall score is. Being too old acts as a big penalty. Note that I really want to avoid this scenario as I do not want to plan the game events over an indefinite period of time.

Which method would you choose? Do you have any other ideas not in the list? Do any of the above methods really grate against your sensibilities to having fun in the game?

City Operation Balance

29 June 2010 - 06:23 PM


I'm creating the beginnings of a simple city simulation where the city composition affects supply and demand. I'm finding the top-down design process quite difficult because ultimately there will be much more types of commodities and buildings than I can anticipate at this point in time.

Here's what I have so far.

Commodity types: water, food, wood
Unit types: people, livestock
Building types: cistern, farm, or mill

A city has a finite set of land plots that can be purposed by constructing a building on it. Certain land plots are better than others for building on. For example a cistern should be built by a river.

A cistern produces water every month. A farm produces food but requires water. A mill produces wood. Each building must be staffed by 1 laborer in order to produce.

Wood can be burned as fuel. Fuel is required for any kind of manufacturing e.g. ore smelting which will be added later.

Here are the effects of the different commodities:

Water - required to grow food. No water = no food produced in farms.
Food - required to feed people and livestock. No food = production halved.
Fuel - required for manufacturing. No fuel = 0 production in buildings that require fuel.

Now my questions are:
1. How would you go about designing city operation? Ultimately I will have many different commodity types such as weapons, armor, machinery, pottery, jewelry, etc... Likewise, there will be just as many building types which can produce different commodities. Would you prefer an incremental design approach where you start with a minimum set and introduce more? Or would you spend more time designing to come up with a comprehensive but cohesive set?

2. How should I determine the effects of commodities on production? For example the lack of water might affect food production only as described above or I could make water scarcity affect many things. E.g. thirsty laborers are unhappy which results in less production, lack of water makes basket weaving much more difficult, it also reduces the quality of bricks, etc... From a a game design point of view I see two approaches: one where water affects a minimal number of things or two where water has an effect on many different variables. What method do you prefer?

3. Livestock. I could make them a requirement for certain forms of production or I could make them into a force multiplier. In the case of the former I might have two types of buildings: a garden that produces food and requires only human labor and a farm which produces much more food but requires both humans and livestock. In the case of being a force multiplier livestock are optional additions to any building, they require 4x as much food as humans but increase production by 4x. Which approach would you choose and why?

Silver as a Game Currency

21 June 2009 - 05:25 PM

I'm creating a trading game that takes place during Ancient Babylonian times. While barter and other forms of currency were quite common I'm planning to make silver the primary currency in the game. Silver will be measured by mass: talents, minas, shekels, etc. When one goes to the marketplace and wants to see the prices, they will be listed in silver. Here's my dilemma. Prices in the game will change due to supply and demand (sub-systems I'm working on but won't bother going into much detail here). But the value of silver could also be subject to supply and demand. My question is if that is a good idea? Or should silver be fixed so that assuming the supply and demand for an item hasn't changed, its price in silver always remains constant? Pros (of the value of silver being subject to supply and demand): -Keeps things consistent in that all material resources follow the same pricing laws based on supply and demand. -Potential for player to really manipulate the markets by manipulating silver (which is something I want to encourage in this game) Cons: -likely more confusing for the player. Why has the price of bread (in silver) suddenly doubled when there's just as much as before? Oh wait, it's because there's a shortage of silver. -somewhat confusing for me the programmer. Commodities have a 'natural price' i.e. the value if the supply equals the demand. Normally I would state that in silver but now I would need a canonical (unitless) value hidden behind the scenes. Looking for your input to add to the pros/cons so that I can make a decision. Thanks kindly.