• Content count

  • Joined

  • Last visited

Community Reputation

620 Good

About Paragon123

  • Rank
  1. Adding to what SiCrane said... The hash code is only used for coarse sorting... if there is a hash collision there is still a true comparison used to sort/place the value. But this is helpful as a hash compare (comparing two integers) is faster then a string compare... so this way it only needs to do the expensive compare when there is a hash collision rather than not being able to take advantage of the faster hash comparison at all.
  2. Is your Logger global?

    I re-invented the wheel... a long long time ago. Now that is the only logger I use. Loggers them selves are instanced, but the log factory is global. I use instance loggers rather than global because I found it easier to mix and match loggers this way... my solution had a couple different logging types... log to file, log to console, log to window event viewer. Then It had a null logger for turning logging off, a multi logger for logging to multiple specific loggers with one log command and an ILog interface for application specific logging.   This way I can create a trace logger and an in game logger and an exception logger. Then when I release I can turn the trace logger into a null logger to "turn it off". The ILog interface allowed me to create a game specific log that logs to a GUI Element... so with one line log.Log("This"); it logs to both the GUI Control and the console and/or a file(That wouldn't be visible in non debug vers.)   Because the factory is global it is just as easy to access the loggers as it would be if the loggers where global... so... there that... i guess...
  3. Is your application or any of the libraries that you are using spawning threads? Sometimes if you close the main thread while there are background threads running you might experience a long pause after shutting down until those threads are cleaned up properly.    
  4. How are you encapsulating User-Inputs

    My input system is at the game level and not at the gamestate level. I am using sfml so the window causes events to fire when input is provided (more than likely using polling, but I haven't looked into the code)   Gamestates have a boolean value, AcceptInput and AcceptGameInput. AcceptGameInput is always true if AcceptInput is true, but AcceptGameInput can be false without AcceptInput being false. If AcceptInput is false than no is passed to any systems... if AcceptGameInput is false than the GUI/Pause etc will accept input but player action inputs aren't processessed.   I created a map from Key/Modifiers hash to messages so when a key is pressed, it looks to see if there is a message attached to that key and if there is it triggers a message to the messaging queue. The message does not contain any information about the input (such a which key it was or which modifiers) but it contains information about the action. So when I hit "W" it sends a "Move Forward" Message...   Each gamestate can create a unique keyboard map... which is both a blessing and a curse, because now II have to put "W" "Move Forward" in every gamestate... but it does allow some screens to have specific input/keys/actions that other game states don't... such as pressing "L" on the overworld map to "Land" your "Airship".   The Mouse gets a bit weird... when the mouse is clicked, it first tests if it is over any GUI Element... if it is then it triggers the OnClick Event for the GUI Element the mouse is hoving over. The OnClick Event can then dispatch a message to initiate an action the same way pressing a key will. Sometimes it gets a touch convulted... such as when a player presses "1" instead of trigger the action associated with the first actionbar slot it triggers a message that causes a "fake" click on the actionbar which then dispatches the actual input action message.   Then, individual systems look for the action message. I like this because with this configuration, only the GUI and the PlayerInput system have to deal with input directly.   It has been awhile since I really researched input... but I am fairly certain that you shouldn't really worry too much about the overhead of polling for input... this should be a fairly constant cost... and as far as I am aware, even if you rely on events from a framework it is highly likely that the framework is using polling behind the events.
  5. I agree with @Wavinator... on a couple of counts. First and foremost I agree that responding "You didn't think much about this, huh?" is a pretty rough way to answer someone trying to help out. Especially when considering some things, such as  Curses=Radiation wasn't even mentioned in the Original Post.   Fundamentally armor protects against physical attacks.... the classic bludgeoning/piercing/slashing. Elemental damage Fire/Lightning/etc... are generally not affected by armor. In some instances the material of the armor may alter the way the element effects the target... metal may increase damage from electrical attacks. Wood may catch fire and cause damage over time, water elements may cause someone wearing heavy cloth armor to be slowed...  The remaining sources as questioned in the Original post (Poison/Curses/Radiation/Disease) are Status effects... either the player is affected by the status effect or not. The damage is dealt to internal systems from an internal attack... armor won't protect you from damage within your body.    I read the part where you mentioned that armor may protect from the status effects delivery method... but it isn't like that is really going to matter much. A dagger isn't coated with exactly one lethal dose of poison... when selecting poisons to coat weapons with it is chosen for it's potency. The reason for coating a weapon with poison is because it is expected that it will be difficult to land an effect blow. Anything that provides enough radiation to cause real-time damage (rather than just future hairlose/impotency/etc) is going to need to be delivering such a quantity of radiation that armor is unlikely to have any effect especially since it would require lead armor to prevent radiation damage anyway. Curses and spells are magical and don't follow the rules of physical attacks. Any disease that requires physically introducing it to the system would be considered a poison in my opinion... the remaining diseases would be delivered through the air, which means that armor (barring hazmat suits or somesuch) would provide no protection.   So... saying all that, I think you might benefit from breaking these status effects into two categories. The first would include poison and such and would work much like you explain the bleed effect. In order for the status to be applied the attacker must get at least a single point of damage past the armor. The second group would be the status for which armor provides no protection... and in this case the attacker has to merely land a blow. They would work a lot like touch-based attacks in D&D.   In either case, once the status effect is applied armor won't be able to help.
  6. Simplicity vs. Complexity

    I think that a good game is a mixture of both complex and simple. The user is presented with simple choices, input, requests... but the game does complex operations and interrelations based on the users choices.   So, it should be simple for the player to manipulate the game and determine what the game is requesting the player to do... but the systems and mechanics should be deeper and more complex.    -or- Simple to play, complex to understand.    You shouldn't need to cross-reference three different charts to make an informed, useful decisions... but that chart cross-referencing should reward the player who does try to optimize at that level or detail.
  7. In my game players are able to push objects. I was looking for an easy way to make it such that if an object has wheels it is easier to push...   When a player runs into an object they generate an amount of force equal to their strength time 10. So, with 10 str. they can push 100lbs. Would it be as easy as just calculating the mass of the pushed object as Mass*wheelCoefficent if that object has wheels? Is 0.25 a reasonable coefficient for this? Would differences in wheels make a significant enough difference to make the coefficent specific to a type of wheel or would this just be unnecessary data clutter?  
  8. Currently, I have a hodge-podge of sprite sorces... I have some that are a collection of individual images in a directory, I have some that are in a sprite sheet with no meta-data indicating what is where and I have some that are in a sprite sheet with identifying meta-data.   I want to reduce the number of sprite sheets I have in total and also ensure that they are all sprite-sheets with identifying data.   I have written a quick application that lets me load all sorts of sprites and name them and everything, then it exports it to a png with a csv. The question I have is what size the sprite sheets should be. My game is targeting Windows Desktops only at the moment (It is written in c# and not meant for mobile... but I may eventually be ported to mono).    What is the optimal sprite sheet size? I originally was hoping that a single 512x512 sheet would be enough room, but that is turning out to not be the case. So, I started by seperating the sprites by functionality... however, even so I still can't fit all of a particular category onto a 512x512 sheet... so Should I increase the spritesheet size or bite the bullet and split it into a second sprite sheet?   Is there best practices regarding spritesheet size?
  9. Quick UX Opinion Question

      I suppose It would be... I just thought it would be awkward if you couldn't pick up something that you were standing over.
  10. In the game I am writing the player has a character sprite and the character sprite has a facing indicator. The facing indicator is always hovering over a cell adjacent to the players location. If the facing indicator is over an item with a context action it populates the context action button and the player can press this button to activate the context action.   The tile map has three layers.. from lowest to highest there is the ground, the floor and the blocking entity. An entity on any of these layers can have a context action associated with it.    If the question I have is the preferred priority order for the various context actions. I think I have narrowed it to two choices.   1) Indicator Blocking ent 2) Indicator Floor  3) Indicator Ground  4) Current Location Floor  5) Current Location Ground   -or- 1) Indicator Blocking ent 2) Current Location Floor 3) Current Location Ground 4) Indicator Floor 5) Indicator Ground   Basically, the question is if the things your are standing on should be considered before or after the things you are standing next to?
  11. Combat Thoughts for a MUD

    I wouldn't limit the number of characters in a room, unless you were doing some kind of instancing where once the capacity is full on an instance of the room a new instance is created for the next n players.   Maybe for combat, you could view the combat as a separate room.. the players in combat would be in two rooms at the same time, the combat room and the room from which the combat started.... the enemies being fought would only exist in the combat room... so player A walks into a room and starts fighting create x,y and z. Then player B walks into the room... he is able to see player A, but not creatures x,y or z.
  12. Freemium without pay to win

    Some of these needs/wants seem to be contradictory... The primary problem I see is that you want to do a monthly subscription but don't want to provide ads... if you are not showing ads then what does paying for the premium monthy membership actually do for the player? It looks like only some premium only areas, but since you want everyone on a level playing field you have to make sure that you can't become more powerful in a premium area then a non-premium area so why bother going to the premium area other than for the flavor of the zone.    Premium only items only avoids pay-to-win if the difference is cosmetic only... if you add premium only areas and they contain premium only items I can only see that leading to a time where there becomes a point that you are forced to become a premium member to have access to the highest level stuff because the premium members will want something beyond an alternate start area and would prefer an alternate end area.   You say you don't want Premium vanity items... but I think this is one of the few safe areas to give premium bonuses. To avoid pay-to-win you can really only give players the option to pay to be cooler... which pretty much translates to vanity items.   Require premium for respec seems like a bad idea. The best alternative I can think of is to limit how often players can respec and allow premium members to do it more often.     Extra stash is good, when premium ends I would say that the extra stash becomes withdraw only.      Here are some Ideas I thought of while reading your post... If you have a crafting system you could make it such that a premium membership is required to craft the high level items/consumables but any player are able to buy them. If having housing/shelter is an important aspect of the game you can make it such that only premium members are able to own/build housing and free-players have to "rent" housing using in game currency. When a premium player quits being premium, the players that are "renting" still pay rent, but the money disappears, and the house goes on sale for purchase by other premium members.    I don't see any reason to disallow free players from using in game currency to buy premium only currency from premium players. This will soften the wall between pay and free users and will give pay users a method for quick cash infusions, you might actually get more sales of premium only currency b/c of this than you would otherwise (Look at how kingdom of loathing handles Mr. Accessories for a good example).   So basically, you could try to make it such that all players free/premium are on equal footing for the action/adventure portion of the game... but it's the premium players that are fueling the economic bits.   Maybe have an in game store that sells items like Commercial Licence: cost 1 pCoin, upon use allows player to list items for sale for a week (player-to-player cash in hand would still be viable for free players, but an interface that keeps your items for sale while your offline wouldn't be) Manufacturers licence: cost 1pCoin, upon use allows player to craft high level items <other type of license>: cost 1pCoin, allows player to cultivate some premium only resource... maybe a high level metal for blacksmithing or high level plants for cooking herblism Exp Potion: Cost 3pCoin increase xp for timeperiod Vault: 5pCoin: increase stash size   The store sells licenses so that a premium player can spend x pcoins to gain y licences to sell for z gold.... now the free players are not entirely blocked from the premium actions, but the premium players don't mind because they are getting something out of the deal... rich.
  13. Passing data between states in an FSM

    I don't know if this will help you, but I generally take a different approach to FSMs. I usually define an enumeration of states, then implement each state as a delegate function accepting a data object specific to that state machine. enum states { state1, state2 } delegate stateDelegate(statedata data); Dictionary<states, stateDelegate> StateDelegates; statedata { states State int sharedInt string sharedString object sharedObj } void main() { statedelegates.add(state1, State1Delegate) statedelegates.add(state2, State2Delegate) //If you Require the state to be wrapped in a class SomeArbitraryClass sac=new SomeArbitraryClass() statedelegates.add(state3, sac.State3Delegate) statedata instanceData=new statedata() <initialize data> while(instanceData.State!=states.exit) { instanceData=statedelegates[instanceData.State](instanceData); } } statedata State1Delegate(statedata data) { <do stuff> return data } statedata State2Delegate(statedata data) { <do stuff> return data } class SomeArbitaryClass { stateData State3Delegate(Statedata data) { <Do stuff> return data } }
  14. Writing a formula is a bit like writing a sentence... it can be long and complex or short and simple, there are multiple ways to express the same thing, you can have two nearly identical expressions with two vastly different results. I don't think there is any way to algorithmically generate expressions that give a specific output, you have to build each formula on a case-by-case basis.   Find a formula with the basic shape you want. Linear, oscillating, tappered, bell curved etc... doesn't matter. take Y=f(x) as your basis function Y'=f'(x) as your modified function   To raise or lower a constant distance  Y=f(x)+c To shift right or left a constant distance Y=f(x-c) to stretch/shrink along the x axis Y=f(x*c) to stretch/shrink along the y axis Y=f(x)*c to travel the oppiste direction on the x axis Y=f(-x) to travel the oppisite direction on the y axis Y=-f(x)   a generic formula which can apply or not apply some transformations Y= (Y_Reflect/abs(Y_Reflect))*(Y_StrechCoefficent)*f((X_reflect/abs(X_reflect))*x-x_shift)+y_shift   When Y_Reflect<0 reflect vertically, when Y_reflect>0 don't modify output, when Y_reflect=0... function falls apart... constant output of 0 When X_Reflect<0 reflect vertically, when X_reflect>0 don't modify output, when X_reflect=0... function falls apart... constant output of f(0)   Here is a demo:       Of course this only works if you already have a function in mind that you want to modify in some way
  15. Coding-Style Poll

    I can't stand it when braces are not on their own line, it is too easy to miss one when the line is wider than the screen and matching braces by column is incredibly easy.    Class names, and public properties are Capitalized Parameters camelCase local variables don't matter as long as they are not  capitalized. starting with an _ is also acceptable (to me) private variables holding the data to a property is the same name as the property camelCased with a proceding _ public class Foo {   int _count;    public int Count   {     get     {       return _count;     }      set     {       _count=value;     }   } } The only time i use specific prefix or suffixes are with GUI elements, event handlers and delegates. User controls are prefixed with an _ and have a suffix indicating the type of control. Events are suffixed with EventHandler And delegates are suffixed with Delegate   Tabs as spaces is always better (IMO) than tabs as tabs.   I like to ensure that all parenthesis are explicit (unless the expression becomes unreadable because of it) I work in .net mostly, switching between and, I can not stand VB implicit parenthesis for subs without parameters... myObject.ToString just drives me up a wall compared to myObject.ToString()     When in doubt I try to find it here