The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.

Game Development Omni-thread [Unity, XNA, UDK, etc]

19293959798100

Posts

  • rembrandtqeinsteinrembrandtqeinstein Registered User regular
    SoaL wrote: »
    Also are you guys members of any gamedev communities?? I had a really fun time during the 7DFPS having all those people in irc to chat with and compare notes/screenshots...

    I just went to my first Unity meetup in DC. There were maybe 10 people of all levels from industry to "i just downloaded Unity last week". We were talking about possibly organizing a capital area game jam. It was well worth the trip and a really good time.

  • ToasticusToasticus yeah YEAHRegistered User regular
    Haven't posted here in a while since I'm mostly focusing on art dev right now, but this UI mockup is sorta designery so figured I'd drop it here and see what you guys think:
    UI_prototyping_01.jpg

    Just a photoshop mockup, for the targeting/firing mode of the UI. For now I'm thinking shooting doesn't cost movement points but you can only fire each weapon once per turn. So Judge has fired all his weapons but not moved, while Mozart has moved but not yet fired his weapons. Phase is offscreen to the left. Also planning to try out slowly constantly recharging shields, which only Phase, Mozart, and the enemy mech are equipped with here.

    I'm thinking that when you mouseover any percent bar it'll give you raw numbers. Might want to pick a specific color just for elements that pop up new windows or otherwise activate when you click on them... hmm...

  • MNC DoverMNC Dover Full-time Voice Actor Kirkland, WARegistered User regular
    Toasticus wrote: »
    Haven't posted here in a while since I'm mostly focusing on art dev right now, but this UI mockup is sorta designery so figured I'd drop it here and see what you guys think:
    UI_prototyping_01.jpg

    Just a photoshop mockup, for the targeting/firing mode of the UI. For now I'm thinking shooting doesn't cost movement points but you can only fire each weapon once per turn. So Judge has fired all his weapons but not moved, while Mozart has moved but not yet fired his weapons. Phase is offscreen to the left. Also planning to try out slowly constantly recharging shields, which only Phase, Mozart, and the enemy mech are equipped with here.

    I'm thinking that when you mouseover any percent bar it'll give you raw numbers. Might want to pick a specific color just for elements that pop up new windows or otherwise activate when you click on them... hmm...

    Like what you've got in the mock-up. A few suggestions though;

    Add some familiar icons next to the bars for readability. As it stands now, they are just bars or lines that don't make a lot of sense. Putting recognizable things icons like:
    -Boots, Footsteps, Treads, Arrows (movement icons)
    -Gun, Muzzle Flash, Bullet, Bullseye (attack icons)
    -Heart, Red Cross, HP (health icons)

    Maybe opaque out weapons or overlay a red X on them as they are used. Hope these were some of the types of suggestions you were looking for.

    I love game design and readability, but suck on the actual programming implementation of them. :(

    Need a voice actor? Hire me at bengrayVO.com
    Legends of Runeterra: MNCdover #moc
    Switch ID: MNC Dover SW-1154-3107-1051
    Steam ID
    Twitch Page
  • ToasticusToasticus yeah YEAHRegistered User regular
    Yeah, I might put an icon in for armor/health, which is right now what all of the unlabeled bars are. It might be worth giving health and shield bars different colors from the rest of the UI as well.

    The dashes show how many weapons on the mech have been used that turn -- none of Mozart's (current unit) weapons have been used yet. I don't think the dashes will need an icon, which would significantly clutter things.

  • MNC DoverMNC Dover Full-time Voice Actor Kirkland, WARegistered User regular
    Toasticus wrote: »
    Yeah, I might put an icon in for armor/health, which is right now what all of the unlabeled bars are. It might be worth giving health and shield bars different colors from the rest of the UI as well.

    The dashes show how many weapons on the mech have been used that turn -- none of Mozart's (current unit) weapons have been used yet. I don't think the dashes will need an icon, which would significantly clutter things.

    Red and blue are pretty universal for health and shields, although you could substitute green for either.

    As for the weapons, would it be easier to read if the weapon icons (the ones you have on the right panel) were displayed in place of the dashes. They'd be small, but you could color code their backgrounds for readability. When used, you could then remove them from the unit, opaque them down, or cross them out with red X marks.

    Need a voice actor? Hire me at bengrayVO.com
    Legends of Runeterra: MNCdover #moc
    Switch ID: MNC Dover SW-1154-3107-1051
    Steam ID
    Twitch Page
  • rembrandtqeinsteinrembrandtqeinstein Registered User regular
    Toasticus wrote: »
    Haven't posted here in a while since I'm mostly focusing on art dev right now, but this UI mockup is sorta designery so figured I'd drop it here and see what you guys think:
    UI_prototyping_01.jpg

    Just a photoshop mockup, for the targeting/firing mode of the UI. For now I'm thinking shooting doesn't cost movement points but you can only fire each weapon once per turn. So Judge has fired all his weapons but not moved, while Mozart has moved but not yet fired his weapons. Phase is offscreen to the left. Also planning to try out slowly constantly recharging shields, which only Phase, Mozart, and the enemy mech are equipped with here.

    I'm thinking that when you mouseover any percent bar it'll give you raw numbers. Might want to pick a specific color just for elements that pop up new windows or otherwise activate when you click on them... hmm...

    Looks great, have you thought about the game system itself? I know you have the health and shields and individual weapons there and different vehicle types. Are you planning on systems damage/anatomy based combat(like no game except dwarf fortress and abstract pnp rpgs), hybrid w/ anatomy + hp (battletech, FTL), or entirely HP based (xcom, most everything else)? Also what level of randomization is there like can attacks miss under normal circumstances?

  • ToasticusToasticus yeah YEAHRegistered User regular
    MNC Dover wrote: »
    Toasticus wrote: »
    Yeah, I might put an icon in for armor/health, which is right now what all of the unlabeled bars are. It might be worth giving health and shield bars different colors from the rest of the UI as well.

    The dashes show how many weapons on the mech have been used that turn -- none of Mozart's (current unit) weapons have been used yet. I don't think the dashes will need an icon, which would significantly clutter things.

    Red and blue are pretty universal for health and shields, although you could substitute green for either.

    As for the weapons, would it be easier to read if the weapon icons (the ones you have on the right panel) were displayed in place of the dashes. They'd be small, but you could color code their backgrounds for readability. When used, you could then remove them from the unit, opaque them down, or cross them out with red X marks.

    I think the dashes are enough for the purpose they serve, since they're mostly there to remind you of which mechs you've had take their shots that turn (i.e. at a quick glance, did I have this guy shoot yet?) and less which specific weapons remain -- basically just a reminder.

    If you aren't sure exactly which weapons have been fired you could just select that mech and open targeting again to see the full list. I'm not sure what my limits will be but it could conceivably go up to eight or nine weapons on some of the mechs, and having those reminders as dashes makes it a doable amount of screen space.

  • ToasticusToasticus yeah YEAHRegistered User regular
    Toasticus wrote: »
    Haven't posted here in a while since I'm mostly focusing on art dev right now, but this UI mockup is sorta designery so figured I'd drop it here and see what you guys think:
    UI_prototyping_01.jpg

    Just a photoshop mockup, for the targeting/firing mode of the UI. For now I'm thinking shooting doesn't cost movement points but you can only fire each weapon once per turn. So Judge has fired all his weapons but not moved, while Mozart has moved but not yet fired his weapons. Phase is offscreen to the left. Also planning to try out slowly constantly recharging shields, which only Phase, Mozart, and the enemy mech are equipped with here.

    I'm thinking that when you mouseover any percent bar it'll give you raw numbers. Might want to pick a specific color just for elements that pop up new windows or otherwise activate when you click on them... hmm...

    Looks great, have you thought about the game system itself? I know you have the health and shields and individual weapons there and different vehicle types. Are you planning on systems damage/anatomy based combat(like no game except dwarf fortress and abstract pnp rpgs), hybrid w/ anatomy + hp (battletech, FTL), or entirely HP based (xcom, most everything else)? Also what level of randomization is there like can attacks miss under normal circumstances?

    Yeah, very little is nailed down at this point but I do have some general plans. For now I'm planning on a minimum of left, center, right, and rear armor locations. Shields and weapons both draw upon the mech's power supply (maybe movement will too?). I'm considering the possibility of having shields reduce incoming damage rather than preventing it completely, with varying effectiveness by weapon type. Weapons will have varying ranges. There might be some randomization of weapon damage, but almost definitely some randomization of accuracy, which is one area the pilot using a mech will have a good deal of influence.

  • MNC DoverMNC Dover Full-time Voice Actor Kirkland, WARegistered User regular
    Toasticus wrote: »
    MNC Dover wrote: »
    Toasticus wrote: »
    Yeah, I might put an icon in for armor/health, which is right now what all of the unlabeled bars are. It might be worth giving health and shield bars different colors from the rest of the UI as well.

    The dashes show how many weapons on the mech have been used that turn -- none of Mozart's (current unit) weapons have been used yet. I don't think the dashes will need an icon, which would significantly clutter things.

    Red and blue are pretty universal for health and shields, although you could substitute green for either.

    As for the weapons, would it be easier to read if the weapon icons (the ones you have on the right panel) were displayed in place of the dashes. They'd be small, but you could color code their backgrounds for readability. When used, you could then remove them from the unit, opaque them down, or cross them out with red X marks.

    I think the dashes are enough for the purpose they serve, since they're mostly there to remind you of which mechs you've had take their shots that turn (i.e. at a quick glance, did I have this guy shoot yet?) and less which specific weapons remain -- basically just a reminder.

    If you aren't sure exactly which weapons have been fired you could just select that mech and open targeting again to see the full list. I'm not sure what my limits will be but it could conceivably go up to eight or nine weapons on some of the mechs, and having those reminders as dashes makes it a doable amount of screen space.

    That could work I guess. My only concern would be the extra steps of weapon checking, especially once you get into a 3-4 mechs with 5-6 weapons each. It's one thing if a mech has say 2 gatling guns and 1 rocket launcher, but something entirely different if it's wielding 7 unique weapons to remember. This is doubly important if you need certain combinations of weapons/mechs to attack different enemies.

    Certainly there should be a happy middleground somewhere. Perhaps a hotkey that brings up an overlay available weapons when held down. That way it's just a quick peek for reminding the player of what's available to them without permanently cluttering up the screen, basically the best of both worlds. Seems like it wouldn't be that hard to program either...says the guy bad at programming. :)

    Need a voice actor? Hire me at bengrayVO.com
    Legends of Runeterra: MNCdover #moc
    Switch ID: MNC Dover SW-1154-3107-1051
    Steam ID
    Twitch Page
  • rembrandtqeinsteinrembrandtqeinstein Registered User regular
    Toasticus wrote: »
    Toasticus wrote: »
    Haven't posted here in a while since I'm mostly focusing on art dev right now, but this UI mockup is sorta designery so figured I'd drop it here and see what you guys think:
    UI_prototyping_01.jpg

    Just a photoshop mockup, for the targeting/firing mode of the UI. For now I'm thinking shooting doesn't cost movement points but you can only fire each weapon once per turn. So Judge has fired all his weapons but not moved, while Mozart has moved but not yet fired his weapons. Phase is offscreen to the left. Also planning to try out slowly constantly recharging shields, which only Phase, Mozart, and the enemy mech are equipped with here.

    I'm thinking that when you mouseover any percent bar it'll give you raw numbers. Might want to pick a specific color just for elements that pop up new windows or otherwise activate when you click on them... hmm...

    Looks great, have you thought about the game system itself? I know you have the health and shields and individual weapons there and different vehicle types. Are you planning on systems damage/anatomy based combat(like no game except dwarf fortress and abstract pnp rpgs), hybrid w/ anatomy + hp (battletech, FTL), or entirely HP based (xcom, most everything else)? Also what level of randomization is there like can attacks miss under normal circumstances?

    Yeah, very little is nailed down at this point but I do have some general plans. For now I'm planning on a minimum of left, center, right, and rear armor locations. Shields and weapons both draw upon the mech's power supply (maybe movement will too?). I'm considering the possibility of having shields reduce incoming damage rather than preventing it completely, with varying effectiveness by weapon type. Weapons will have varying ranges. There might be some randomization of weapon damage, but almost definitely some randomization of accuracy, which is one area the pilot using a mech will have a good deal of influence.

    You might want to take a quick look at this game:Crescent Hawk's Revenge http://www.abandonia.com/en/games/977
    BattleTech_-_The_Crescent_Hawk%27s_Revenge_Coverart.png

    It is a real-time tactics game that fairly faithfully models the complicated BattleTech ruleset. It is ancient and you will probably need dosbox to play it but the thing to look at is how the UI presents the Mech information.

  • ToasticusToasticus yeah YEAHRegistered User regular
    MNC Dover wrote: »
    Toasticus wrote: »
    MNC Dover wrote: »
    Toasticus wrote: »
    Yeah, I might put an icon in for armor/health, which is right now what all of the unlabeled bars are. It might be worth giving health and shield bars different colors from the rest of the UI as well.

    The dashes show how many weapons on the mech have been used that turn -- none of Mozart's (current unit) weapons have been used yet. I don't think the dashes will need an icon, which would significantly clutter things.

    Red and blue are pretty universal for health and shields, although you could substitute green for either.

    As for the weapons, would it be easier to read if the weapon icons (the ones you have on the right panel) were displayed in place of the dashes. They'd be small, but you could color code their backgrounds for readability. When used, you could then remove them from the unit, opaque them down, or cross them out with red X marks.

    I think the dashes are enough for the purpose they serve, since they're mostly there to remind you of which mechs you've had take their shots that turn (i.e. at a quick glance, did I have this guy shoot yet?) and less which specific weapons remain -- basically just a reminder.

    If you aren't sure exactly which weapons have been fired you could just select that mech and open targeting again to see the full list. I'm not sure what my limits will be but it could conceivably go up to eight or nine weapons on some of the mechs, and having those reminders as dashes makes it a doable amount of screen space.

    That could work I guess. My only concern would be the extra steps of weapon checking, especially once you get into a 3-4 mechs with 5-6 weapons each. It's one thing if a mech has say 2 gatling guns and 1 rocket launcher, but something entirely different if it's wielding 7 unique weapons to remember. This is doubly important if you need certain combinations of weapons/mechs to attack different enemies.

    Certainly there should be a happy middleground somewhere. Perhaps a hotkey that brings up an overlay available weapons when held down. That way it's just a quick peek for reminding the player of what's available to them without permanently cluttering up the screen, basically the best of both worlds. Seems like it wouldn't be that hard to program either...says the guy bad at programming. :)

    Ah, probably something I should have pointed out earlier -- you swap between targeting mode and movement/selection mode on your current unit by right-clicking anywhere on the screen. While you are in targeting it shows the full list of all weapons on that mech, so it's very quick to pull up that detailed info if you want it.

    Overall I don't think it'll be that much of a concern since these are mechs you will be customizing yourself and using over the course of the campaign, but the proof of the pudding is in the eating so we'll see. When you see the dashes un-highlight with each weapon the unit fires it should click that that's what they're for. Once I get this prototype UI working I'll start iterating and seeing what works and what doesn't, with particular attention to how intuitive the interface is to use. If I find myself bringing up the targeting mode a lot to see what weapons a unit has I might look into other ways to display it like you're suggesting -- maybe the expanded top row panel for the current unit could show that info.

  • DelzhandDelzhand Registered User, Transition Team regular
    When unit customization is such a heavy part of the game, you tend to know what units have what. The big exception I can think of is when you have a lot of similar units on your team. Like in the beginning of FF Tactics, you often don't know what squires have throw stone, which chemist has Phoenix down, etc, because you have a couple of the same class on your team, but as the units diverge to fill different roles it usually becomes more clear. When you've only got one summoner and each ability costs a few hundred jp, you're unlikely to forget that she's got Shiva and Moogle.

  • MNC DoverMNC Dover Full-time Voice Actor Kirkland, WARegistered User regular
    Toasticus wrote: »
    MNC Dover wrote: »
    Toasticus wrote: »
    MNC Dover wrote: »
    Toasticus wrote: »
    Yeah, I might put an icon in for armor/health, which is right now what all of the unlabeled bars are. It might be worth giving health and shield bars different colors from the rest of the UI as well.

    The dashes show how many weapons on the mech have been used that turn -- none of Mozart's (current unit) weapons have been used yet. I don't think the dashes will need an icon, which would significantly clutter things.

    Red and blue are pretty universal for health and shields, although you could substitute green for either.

    As for the weapons, would it be easier to read if the weapon icons (the ones you have on the right panel) were displayed in place of the dashes. They'd be small, but you could color code their backgrounds for readability. When used, you could then remove them from the unit, opaque them down, or cross them out with red X marks.

    I think the dashes are enough for the purpose they serve, since they're mostly there to remind you of which mechs you've had take their shots that turn (i.e. at a quick glance, did I have this guy shoot yet?) and less which specific weapons remain -- basically just a reminder.

    If you aren't sure exactly which weapons have been fired you could just select that mech and open targeting again to see the full list. I'm not sure what my limits will be but it could conceivably go up to eight or nine weapons on some of the mechs, and having those reminders as dashes makes it a doable amount of screen space.

    That could work I guess. My only concern would be the extra steps of weapon checking, especially once you get into a 3-4 mechs with 5-6 weapons each. It's one thing if a mech has say 2 gatling guns and 1 rocket launcher, but something entirely different if it's wielding 7 unique weapons to remember. This is doubly important if you need certain combinations of weapons/mechs to attack different enemies.

    Certainly there should be a happy middleground somewhere. Perhaps a hotkey that brings up an overlay available weapons when held down. That way it's just a quick peek for reminding the player of what's available to them without permanently cluttering up the screen, basically the best of both worlds. Seems like it wouldn't be that hard to program either...says the guy bad at programming. :)

    Ah, probably something I should have pointed out earlier -- you swap between targeting mode and movement/selection mode on your current unit by right-clicking anywhere on the screen. While you are in targeting it shows the full list of all weapons on that mech, so it's very quick to pull up that detailed info if you want it.

    Overall I don't think it'll be that much of a concern since these are mechs you will be customizing yourself and using over the course of the campaign, but the proof of the pudding is in the eating so we'll see. When you see the dashes un-highlight with each weapon the unit fires it should click that that's what they're for. Once I get this prototype UI working I'll start iterating and seeing what works and what doesn't, with particular attention to how intuitive the interface is to use. If I find myself bringing up the targeting mode a lot to see what weapons a unit has I might look into other ways to display it like you're suggesting -- maybe the expanded top row panel for the current unit could show that info.

    Oh OK, that does make things a bit better. As a guy who plays tons of different strategy games, nothing is more painful than having to navigate menus after a long period of play. Anything that allows quick information is a blessing. This is why games on the DS/3DS are great with a ton of useful info on the bottom screen.

    Need a voice actor? Hire me at bengrayVO.com
    Legends of Runeterra: MNCdover #moc
    Switch ID: MNC Dover SW-1154-3107-1051
    Steam ID
    Twitch Page
  • LorkLork Registered User regular
    edited October 2013
    Everyone wrote:
    Help with Quaternions
    Thanks, guys. I haven't checked in here in a bit because of a particularly obnoxious week at work, but I'll try to figure out this whole laser thing with the help you posted.

    But first, can anyone tell me why this would return a null reference?
    public class SpawnPoint : MonoBehaviour 
    {
    	public GameObject enemy;
    	
    	public GameObject Spawn()
    	{
    		return (GameObject)Instantiate(enemy, transform.position + Vector3.up * 1.5f, transform.rotation);
    	}
    }
    

    I get a null reference exception when I call it here:
    void SpawnWave()
    {
    	enemyCount = 0;
    	Component[] spawnPoints;
    	spawnPoints = _manager.CurrentWave.GetComponentsInChildren<SpawnPoint>();
    		
    	foreach(SpawnPoint currentSpawnPoint in spawnPoints)
    	{
    			enemiesInWave[enemyCount] = currentSpawnPoint.Spawn();
    			enemyCount++;
    	}
    }
    

    The "Wave" consists of a prefab containing two SpawnPoints, which are both set up with a prefab containing an enemy (which does correctly spawn even though the Spawn() function returns a null reference.

    Lork on
    Steam Profile: Lork
  • DelzhandDelzhand Registered User, Transition Team regular
    Consider this alternate approach:
    public class SpawnPoint : MonoBehaviour 
    {
    	public GameObject enemy;
    	
    	public void Spawn()
    	{
    		GameObject g = (GameObject)Instantiate(enemy, transform.position + Vector3.up * 1.5f, transform.rotation);
    		g.transform.parent = this.transform;
    	}
    }
    
    void SpawnWave()
    {
    	enemyCount = 0;
    	Component[] spawnPoints;
    	spawnPoints = _manager.CurrentWave.GetComponentsInChildren<SpawnPoint>();
    		
    	foreach(SpawnPoint currentSpawnPoint in spawnPoints)
    	{
    		currentSpawnPoint.Spawn();
    	}
    }
    

    Now each spawn point has as it's children all the things it spawned. This has plenty of advantages. You could, if you wanted, still do a GetComponentsInChildren if you needed the count for calculations, or you could just iterate over its results whenever you need each child to do something. Also saves you the step of having to call GetComponent on every gameObject in your list.

  • LorkLork Registered User regular
    While thinking about your method it occured to me that all I really wanted to do was keep a count of how many enemies were remaining, so keeping an array of references to the enemies isn't actually necessary. All I really need to do is keep track of how many enemies were spawned and decrement the counter in an OnDeath() function on the enemies themselves. Much simpler. Thanks for the advice.

    Steam Profile: Lork
  • DelzhandDelzhand Registered User, Transition Team regular
    Hmm. I wonder what the best way to handle status effects is. My first preference is to implement them as components. So a "poison" component would just have an OnTurnInit function where it deals damage. "Regen" might have OnTurnInit that recovers hp.

    And ideally, in a unit's turn initialization, it would just get all the components that implement a function like OnTurnInit and just call it. But I don't think there's a way to do this.

    Can you subclass components? I could have a StatusEffect component and make the various types subclasses of that maybe, then I could call GetComponents<StatusEffect>...

    ...

    okay, I think I need to sleep and recharge my brain

  • GarthorGarthor Registered User regular
    Yes, you can subclass components. Though, also, you can just use SendMessage() to call a function on all applicable components. I'm not a particular fan of that, since it interferes with code completion stuff and muddies the waters a little bit.

  • DelzhandDelzhand Registered User, Transition Team regular
    Can I just remind everyone how much I hate monodevelop? I'm trying to debug a pretty serious flaw in my main engine's state machine, figuring out where certain changes are coming from. But the objects that are responsible for a good number of state changes are event collections, I can't debug them, because the hacked version of Monodevelop that comes with Unity has a bug where it can't see the contents of generic collections.

    So I basically had to, instead of just using List<T>.Add, had to write a function to intercept additions to the list.
    public List<ScenarioEvent> Events;
      public ScenarioTrigger Trigger;
      public ScenarioEvent[] EventInspector;
    
      public ScenarioGroup(){
        Events = new List<ScenarioEvent>();
      }
    
      public void EventAdd(ScenarioEvent s)
      {
        Events.Add(s);
        EventInspector = Events.ToArray();
      }
    

  • rembrandtqeinsteinrembrandtqeinstein Registered User regular
    edited November 2013
    Little proof of concept I'm working on. It is a remake of an Atari game (Atom Smasher for you old nerds) and figured it would be a good projec to cut my teeth on with Gamemaker.


    VALANCE

    screenshot.png


    Fly around the nucleus, free the electrons by shooting them, collect the to score points. Gravity and number of electrons increase w/ each stage. 36 is my top score, I think the max is 53. Ship can get stuck in the walls when turning right at the edge if you do it right.

    Edit: click the picture to download the game. The file is an installer without the .exe extension because my host doesn't allow uploading of files with the .exe extension. Add the .exe extension and run the installer to play.

    rembrandtqeinstein on
  • DelzhandDelzhand Registered User, Transition Team regular
    Rem, I tried to play the game, but it crashes right away. From the image and description it reminds me of Gyruss!

    In other news, although initially I wanted to define all of Ardor's commands in XML, it just had really gotten too unwieldy, so I decided just to write a function for each skill. I've essentially traded the ability to later have player defined command lists for a massively simpler system.

    There's just too much logic and it's really awful to try and abstract it all out into components. I feel as though a great weight has been lifted.

  • rembrandtqeinsteinrembrandtqeinstein Registered User regular
    Delzhand wrote: »
    Rem, I tried to play the game, but it crashes right away. From the image and description it reminds me of Gyruss!

    In other news, although initially I wanted to define all of Ardor's commands in XML, it just had really gotten too unwieldy, so I decided just to write a function for each skill. I've essentially traded the ability to later have player defined command lists for a massively simpler system.

    There's just too much logic and it's really awful to try and abstract it all out into components. I feel as though a great weight has been lifted.

    What did you have trouble with when you made your XML? There is certainly an initial investment, but after that adding new content or extending existing content is really easy.

    Also try this link for a new and improved Valance: https://dl.dropboxusercontent.com/u/221516245/Valance-Default-1.0.0.9.exe

    Now with LAZORS!

    screenshot.png

  • DelzhandDelzhand Registered User, Transition Team regular
    edited November 2013
    Well, consider this: activating a very basic attack involves several components.

    Face target
    Begin attack animation
    Add flash visual effect
    Play slash sound
    Start hurt animation for target
    Damage target based on formula
    Show pop up damage numbers

    So... What if you attack an empty hex? What if the enemy dodges? Blocks? Has an ability that mitigates a portion of physical damage?

    It gets even worse. When you target a hex, you see a preview of the effect, but this shouldn't include the random variance, which is often applied in the middle of calculations.

    I was already storing damage formulas in reverse polish notation with tokens, it just got way too nuts.

    Edit: for example, here's a basic attack's formula

    100 [CasterVigorMod] * [Variance] * [TargetArmorMod] *

    The problem became apparent when I tried to implement a skill that has a 20% chance to ignore the target's armor. Also without beefing up the parsing function I've got, there's no way to change the variance based on the skill. I've always been a proponent of designing your skills and building systems to support them, rather than seeing what skills can be implemented using the system you've got.

    Now I can just relax and handle it this way
    if (ArmorPen){
      damage = 100 * VigorMod(Caster) * Variance(.1);
    }
    else {
      damage = 100 * VigorMod(Caster) * Variance(.1) * ArmorMod(Target);
    }
    

    Delzhand on
  • rembrandtqeinsteinrembrandtqeinstein Registered User regular
    edited November 2013
    For my aborted tactics game attempt I used XML as the "raws" for data input. That way I had a human readable, yet machine usable data object (you know what XML was originally invented to be used for). And if I bothered to write up a DTD I could easily validate the input before the game proper started so that was another level of error checking. The first thing my game did when starting was read all the XML data and save it in appropriate data structures so I never touched the XML after the game loaded.

    How were you handling your XML that it was more difficult to work with? If you had game logic based on XML structure that you had to read at runtime I can understand but IMO that wouldn't be an XML issue so much as a "doing it wrong" issue.

    edit:

    Heh you edited your post while I was typing so I'll edit mine :)

    Maybe I'm reading something wrong but why would an attack hold its own formula? Wouldn't you have a single forumla for a "class" of attacks (magic, melee, missile, etc) then make your modifications there? So for your armor penetration why wouldn't you tell the target that the attach has armor penetration, and to return how much is left after the penetration value (min 0)? Maybe post the original code you were using so to see how you were doing the damage calc before.

    rembrandtqeinstein on
  • MachismoMachismo Registered User regular
    edited November 2013
    I was reading on the limitations of the non-pro unity engine, and it looked like alpha layers on textures was locked out. Is that true?
    One of the ideas I want to try is to have textures of the environment change smoothly based on a players action. I figure the easier way to do it is have a few texture layers and alpha blend them. Is it doable with out paying for the pro license?

    Machismo on
    steam_sig.png
  • GlalGlal AiredaleRegistered User regular
    edited November 2013
    You can see the license comparison here, just click the platform (simply Unity for desktop). As far as I know, the major limitation is inability to render to texture, but alpha layers are fair game? I use plenty of PNGs with transparency just fine.

    Glal on
  • rembrandtqeinsteinrembrandtqeinstein Registered User regular
    I've used alpha textures and transparency shaders just fine with Unity free.

  • DelzhandDelzhand Registered User, Transition Team regular
    For my aborted tactics game attempt I used XML as the "raws" for data input. That way I had a human readable, yet machine usable data object (you know what XML was originally invented to be used for). And if I bothered to write up a DTD I could easily validate the input before the game proper started so that was another level of error checking. The first thing my game did when starting was read all the XML data and save it in appropriate data structures so I never touched the XML after the game loaded.

    How were you handling your XML that it was more difficult to work with? If you had game logic based on XML structure that you had to read at runtime I can understand but IMO that wouldn't be an XML issue so much as a "doing it wrong" issue.

    edit:

    Heh you edited your post while I was typing so I'll edit mine :)

    Maybe I'm reading something wrong but why would an attack hold its own formula? Wouldn't you have a single forumla for a "class" of attacks (magic, melee, missile, etc) then make your modifications there? So for your armor penetration why wouldn't you tell the target that the attach has armor penetration, and to return how much is left after the penetration value (min 0)? Maybe post the original code you were using so to see how you were doing the damage calc before.

    I've tried very hard to make every skill in the game interesting in some way - there just aren't a lot of shared properties between attacks. I used the example of a basic attack, but there aren't any attacks that only differ in trivial ways like magnitude or element. There's no Fire, Fira, Firaga, you know? It's especially important because there's no leveling up outside of battle, all of the strategy comes from what skills you bring to the fight and how/when you use them.

    Now, one thing I could do is group events together - like the whole "face enemy, swing sword, play sound" routine for melee attacks, but that was never the hard part really.

  • IzzimachIzzimach Fighter/Mage/Chef Registered User regular
    So I tried writing a game using fluid simulation. It kinda worked, but making puzzles based on fluidic goop flowing around is not very easy. I mean it's cool to see swirls and whorls and stuff, but it's hard to get the stuff to go exactly where you want, so the puzzle has a be quite forgiving. Still, I'm happy it worked at all!

    yAL7dus.png

  • DelzhandDelzhand Registered User, Transition Team regular
    edited November 2013
    I created a vimeo account because a) the quality is better and b) I'm vaguely making some kind of statement against YouTube's recent changes. I got marked as a spammer and then my video was removed because gameplay videos aren't allowed. But the rules make a notable exception for developers showing off their own work, and I've sent them an email to that effect, so hopefully this gets cleared up soon.

    Delzhand on
  • rembrandtqeinsteinrembrandtqeinstein Registered User regular
    If anyone is doing 2d work GameMaker has nice sprite editing tools even in the free version. So its probably worth getting just for those.

  • TechnicalityTechnicality Registered User regular
    I discovered something a bit weird in Unity at work yesterday.

    If you are raycasting a lot, casting in a scene containing say 1000 colliders runs a lot faster than casting in a scene containing 2000 colliders where 1000 of those are turned off or on a layer that the raycast doesn't interact with. I had to physically remove the extra colliders from my prefabs before it would run acceptably again, and the profiler showed it was definitely the raycasts causing the slowdown.

    I would have thought the first thing the raycast algorithm would do would be to remove things it couldn't hit from checks.

    handt.jpg tor.jpg

  • DelzhandDelzhand Registered User, Transition Team regular
    But isn't that all a raycast does? How would it know it can't interact with them if they're on a valid layer and enabled?

  • EchoEcho ski-bap ba-dapModerator, Administrator admin
  • DelzhandDelzhand Registered User, Transition Team regular
    edited November 2013
    That's rad as hell, and even though we all know Unity treats 2D and 3D the same, I can't believe it took this long to think about applying normal maps to pixel art.

    In other news, I may have just written the ugliest line of code in my game.
    float degreeOffset = (items.Count % 2 == 0 ? (items.Count / 2 % 2 == 0 ? 360f / items.Count / 2f : 0) : 90 );
    

    Delzhand on
  • Death of RatsDeath of Rats Registered User regular
    I spent 2 days trying to figure something out, feeling ridiculously stupid about it.

    In my tetris like puzzle game, I have each "panel" of the "grid" being made up of a gameobject. I have each panel add itself to a "masterlist" of all the panels on the grid. Then I have a method called "find panel by position" which would take an x and y, and search through the list to find the panel I'm looking for, or return null if there was no panel.

    I use this all over the place, and once I started trying to optimize the game, I realized this was a major resource hog (this method can be called upwards of 32 times in a frame). Frames where it would be called allot would slow the framerate down to around 600fps from 1400fps. So I decide to look for another way to do it.

    The simplest solution, place a collider on each panel, and then use either raycast on the position or sphere cast, and grab whatever it found (again, returning null if nothing was found). Which seemed to work great.

    However, I noticed things started getting all crazy by doing it this way. Normally it would work fine, but if the grid rotated 90 degrees after the rotation everything would possibly break. Most noticeably the ghosts for the player controlled blocks would just randomly go to the wrong position after the rotation animation was finished.

    So I poked and prodded and just couldn't figure out what was happening. I figured something was wrong with the code for the animation, and I tore it apart and changed anything I possibly could. For at least 8 hours total. With no luck.

    Until I realized physics objects don't have their positions calculated every update. They do it on FixedUpdate.

    Oh.

    So all I had to do was set my animation class to wait until the animation was over, set a bool to true, and then change my gamestate back to playing and update the pieces with their new positions and everything works fine.

    And my game is now running at a pretty stable 1200-1400 fps. Yay!

    I swear, learning to program this way has a way of making me feel uncontrollably stupid when I run up against problems dealing with concepts I didn't even know existed. Guess that's just part of the learning process.

    No I don't.
  • LaCabraLaCabra MelbourneRegistered User regular
    edited November 2013
    I was experimenting with normal mapped pixel art (well, very low res unfiltered textures) on UDK a while ago, it is one of my favorite things
    it was for this retro style thing we were doing
    9919899413_de478130f4_h.jpg

    LaCabra on
  • DelzhandDelzhand Registered User, Transition Team regular
    I guess you need a pro account to put game dev stuff on Vimeo. That sucks.

    I think I might create a tumblr though. I definitely want to start making more of an effort to create promo content while the game is still in development.

  • surrealitychecksurrealitycheck lonely, but not unloved dreaming of faulty keys and latchesRegistered User regular
    bros

    if u r doin these tweenins u might wanna consider dumping itween (because its a slow unintuitive dumpster) and getting HOTween or leantween, both of which are free and run about 2-5 times as fast

    they got some sicknasty tween action goin on

    3fpohw4n01yj.png
  • LorkLork Registered User regular
    edited November 2013
    Can anyone tell me why this raycast wouldn't be hitting the player?
    RaycastHit rayHit;
    Ray ray = new Ray(transform.position, beamEndPoint);
    
    if(Physics.Raycast(ray, out rayHit, maxDistance))
    {		
    	aimPoint = rayHit.point;
    			
    	Stats enemyStats = rayHit.collider.GetComponent<Stats>(); 
    	Transform T = rayHit.collider.transform;
     	while(T.parent!=null && enemyStats == null)
    	{	
    		enemyStats = T.GetComponent<Stats>();
    		Debug.Log (T.name);
    		T=T.parent;
    	}
    				
    	if(enemyStats != null)
            {
    	        enemyStats.takeDamage(1f, 1f, false);
                    Debug.Log (enemyStats.gameObject.name);
            }
    }
    
    I can read the debug message telling me that it's hitting the walls and I'm using the endpoint of this raycast to draw a linerenderer, so I can actually see the line stopping when it hits the player, and yet it still only reports hitting the walls.

    Lork on
    Steam Profile: Lork
This discussion has been closed.