- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
This is a recipe for disaster in a game engine.
That's an interesting attitude; why do you say that?
|
#
?
Aug 3, 2012 02:48
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
|
#
?
May 12, 2024 00:30
|
|
- Suspicious Dish
- Sep 24, 2011
-
2020 is the year of linux on the desktop, bro
-
Fun Shoe
|
That's an interesting attitude; why do you say that?
Just so we're on the same page, by "event" do you mean something like DOM events where you attach a callback to an event like "drawn" or something?
I like that approach, but in moderation. A good use of this is a "Clicked" handler for a button, but for something like "StartParticleForMe", on which the ParticleManager listens, you're basically calling a method, but in reverse. It's this form of loose coupling which is super fragile, and now the compiler doesn't tell you you hosed up. Also, it's slower, due to the indirection here, and the compiler can't easily optimize it away.
I don't see what's wrong with passing around a ParticleManager, or having a global in this case.
|
|
#
?
Aug 3, 2012 03:00
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
Just so we're on the same page, by "event" do you mean something like DOM events where you attach a callback to an event like "drawn" or something?
I like that approach, but in moderation. A good use of this is a "Clicked" handler for a button, but for something like "StartParticleForMe", on which the ParticleManager listens, you're basically calling a method, but in reverse. It's this form of loose coupling which is super fragile, and now the compiler doesn't tell you you hosed up. Also, it's slower, due to the indirection here, and the compiler can't easily optimize it away.
I don't see what's wrong with passing around a ParticleManager, or having a global in this case.
Yeah, I figured we had to be talking a little crosswise, and I should have said "message" not "event", that was just a misstatement on my part.
For a particle system, in most cases I'd probably just have a singleton, I agree with that.
In the general case for event-driven game engines, I was talking about something very lightweight, and part of the engine itself. By "event driven", I usually just mean having some sort of system for sending a typed message of some sort, and having game objects able to respond to it, without one object necessarily knowing the composition (and thus specific interface) of another object.
so dealing with object->object interactions like this:
Object->SendMessage( DamageMessage( 500 ) )
rather than like this:
Object->SubtractHitpoints(500)
|
|
#
?
Aug 3, 2012 03:56
|
|
- Suspicious Dish
- Sep 24, 2011
-
2020 is the year of linux on the desktop, bro
-
Fun Shoe
|
Why the indirection? The behavior that an actor can potentially just flat out ignore a DamageMessage without the caller knowing it seems really dangerous.
|
|
#
?
Aug 3, 2012 04:02
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
Why the indirection? The behavior that an actor can potentially just flat out ignore a DamageMessage without the caller knowing it seems really dangerous.
There are many strengths to a message driven engine, so I won't be exhasutive here, and, in my opinion, it's not about how an object behaves when the function is called on it which differentiates them. In both situations, with a flexible enough system, the destination object could (and should) ignore the damage. Imagine the case of a target object that has a shield that absorbs 1000 damage.
For this example, In both cases, ultimately, some chunk of code is handling the damage taken, opaque to the calling object.
So, for the example of a 1000 damage shield, one solution is to implement that in the TakeDamage() function itself. This works for simple game architectures, but blows up in complexity with large ones. i.e:
TakeDamage( int HowMuch )
{
if( MyShieldAmount > 0 ) HowMuch -= MyShieldAmount;
MyHealth -= HowMuch;
}
However, now, every single call to takedamage, for every object in your system, must go through all of the potential modifications to damage.
In an event driven system, with a correctly chained component system handling the messages, you can share one very simple take damage at the bottom of a chain:
HandleTakeDamage( Message DamageMessage )
{
MyHealth -= DamageMessage.HowMuch;
}
but you could, for example, add a component that 'catches' that event before the base component, to any object that has a shield:
HandleTakeDamage( Message DamageMessage )
{
DamageMessage.Amount -= ShieldAmount;
}
So objects with a shield have two components, and objects without a shield have one very efficent handler.
You give up a slight amount of baseline efficiency on the messaging redirection, but gain a huge amount of simplicity in the normal execution pipeline. Simple objects have simple components, and more complex objects have more, more complex, components handling the messages.
|
|
#
?
Aug 3, 2012 04:15
|
|
- Shalinor
- Jun 10, 2002
-
Can I buy you a rootbeer?
|
Just, uh, some food for thought. LEGO Universe was built to have a highly modular, component-based structure. It was architected relatively cleanly, designed such that components were reusable, yadda. Exactly the kind of pie in the sky "use messages!" engine you'd expect.
On minspec, 20% of the frame was spent just processing messages
... which killed us.
So yeah, don't fling messages around without some thought to how many are receiving them, how you're routing them, how many handoffs or up/downcasts are in that process, etc.
(in our case, it had to tunnel up to the base component class, across to the interface class, up to the base interface class, through the message handler, to the interface class that handled messages of that type, then all the way back down to the target. Which is not an usual structure, if you make a generic message routing system.)
Jewel - but the point is, even professionals make dumb mistakes like that. Don't freeze, just do something. Yeah, you'll screw it up, who cares, that's code. You'll learn, and do it better the next time.
Shalinor fucked around with this message at 04:45 on Aug 3, 2012
|
|
#
?
Aug 3, 2012 04:40
|
|
- Suspicious Dish
- Sep 24, 2011
-
2020 is the year of linux on the desktop, bro
-
Fun Shoe
|
So, for the example of a 1000 damage shield, one solution is to implement that in the TakeDamage() function itself. This works for simple game architectures, but blows up in complexity with large ones. i.e:
TakeDamage( int HowMuch )
{
if( MyShieldAmount > 0 ) HowMuch -= MyShieldAmount;
MyHealth -= HowMuch;
}
However, now, every single call to takedamage, for every object in your system, must go through all of the potential modifications to damage.
What about the traditional methods of code reuse? Like functions?
code:TakeDamage( int HowMuch )
{
HowMuch = AdjustDamage(HowMuch);
MyHealth -= HowMuch;
}
AdjustDamage( int HowMuch )
{
if ( MyShieldAmount > 0 ) HowMuch -= MyShieldAmount;
return HowMuch;
}
|
|
#
?
Aug 3, 2012 04:44
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
Just, uh, some food for thought. LEGO Universe was built to have a highly modular, component-based structure. It was architected relatively cleanly, designed such that components were reusable, yadda. Exactly the kind of pie in the sky "use messages!" engine you'd expect.
On minspec, 20% of the frame was spent just processing messages
... which killed us.
So yeah, don't fling messages around without some thought to how many are receiving them, how you're routing them, how many handoffs or up/downcasts are in that process, etc.
It has it's downsides, but for a complex engine, what's the alternative?
Certainly you've got channels like rendering/network stack that probably need to be mainlined between objects, but is there a reasonable alternative you've encountered to some sort of component driven architecture for basic game logic once you get into highly variable worlds that aren't just dudes shooting rockets?
|
|
#
?
Aug 3, 2012 04:44
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
Now every component simply needs to adjust the damage beforehand. And it's a lot more straightforward rather than grepping to see that oh, the shield damage is taken in here because somebody added a global event mangler here.
I'm not sure how multiple components would exist in your design there. A particular object might inherit and over-ride Adjust Damage, but there's no clean way to include two damage-adjusting behaviors in a single object in your proposal, without defining a new overriding class that combines both.
quote:
Jewel - but the point is, even professionals make dumb mistakes like that. Don't freeze, just do something. Yeah, you'll screw it up, who cares, that's code. You'll learn, and do it better the next time.
Yes, do anything. If you don't come out of any project wishing you did almost everything differently/better, you probably aren't paying enough attention.
|
|
#
?
Aug 3, 2012 04:49
|
|
- Shalinor
- Jun 10, 2002
-
Can I buy you a rootbeer?
|
It has it's downsides, but for a complex engine, what's the alternative?
Certainly you've got channels like rendering/network stack that probably need to be mainlined between objects, but is there a reasonable alternative you've encountered to some sort of component driven architecture for basic game logic once you get into highly variable worlds that aren't just dudes shooting rockets?
... but if you built it right, you do. A sound emitted in an area. We know what entities have ears, so boom, subset already there of who cares about it. Bam, we read off the type, and kablooey, we know it has Listen() or whatever - so just call it.
A complex engine does not require complex components and wiggly who-knows component bundles. It demands even simpler components, just more of them, built to purpose, attached in specific ways immediately recognizable as one of a limited set of entity types.
The wiggly entities are only suitable in prototypes. They'll bog production games down something fierce, every step of the way. (they slow down programmers trying to make sense/implement, they confuse designers and result in buggy interactions, etc)
Shalinor fucked around with this message at 04:53 on Aug 3, 2012
|
|
#
?
Aug 3, 2012 04:49
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
Yes. Avoid overly generic components. Design your entities to fit within tight definitions of each possible type, and let them speak directly to each other whenever possible. No up/down, just straight across, and to the specific component that cares about the event. Which is to say, yes, call TakeDamage directly if you can, and only do a generic message if you have no choice.
... but if you built it right, you do. A sound emitted in an area. We know what entities have ears, so boom, subset already there of who cares about it. Bam, we read off the type, and kablooey, we know it has Listen() or whatever - so just call it.
Yeah, in Caves of Qud I ended up exposing very-commonly-called components (which I knew were typically present) like 'physics' or 'render' directly on objects to get adequate performace on a frame by frame basis. I'm certainly not rallying for a "you must have everything happen through a completely generic message" perfect world. I was just suggesting that if you're just building 'a game', for learning, you can do worse than building a messaging system and using that for stuff until performance becomes an issue in any particular case.
Eschewing generic messages altogether would be a complete nightmare with a system with as many unique item behaviors and behavioral mutability as Caves of Qud though. 
e: and if I had to do it over, I wouldn't even try to compontentize "render" and "physics", probably. If you're a game object, you're just going to have have those really core behaviors, and I'm going to streamline them.
Small unique behaviors and interactions I'd still be happy to handle through components, though. (but, I'm not building MMOs  )
Unormal fucked around with this message at 04:57 on Aug 3, 2012
|
|
#
?
Aug 3, 2012 04:54
|
|
- Shalinor
- Jun 10, 2002
-
Can I buy you a rootbeer?
|
Eschewing generic messages altogether would be a complete nightmare with a system with as many unique item behaviors and behavioral mutability as Caves of Qud though.
... though in this day and age, I suppose you'd use delegates to much the same effect. But that's nowhere near as cool.
Anyways, no, eschewing messages entirely is a bit silly. Sometimes, it makes perfect sense to send a generic message. Just, try and make sure you only do it for true "events", and only between separate entities. If you ever get in a situation where you send a message to yourself to get your current health... you've almost certainly gone too far. Unless you've doing a weird sandbox roguelike thingy which severe item mutability, in which case, you have little choice and you're just accepting the fact that it'll be slow.
Shalinor fucked around with this message at 05:01 on Aug 3, 2012
|
|
#
?
Aug 3, 2012 04:57
|
|
- Suspicious Dish
- Sep 24, 2011
-
2020 is the year of linux on the desktop, bro
-
Fun Shoe
|
I'm not sure how multiple components would exist in your design there. A particular object might inherit and over-ride Adjust Damage, but there's no clean way to include two damage-adjusting behaviors in a single object in your proposal, without defining a new overriding class that combines both.
Without any concrete specifications on what different components are allowed to do, I cannot make a decision as to the architecture. Tell me what your app needs to do and I'll do it.
But if different components need to different things, I don't see how your event mangler helps at all here. Would I attach a "SwordDamageEventMangler" to one component, and a "ShieldDamageEventMangler" to another? What's wrong with "AdjustSwordDamage" and "AdjustShieldDamage". There's certainly nothing wrong with code that does that's straightforward and easy to read, even if there's two lines of repetition somewhere.
|
|
#
?
Aug 3, 2012 05:28
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
But if different components need to different things, I don't see how your event mangler helps at all here. Would I attach a "SwordDamageEventMangler" to one component, and a "ShieldDamageEventMangler" to another? What's wrong with "AdjustSwordDamage" and "AdjustShieldDamage". There's certainly nothing wrong with code that does that's straightforward and easy to read, even if there's two lines of repetition somewhere.
There's no question, your needs and scope should be the ultimate rationale behind your architecture. There's upsides and downsides to each approach, and you need to take a serious look at your overall requirements when deciding what approach to take.
A very well defined set of objects and interactions? Just use completely intercommunicating objects, heck I think quake had only one kind of object, period.
For a completely ill-defined set of objects and interactions where no two objects are particularly alike? Use all generic messages.
For something in between, use something in between. One size doesn't fit all.
components rule, inheritance sucks
|
|
#
?
Aug 3, 2012 05:34
|
|
- Suspicious Dish
- Sep 24, 2011
-
2020 is the year of linux on the desktop, bro
-
Fun Shoe
|
I was asking you to defend the component architecture rather than say "OK, sure, use whatever you think might be more useful", but sure, use whatever you think might be more useful.
A very well defined set of objects and interactions? Just use completely intercommunicating objects, heck I think quake had only one kind of object, period.
Nope. It had a lot of structures and functions that acted on those structures. Some of the structures had function pointers.
If that's not a separate object, I don't know what is.
|
|
#
?
Aug 3, 2012 05:39
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
I was asking you to defend the component architecture rather than say "OK, sure, use whatever you think might be more useful", but sure, use whatever you think might be more useful.
To address the point about Adjust Sword and Adjust Shield damage, no it'd be silly to have just those two on separate components.
My specific requirements for a pretty generic engine are to support situations like:
A web-spinning smart spider with wings, the ability to phase through solid objects and a mental force shield's body is taken over by the player via mind control (becoming the active player object [any object in the game is required to be fully controllable] the player can play the creature in full, as he could any creature or item in the game) who then picks up and equips a force bracelet that allows a similar but not identical kind of force field, takes an drug that turns his body (the spider) to rubber, and is then pushed down a 40 foot hole, landing on a pile of worms, survives because his body is made of rubber, but killing one of the worms with the impact which causes him (the spider) to gain enough experience to level up the spider allowing him to grow a set of quills, but causing enough damage to send the player back to his idle body.
...also tomorrow you are going to have to add a room full of chambers filled with cryogenic gas with breakable glass, including a plant that grows in a fractal pattern (unique to the game), and ancient unique bear-monster that wields a vibro blade and wears a jetpack capable of (unlike anything else in the entire game so far) jetting him around the room 30 squares at a time granting a huge bonus to penetration if hit hits anything in that time.
Next day, you have to add something else novel like that, you don't know what it's going to be.
Actual, non made up example. In my opinion, a pretty good case for a pretty generic and flexible component-driven system.
Not the common case in general, though.
|
|
#
?
Aug 3, 2012 06:04
|
|
- Suspicious Dish
- Sep 24, 2011
-
2020 is the year of linux on the desktop, bro
-
Fun Shoe
|
What does any of that have to do with components?
Wait.
What does any of that have to do with game development? You know you're in CoC, not TCC, right?
|
|
#
?
Aug 3, 2012 06:19
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
What does any of that have to do with components?
Wait.
What does any of that have to do with game development? You know you're in CoC, not TCC, right?
That's just a description of [a very small subset] of things that happen in my game. None of that is creative writing.
http://forums.freeholdentertainment.com/
You're welcome to play it!
It takes almost 700 components to make it work. Could I do it without a data-driven component based system? Maybe; but there's nothing TCC about it.
code:World.Damage.cs World.GameObject.cs
World.GameObjectFactory.cs World.ModificationFactory.cs
World.Player.cs World.Statistic.cs
6 File(s) 158,510 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Part Builders
World.PartBuilder.cs
1 File(s) 186 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Part Builders\Body
World.PartBuilders.BodyHumanoid.cs World.PartBuilders.BodyPlants.cs
World.PartBuilders.BodyQuadraped.cs
3 File(s) 6,603 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Part Builders\Inventory
InventoryChestJunk.cs
1 File(s) 9,898 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts
World.Part.cs World.Parts.ActivatedAbilities.cs
World.Parts.Armor.cs World.Parts.Breeder.cs
World.Parts.Chat.cs World.Parts.Combat.cs
World.Parts.Commerce.cs World.Parts.Connect.cs
World.Parts.Container.cs World.Parts.Corpse.cs
World.Parts.Cursed.cs World.Parts.Daylight.cs
World.Parts.Description.cs World.Parts.Door.cs
World.Parts.EnergyCell.cs World.Parts.EnergyCellSocket.cs
World.Parts.Examiner.cs World.Parts.Experience.cs
World.Parts.Food.cs World.Parts.Forcefield.cs
World.Parts.Hidden.cs World.Parts.HiddenRender.cs
World.Parts.Inventory.cs World.Parts.LairFinder.cs
World.Parts.Leveler.cs World.Parts.LightSource.cs
World.Parts.MeleeWeapon.cs World.Parts.Physics.cs
World.Parts.QuestStepFinisher.cs World.Parts.RandomLoot.cs
World.Parts.Render.cs World.Parts.SendEndSegment.cs
World.Parts.Shield.cs World.Parts.Stacker.cs
World.Parts.Stainless.cs World.Parts.StairsDown.cs
World.Parts.StairsUp.cs World.Parts.Stasisfield.cs
World.Parts.Stomach.cs World.Parts.Swarmer.cs
World.Parts.TerrainTravel.cs World.Parts.ThrownWeapon.cs
World.Parts.WaterContainer.cs
43 File(s) 454,756 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Applicators
World.Parts.Applicator.cs World.Parts.DesalinationPellet.cs
World.Parts.FixitSpray.cs World.Parts.Polygel.cs
4 File(s) 9,030 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Baetyls
World.Parts.RandomAltarBaetyl.cs
1 File(s) 10,575 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Body
World.BodyPart.cs World.Parts.Body.cs
2 File(s) 26,236 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Books
Books.cs
1 File(s) 7,374 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Brian
World.AI.ObjectOpinion.cs World.Parts.Brain.cs
2 File(s) 41,698 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Brian\Behavior Parts
World.Parts.AIFlocks.cs World.Parts.AIJuker.cs
World.Parts.AIKillStuckStuff.cs World.Parts.AISeekHealingPool.cs
World.Parts.AIShootAndScoot.cs World.Parts.AIThrowAndScoot.cs
World.Parts.AITryKeepDistance.cs World.Parts.TargetMe.cs
8 File(s) 15,801 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Brian\Goal Handlers
World.AI.GoalHandler.cs World.AI.GoalHandlers.Bored.cs
World.AI.GoalHandlers.Confused.cs World.AI.GoalHandlers.Dormant.cs
World.AI.GoalHandlers.Flee.cs World.AI.GoalHandlers.Kill.cs
World.AI.GoalHandlers.Wait.cs World.AI.GoalHandlers.Wander.cs
8 File(s) 46,045 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Brian\Goal Handlers\Behavior Goals\Movement
World.AI.GoalHandler.MoveTo.cs World.AI.GoalHandler.Step.cs
World.AI.Pathfinding.cs
3 File(s) 35,735 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Conversations
World.Parts.Conversation.cs
1 File(s) 1,487 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Conversations\Conversation Loader
World.ConversationLoader.cs World.ConversationScriptUtility.cs
2 File(s) 18,937 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Conversations\Quest Loader
World.QuestLoader.cs
1 File(s) 5,687 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Custom Creature Properties
World.Parts.AcidCorpseExplosion.cs
World.Parts.AcidImmunity.cs
World.Parts.Alchemist.cs
World.Parts.BloodRingWeakness.cs
World.Parts.Cloneling.cs
World.Parts.DischargeOnDeath.cs
World.Parts.Diseased.cs
World.Parts.DiseaseMelee.cs
World.Parts.DroidScramblerWeakness.cs
World.Parts.DrowsingUrchin.cs
World.Parts.Ecstasy.cs
World.Parts.ElectricImmunity.cs
World.Parts.ElementalJelly.cs
World.Parts.Frenzy.cs
World.Parts.GelatenousPalmProperties.cs
World.Parts.GiantAmoeba.cs
World.Parts.HornedChameleon.cs
World.Parts.Ironshroom.cs
World.Parts.JiltedLoverMelee.cs
World.Parts.JoppaZealot.cs
World.Parts.LiquidBurst.cs
World.Parts.Madpole.cs
World.Parts.MimicProperties.cs
World.Parts.MoltingBasilisk.cs
World.Parts.Plastronoid.cs
World.Parts.PoisonMelee.cs
World.Parts.QudzuMelee.cs
World.Parts.RandomDrugs.cs
World.Parts.Slumberling.cs
World.Parts.Snailmother.cs
World.Parts.Sweeper.cs
World.Parts.TrollKing.cs
World.Parts.Twinner.cs
World.Parts.Yempuris.cs
World.Parts.Yonderbrush.cs
World.Parts.YoungIvory.cs
36 File(s) 114,547 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Cybernetics
World.Parts.Cybernetic.cs World.Parts.Cybernetics.cs
World.Parts.CyberneticsCreditWedge.cs World.Parts.CyberneticsIntro.cs
World.Parts.CyberneticsTerminal.cs World.Parts.Implant.cs
XRL.UI.Cybernetics.cs
7 File(s) 35,459 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Cybernetics\Arm
World.Parts.Cybernetics.Eigencannon.cs
1 File(s) 1,583 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Cybernetics\Indexer
World.Parts.Cybernetics.BioIndexerModule.cs
World.Parts.Cybernetics.TechIndexerModule.cs
2 File(s) 3,451 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Cybernetics\Ocular
World.Parts.Cybernetics.NightVisionModule.cs
1 File(s) 2,617 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Effects
World.Effect.cs
World.Parts.Effect.BoostStatistic.cs
World.Parts.Effects.Asleep.cs
World.Parts.Effects.Bleeding.cs
World.Parts.Effects.Blind.cs
World.Parts.Effects.Bloody.cs
World.Parts.Effects.Broken.cs
World.Parts.Effects.Burning.cs
World.Parts.Effects.Cripple.cs
World.Parts.Effects.Dazed.cs
World.Parts.Effects.Disoriented.cs
World.Parts.Effects.Exhausted.cs
World.Parts.Effects.Frozen.cs
World.Parts.Effects.LifeLeech.cs
World.Parts.Effects.Lost.cs
World.Parts.Effects.Lovesick.cs
World.Parts.Effects.Paralyzed.cs
World.Parts.Effects.Phased.cs
World.Parts.Effects.Poisoned.cs
World.Parts.Effects.PoisonGasPoison.cs
World.Parts.Effects.Prone.cs
World.Parts.Effects.Refresh.cs
World.Parts.Effects.Rusted.cs
World.Parts.Effects.Shaken.cs
World.Parts.Effects.Shamed.cs
World.Parts.Effects.ShatterArmor.cs
World.Parts.Effects.ShatteredArmor.cs
World.Parts.Effects.StairHighlight.cs
World.Parts.Effects.Stun.cs
World.Parts.Effects.StunGasStun.cs
World.Parts.Effects.Wet.cs
31 File(s) 110,793 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Effects\Diseases
World.Parts.Effects.Glotrot.cs World.Parts.Effects.Ironshank.cs
2 File(s) 20,959 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Encounters
World.Parts.CaverCorpseLoot.cs World.Parts.SkrefCorpseLoot.cs
2 File(s) 6,709 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Environment
World.Parts.Fireflies.cs
1 File(s) 1,587 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Gasses
World.Parts.Gas.cs World.Parts.GasAcid.cs
World.Parts.GasBlind.cs World.Parts.GasCryo.cs
World.Parts.GasPoison.cs World.Parts.GasSleep.cs
World.Parts.GasSteam.cs World.Parts.GasStink.cs
World.Parts.GasStun.cs
9 File(s) 25,624 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Gasses\Items
World.Parts.GasMask.cs
1 File(s) 2,094 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Grenades
World.Parts.EMPGrenade.cs World.Parts.FlashbangGrenade.cs
World.Parts.GasGrenade.cs World.Parts.HEGrenade.cs
World.Parts.StasisGrenade.cs World.Parts.ThermalGrenade.cs
6 File(s) 15,680 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Item Properties
World.Parts.AjiConch.cs World.Parts.Backpack.cs
World.Parts.BioScanner.cs World.Parts.ButcheryTool.cs
World.Parts.ConfuseOnEat.cs World.Parts.CyclopeanPrism.cs
World.Parts.DecoyHologramEmitter.cs World.Parts.DestroyOnUnequip.cs
World.Parts.Drill.cs World.Parts.ForceEmitter.cs
World.Parts.Garbage.cs World.Parts.Gaslight.cs
World.Parts.GrandfatherHorn.cs World.Parts.GreaseBoots.cs
World.Parts.HealOnEat.cs World.Parts.HelpingHands.cs
World.Parts.Inspector.cs World.Parts.Insulating.cs
World.Parts.Metal.cs World.Parts.MoveCostMultiplier.cs
World.Parts.NavigationBonus.cs World.Parts.NightVisionGoggles.cs
World.Parts.PortableWall.cs World.Parts.RecyclingSuitFiller.cs
World.Parts.RefreshCooldownsOnEat.cs World.Parts.Shading.cs
World.Parts.SometimesBloody.cs World.Parts.Spectacles.cs
World.Parts.SpringBoots.cs World.Parts.Stable.cs
World.Parts.Teleporter.cs World.Parts.TeleportOnEat.cs
World.Parts.Teleprojector.cs World.Parts.TemperatureOnEat.cs
World.Parts.TimeCube.cs World.Parts.TorchProperties.cs
World.Parts.UlnarStimulators.cs World.Parts.Wire.cs
World.Parts.Yuckwheat.cs World.Parts.Yurtmat.cs
40 File(s) 127,343 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Item Properties\Storied Items
World.Parts.MechanicalWings.cs World.Parts.RuinOfHouseIsner.cs
World.Parts.SkybearShroud.cs World.Parts.Stopsvaalinn.cs
4 File(s) 32,919 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Liquids
World.Effects.LiquidCovered.cs World.Liquids.Acid.cs
World.Liquids.Blood.cs World.Liquids.Cider.cs
World.Liquids.Cloning.cs World.Liquids.Convalessence.cs
World.Liquids.Gel.cs World.Liquids.Goo.cs
World.Liquids.Honey.cs World.Liquids.Lava.cs
World.Liquids.NeutronFlux.cs World.Liquids.Oil.cs
World.Liquids.Ooze.cs World.Liquids.Putrescence.cs
World.Liquids.Salt.cs World.Liquids.Slime.cs
World.Liquids.Sludge.cs World.Liquids.Tar.cs
World.Liquids.Water.cs World.Liquids.Wine.cs
World.Parts.LiquidVolume.cs
21 File(s) 160,852 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Materials
World.Parts.AnimatedMaterialElectric.cs
World.Parts.AnimatedMaterialFire.cs
World.Parts.AnimatedMaterialForcefield.cs
World.Parts.AnimatedMaterialLuminous.cs
World.Parts.AnimatedMaterialSaltDunes.cs
World.Parts.AnimatedMaterialStasisfield.cs
World.Parts.AnimatedMaterialWater.cs
7 File(s) 31,425 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Medications
World.Parts.BandageMedication.cs World.Parts.HealMedication.cs
World.Parts.Medication.cs World.Parts.RegenMedication.cs
World.Parts.StatBoostMedication.cs
5 File(s) 9,346 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Medications\Tonics
World.Parts.Effects.BlazeTonic.cs
World.Parts.Effects.EmptyTonic.cs
World.Parts.Effects.HoarshroomTonic.cs
World.Parts.Effects.HulkHoneyTonic.cs
World.Parts.Effects.NectarTonic.cs
World.Parts.Effects.RubbergumTonic.cs
World.Parts.Effects.SalveTonic.cs
World.Parts.Effects.ShadeOilTonic.cs
World.Parts.Effects.SkulkTonic.cs
World.Parts.Effects.SphynxSaltTonic.cs
World.Parts.Effects.UbernostrumTonic.cs
World.Parts.Tonic.cs
12 File(s) 71,416 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Melee Weapon Parts
World.Parts.BleedingOnHit.cs World.Parts.DischargeOnHit.cs
World.Parts.StunOnHit.cs World.Parts.TemperatureOnHit.cs
World.Parts.VibroWeapon.cs
5 File(s) 10,467 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Missile Weapon Parts
World.Parts.MissileWeapon.cs World.Parts.Projectile.cs
2 File(s) 107,443 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Missile Weapon Parts\Ammo
World.Parts.AmmoArrow.cs World.Parts.AmmoDart.cs
World.Parts.AmmoGrenade.cs World.Parts.AmmoMissile.cs
World.Parts.AmmoSlug.cs World.Parts.BlastOnHit.cs
World.Parts.ExplodeOnHit.cs
7 File(s) 12,518 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Missile Weapon Parts\Ammo Loaders
World.Parts.EnergyAmmoLoader.cs World.Parts.InventoryAmmoLoader.cs
World.Parts.LiquidAmmoLoader.cs World.Parts.MagazineAmmoLoader.cs
4 File(s) 20,788 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Modifications
World.Parts.ModCounterweighted.cs World.Parts.ModDrumLoaded.cs
World.Parts.ModElectrified.cs World.Parts.ModFeatherweight.cs
World.Parts.ModFlaming.cs World.Parts.ModFlexiweaved.cs
World.Parts.ModFreezing.cs World.Parts.ModLacquered.cs
World.Parts.ModLanterned.cs World.Parts.ModLight.cs
World.Parts.ModReinforced.cs World.Parts.ModScoped.cs
World.Parts.ModSharp.cs World.Parts.ModSixFingered.cs
World.Parts.ModSturdy.cs World.Parts.ModVisored.cs
16 File(s) 34,374 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations
World.Parts.Mutation.BaseMutation.cs World.Parts.Mutations.cs
World.Parts.RandomMutations.cs World.Parts.UnstableGenome.cs
4 File(s) 17,334 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Defect
World.Parts.Mutation.Albino.cs
World.Parts.Mutation.Amnesia.cs
World.Parts.Mutation.Amphibious.cs
World.Parts.Mutation.Analgesia.cs
World.Parts.Mutation.Beak.cs
World.Parts.Mutation.BlinkingTic.cs
World.Parts.Mutation.BrittleBones.cs
World.Parts.Mutation.ColdBlooded.cs
World.Parts.Mutation.ElectromagneticImpulse.cs
World.Parts.Mutation.EvilTwin.cs
World.Parts.Mutation.Hemophilia.cs
World.Parts.Mutation.HooksForFeet.cs
World.Parts.Mutation.Myopia.cs
World.Parts.Mutation.Narcolepsy.cs
World.Parts.Mutation.PackRat.cs
World.Parts.Mutation.Ravenous..cs
World.Parts.Mutation.Skittish.cs
World.Parts.Mutation.SociallyRepugnant.cs
World.Parts.Mutation.SpontaneousCombustion.cs
World.Parts.Mutation.UnwelcomeGermination.cs
20 File(s) 51,118 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Mental
World.Parts.Mutation.Beguiling.cs
World.Parts.Mutation.BiologicalGenius.cs
World.Parts.Mutation.Burgeoning.cs
World.Parts.Mutation.Clairvoyance.cs
World.Parts.Mutation.Confusion.cs
World.Parts.Mutation.DensityDisruption.cs
World.Parts.Mutation.Devolution.cs
World.Parts.Mutation.DirectionSense.cs
World.Parts.Mutation.Disintegration.cs
World.Parts.Mutation.Domination.cs
World.Parts.Mutation.EconomicGenius.cs
World.Parts.Mutation.Empathy.cs
World.Parts.Mutation.EnergyAssimilation.cs
World.Parts.Mutation.EnergyDissipation.cs
World.Parts.Mutation.Farport.cs
World.Parts.Mutation.Fear.cs
World.Parts.Mutation.ForceBubble.cs
World.Parts.Mutation.ForceFieldGeneration.cs
World.Parts.Mutation.ForceWall.cs
World.Parts.Mutation.GammaGaze.cs
World.Parts.Mutation.HeightenedEgo.cs
World.Parts.Mutation.HeightenedIntelligence.cs
World.Parts.Mutation.HeightenedWillpower.cs
World.Parts.Mutation.Illusion.cs
World.Parts.Mutation.Intuition.cs
World.Parts.Mutation.Kindle.cs
World.Parts.Mutation.Levitation.cs
World.Parts.Mutation.LifeLeech.cs
World.Parts.Mutation.LightManipulation.cs
World.Parts.Mutation.MagneticManipulation.cs
World.Parts.Mutation.MassMind.cs
World.Parts.Mutation.MechanicalGenius.cs
World.Parts.Mutation.MentalBlast.cs
World.Parts.Mutation.MentalHealing.cs
World.Parts.Mutation.MentalInvisibility.cs
World.Parts.Mutation.MentalMirror.cs
World.Parts.Mutation.MentalShield.cs
World.Parts.Mutation.MilitaryGenius.cs
World.Parts.Mutation.MolecularDisruption.cs
World.Parts.Mutation.MolecularSense.cs
World.Parts.Mutation.OldCryokinesis.cs
World.Parts.Mutation.OldPyrokinesis.cs
World.Parts.Mutation.Paralyze.cs
World.Parts.Mutation.PlantControl.cs
World.Parts.Mutation.Precognition.cs
World.Parts.Mutation.Psychometry.cs
World.Parts.Mutation.RepellingField.cs
World.Parts.Mutation.RepellingForce.cs
World.Parts.Mutation.Serenity.cs
World.Parts.Mutation.StunningForce.cs
World.Parts.Mutation.Summoning.cs
World.Parts.Mutation.Telekinesis.cs
World.Parts.Mutation.TelekineticFlight.cs
World.Parts.Mutation.Telepathy.cs
World.Parts.Mutation.Teleportation.cs
World.Parts.Mutation.TeleportObject.cs
World.Parts.Mutation.TeleportOther.cs
World.Parts.Mutation.TemporalFugue.cs
World.Parts.Mutation.TemporalHealing.cs
World.Parts.Mutation.ThoughtImitation.cs
World.Parts.Mutation.TimeDilation.cs
World.Parts.Mutation.WeatherManipulation.cs
World.Parts.Mutation.WillForce.cs
63 File(s) 257,842 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Mental\Cryokinesis
World.Parts.CryoZone.cs World.Parts.Mutation.Cryokinesis.cs
2 File(s) 11,343 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Mental\Pyrokinesis
World.Parts.Mutation.Pyrokinesis.cs World.Parts.PyroZone.cs
2 File(s) 11,462 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Mental\SensePsychic
World.Parts.Effects.SensePsychicEffect.cs
World.Parts.Mutation.SensePsychic.cs
2 File(s) 7,728 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Mental\Space-Time Vortex
World.Parts.Mutation.SpaceTimeVortex.cs
World.Parts.SpaceTimeVortex.cs
2 File(s) 16,155 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Monster
World.Parts.Mutation.FearAura.cs World.Parts.Mutation.SpiderWebs.cs
2 File(s) 8,931 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Physical
World.Parts.Horns.cs
World.Parts.Mutation.AcidSlimeGlands.cs
World.Parts.Mutation.AdrenalControl.cs
World.Parts.Mutation.BurrowingClaws.cs
World.Parts.Mutation.Carapace.cs
World.Parts.Mutation.ChameleonSkin.cs
World.Parts.Mutation.ColdAbsorption.cs
World.Parts.Mutation.CombatReflexes.cs
World.Parts.Mutation.DarkVision.cs
World.Parts.Mutation.DensityControl.cs
World.Parts.Mutation.Displacement.cs
World.Parts.Mutation.DualBrain.cs
World.Parts.Mutation.ElectromagneticPulse.cs
World.Parts.Mutation.EnergyAbsorption.cs
World.Parts.Mutation.EnergyGeneration.cs
World.Parts.Mutation.EnergyMetamorphosis.cs
World.Parts.Mutation.EnergyReflection.cs
World.Parts.Mutation.EnhancedSkeleton.cs
World.Parts.Mutation.FattyHump.cs
World.Parts.Mutation.FlamingHands.cs
World.Parts.Mutation.FreezeBreath.cs
World.Parts.Mutation.FreezingHands.cs
World.Parts.Mutation.FrostWebs.cs
World.Parts.Mutation.GasGeneration.cs
World.Parts.Mutation.Gills.cs
World.Parts.Mutation.HeatAbsorption.cs
World.Parts.Mutation.HeightenedAgility.cs
World.Parts.Mutation.HeightenedPrecision.cs
World.Parts.Mutation.HeightenedSight.cs
World.Parts.Mutation.HeightenedSmell.cs
World.Parts.Mutation.HeightenedSpeed.cs
World.Parts.Mutation.HeightenedStrength.cs
World.Parts.Mutation.HeightenedTaste.cs
World.Parts.Mutation.HeightenedTouch.cs
World.Parts.Mutation.HeightenedToughness.cs
World.Parts.Mutation.Horns.cs
World.Parts.Mutation.Immunity.cs
World.Parts.Mutation.Infravision.cs
World.Parts.Mutation.Invisibility.cs
World.Parts.Mutation.KineticDampening.cs
World.Parts.Mutation.Mane.cs
World.Parts.Mutation.Metamorphosis.cs
World.Parts.Mutation.MultiHorns.cs
World.Parts.Mutation.MultipleArms.cs
World.Parts.Mutation.MultipleEyes.cs
World.Parts.Mutation.MultipleLegs.cs
World.Parts.Mutation.Oil.cs
World.Parts.Mutation.OldGasGeneration.cs
World.Parts.Mutation.Phasing.cs
World.Parts.Mutation.PhotosyntheticSkin.cs
World.Parts.Mutation.PoisonGeneration.cs
World.Parts.Mutation.Quills.cs
World.Parts.Mutation.Regeneration.cs
World.Parts.Mutation.Shapeshift.cs
World.Parts.Mutation.Shorter.cs
World.Parts.Mutation.SlimeGlands.cs
World.Parts.Mutation.SlogGlands.cs
World.Parts.Mutation.Sonar.cs
World.Parts.Mutation.SoundImitation.cs
World.Parts.Mutation.Spinnerets.cs
World.Parts.Mutation.Stinger.cs
World.Parts.Mutation.Taller.cs
World.Parts.Mutation.ThickFur.cs
World.Parts.Mutation.TwoHeaded.cs
World.Parts.Mutation.Ultravision.cs
World.Parts.Mutation.Wings.cs
66 File(s) 281,048 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Physical\Aura
World.Parts.Mutation.Aura.cs
1 File(s) 707 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Physical\Electrical Generation
World.Parts.Effects.SynapseSnap.cs
World.Parts.Mutation.ElectricalGeneration.cs
World.Parts.Mutation.OldElectricalGeneration.cs
3 File(s) 25,242 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Physical\HeightenedHearing
World.Parts.Effects.HeightenedHearingEffect.cs
World.Parts.Mutation.HeightenedHearing.cs
2 File(s) 7,494 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Mutations\Plant
World.Parts.Mutation.Adaptation.cs
World.Parts.Mutation.Allurement.cs
World.Parts.Mutation.BacterialSymbiosis.cs
World.Parts.Mutation.Berries.cs
World.Parts.Mutation.DissolvingJuices.cs
World.Parts.Mutation.ExplosiveFruit.cs
World.Parts.Mutation.LivingSegments.cs
World.Parts.Mutation.PoisionSap.cs
8 File(s) 5,669 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Qualities
World.Parts.Inorganic.cs World.Parts.NoDamage.cs
World.Parts.NoEffects.cs World.Parts.NoMove.cs
World.Parts.PlantProperties.cs World.Parts.Robot.cs
World.Parts.Temporary.cs
7 File(s) 13,093 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Scripting Game Events
World.Parts.MoveOtho.cs World.Parts.ScriptCallToArms.cs
2 File(s) 7,418 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers
World.Parts.Skill.AnimalTraining.cs World.Parts.Skill.BaseSkill.cs
World.Parts.SkillFactory.cs World.Parts.Skills.cs
4 File(s) 9,690 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Acrobatics
World.Parts.Skill.Acrobatics.cs
World.Parts.Skill.Acrobatics_Dodge.cs
World.Parts.Skill.Acrobatics_Jump.cs
World.Parts.Skill.Acrobatics_Tumble.cs
4 File(s) 8,323 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Armor
World.Parts.Skill.Armor.cs
1 File(s) 755 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Axe
World.Parts.Skill.Axe.cs World.Parts.Skill.Axe_Bezerk.cs
World.Parts.Skill.Axe_Cleave.cs World.Parts.Skill.Axe_Decapitate.cs
World.Parts.Skill.Axe_Dismember.cs World.Parts.Skill.Axe_Expertise.cs
World.Parts.Skill.Axe_Hew.cs World.Parts.Skill.Axe_HookAndDrag.cs
World.Parts.Skill.Axe_Trip.cs World.Parts.Skill.Axe_Whack.cs
10 File(s) 38,605 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Butchery
World.Parts.Butcher.cs World.Parts.Skill.Butchery.cs
2 File(s) 10,582 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Cudgel
World.Parts.Skill.Cudgel.cs
World.Parts.Skill.Cudgel_Bludgeon.cs
World.Parts.Skill.Cudgel_ChargingStrike.cs
World.Parts.Skill.Cudgel_Clobber.cs
World.Parts.Skill.Cudgel_CripplingBlows.cs
World.Parts.Skill.Cudgel_Expertise.cs
World.Parts.Skill.Cudgel_Flurry.cs
World.Parts.Skill.Cudgel_ShatteringBlows.cs
World.Parts.Skill.Cudgel_Slam.cs
World.Parts.Skill.Cudgel_ToTheFences.cs
World.Parts.Skill.Cudgel_UnstoppableBlows.cs
World.Parts.Skills.Cudgel_Bonecrusher.cs
World.Parts.Skills.Cudgel_Hammer.cs
13 File(s) 33,576 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Dual_Wield
World.Parts.Skill.Dual_Wield.cs
World.Parts.Skill.Dual_Wield_Ambidexterity.cs
World.Parts.Skill.Dual_Wield_Offhand_Strikes.cs
World.Parts.Skill.Dual_Wield_Two_Weapon_Fighting.cs
4 File(s) 2,071 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Endurance
World.Parts.Skill.Endurance.cs
World.Parts.Skill.Endurance_Calloused.cs
World.Parts.Skill.Endurance_Juicer.cs
World.Parts.Skill.Endurance_Longstrider.cs
World.Parts.Skill.Endurance_MoreHPI-V.cs
World.Parts.Skill.Endurance_PoisonTolerance.cs
World.Parts.Skill.Endurance_ShakeItOff.cs
World.Parts.Skill.Endurance_Swimming.cs
World.Parts.Skill.Endurance_Weathered.cs
9 File(s) 12,761 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\First Aid
World.Parts.Skill.Firstaid.cs
World.Parts.Skill.Firstaid_Heal.cs
World.Parts.Skill.Firstaid_SetLimb.cs
World.Parts.Skill.Firstaid_StaunchWounds.cs
4 File(s) 13,232 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Heavy Weapons
World.Parts.Skill.HeavyWeapons.cs
World.Parts.Skill.HeavyWeapons_StrappingShoulders.cs
World.Parts.Skill.HeavyWeapons_Sweep.cs
World.Parts.Skill.HeavyWeapons_Tank.cs
4 File(s) 5,852 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Long Blades
World.Parts.Skill.LongBlades.cs
World.Parts.Skill.LongBlades_BladeFlurry.cs
World.Parts.Skill.LongBlades_CripplingInterception.cs
World.Parts.Skill.LongBlades_DisarmingRipostes.cs
World.Parts.Skill.LongBlades_Expertise.cs
World.Parts.Skill.LongBlades_GoringLunges.cs
World.Parts.Skill.LongBlades_Intercept.cs
World.Parts.Skill.LongBlades_Lunge.cs
World.Parts.Skill.LongBlades_MightySwipes.cs
World.Parts.Skill.LongBlades_ParryAndRiposte.cs
World.Parts.Skill.LongBlades_PorcupineMastery.cs
World.Parts.Skill.LongBlades_ScorpiokMastery.cs
World.Parts.Skill.LongBlades_Swallow.cs
World.Parts.Skill.LongBlades_SweepingSlash.cs
World.Parts.Skill.LongBlades_Swipe.cs
World.Parts.Skill.LongBlades_WillowMastery.cs
World.Parts.Skill.LongBlades_WindmillMastery.cs
17 File(s) 64,910 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Mind over Matter
World.Parts.Skill.MindOverMatter.cs
World.Parts.Skill.MindOverMatter_ExpertiseOfTheDomain.cs
World.Parts.Skill.MindOverMatter_MasteryOfTheDomain.cs
World.Parts.Skill.MindOverMatter_PsychicGrit.cs
World.Parts.Skill.MindOverMatter_PsychicStamina.cs
World.Parts.Skill.MindOverMatter_Sync.cs
World.Parts.Skill.MindOverMatter_Trance.cs
7 File(s) 11,349 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Persuasian
World.Parts.Skill.Persuasian.cs
World.Parts.Skill.Persuasian_InspiringPresence.cs
World.Parts.Skill.Persuasian_Intimidate.cs
World.Parts.Skill.Persuasian_SnakeOiler.cs
World.Parts.Skill.Persuasion_Berate.cs
World.Parts.Skill.Persuasion_Proselytize.cs
World.Parts.Skill.Persuasion_RebukeRobot.cs
7 File(s) 32,450 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Pistol
World.Parts.Skill.Pistol.cs
World.Parts.Skill.Pistol_Akimbo.cs
World.Parts.Skill.Pistol_Bullseye.cs
World.Parts.Skill.Pistol_DeadShot.cs
World.Parts.Skill.Pistol_DisarmingShot.cs
World.Parts.Skill.Pistol_EmptyTheClips.cs
World.Parts.Skill.Pistol_Expertise.cs
World.Parts.Skill.Pistol_Fastdraw.cs
World.Parts.Skill.Pistol_FastestGun.cs
World.Parts.Skill.Pistol_Hipshot.cs
World.Parts.Skill.Pistol_MenacingStare.cs
World.Parts.Skill.Pistol_SlingAndRun.cs
World.Parts.Skill.Pistol_SteadyHands.cs
World.Parts.Skill.Pistol_WeakSpotter.cs
14 File(s) 21,834 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Plant Harvesting
World.Parts.Harvest.cs
World.Parts.Skill.Survival_EfficentHarvesting.cs
World.Parts.Skill.Survival_MasterHarvester.cs
World.Parts.Skill.Survival_PlantHarvesting.cs
4 File(s) 9,385 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Rifles
World.Parts.Skill.Rifles.cs
World.Parts.Skill.Rifle_Aim.cs
World.Parts.Skill.Rifle_CripplingShot.cs
World.Parts.Skill.Rifle_DrawABead.cs
World.Parts.Skill.Rifle_Kickback.cs
World.Parts.Skill.Rifle_KillingGun.cs
World.Parts.Skill.Rifle_LamingGun.cs
World.Parts.Skill.Rifle_PressureShooter.cs
World.Parts.Skill.Rifle_RapidFire.cs
World.Parts.Skill.Rifle_Snipe.cs
World.Parts.Skill.Rifle_SteadyHands.cs
World.Parts.Skill.Rifle_SupressiveFire.cs
World.Parts.Skill.Rifle_VitalFire.cs
World.Parts.Skill.Rifle_WatchingGun.cs
World.Parts.Skill.Rifle_WoundingFire.cs
15 File(s) 53,027 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Self-discipline
World.Parts.Skill.Discipline.cs
World.Parts.Skill.Discipline_Conatus.cs
World.Parts.Skill.Discipline_FastingWay.cs
World.Parts.Skill.Discipline_IronMind.cs
World.Parts.Skill.Discipline_Lionheart.cs
World.Parts.Skill.Discipline_Meditate.cs
World.Parts.Skill.Discipline_MindOverBody.cs
7 File(s) 14,481 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Shield
World.Parts.Skill.Shield.cs
World.Parts.Skill.Shield_Block.cs
World.Parts.Skill.Shield_DeftBlocking.cs
World.Parts.Skill.Shield_ShieldWall.cs
World.Parts.Skill.Shield_Slam.cs
World.Parts.Skill.Shield_StaggeringBlock.cs
World.Parts.Skill.Shield_SwiftBlocking.cs
7 File(s) 16,470 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Short Blades
World.Parts.Skill.ShortBlades.cs
World.Parts.Skill.ShortBlades_Bloodletter.cs
World.Parts.Skill.ShortBlades_Expertise.cs
World.Parts.Skill.ShortBlades_Jab.cs
World.Parts.Skill.ShortBlades_Lacerate.cs
World.Parts.Skill.ShortBlades_PointedCircle.cs
World.Parts.Skill.ShortBlades_Puncture.cs
World.Parts.Skill.ShortBlades_RemisingStrike.cs
World.Parts.Skill.ShortBlades_Shank.cs
9 File(s) 13,636 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Survival
World.Parts.Skill.Survival.cs World.Parts.Skill.SurvivalTerrains.cs
2 File(s) 6,354 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Tactics
World.Parts.Skill.Melee.cs World.Parts.Skill.Melee_Charge.cs
World.Parts.Skill.Melee_Run.cs World.Parts.Skill.Tactics_Juke.cs
4 File(s) 20,830 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Skills and Powers\Tinkering
World.Parts.HostileTurretBuilder.cs
World.Parts.Repair.cs
World.Parts.Skill.Tinkering.cs
World.Parts.Skill.Tinkering_DeployTurret.cs
World.Parts.Skill.Tinkering_Disassemble.cs
World.Parts.Skill.Tinkering_GadgetInspector.cs
World.Parts.Skill.Tinkering_LayMine.cs
World.Parts.Skill.Tinkering_Repair.cs
World.Parts.Skill.Tinkering_ReverseEngineer.cs
World.Parts.Skill.Tinkering_Scavenger.cs
World.Parts.Skill.Tinkering_Tinker1.cs
World.Parts.Skill.Tinkering_Tinker2.cs
World.Parts.Skill.Tinkering_Tinker3.cs
World.Parts.Skill.Tinkering_Upgrade1.cs
World.Parts.Skill.Tinkering_Upgrade2.cs
World.Parts.Skill.Tinkering_Upgrade3.cs
World.Parts.TinkerItem.cs
World.Parts.Toolbox.cs
18 File(s) 69,045 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Talents
World.Parts.Talent.Ambidexterous.cs World.Parts.Talent.BaseTalent.cs
World.Parts.Talents.cs World.Parts.Talents.TalentList.cs
4 File(s) 5,000 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Terrain and Objects
World.Parts.BlockSpawns.cs World.Parts.Dirty.cs
World.Parts.EelSpawn.cs World.Parts.RandomDirt.cs
World.Parts.RandomFlower.cs World.Parts.RandomJungle.cs
World.Parts.RandomWeald.cs
7 File(s) 26,520 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Terrain and Objects\Switches
World.Parts.DoorSwitch.cs World.Parts.ElevatorSwitch.cs
World.Parts.EnableSwitch.cs World.Parts.Switch.cs
4 File(s) 9,531 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Terrain and Objects\Wall Traps
World.Parts.CryochamberWall.cs World.Parts.Walltrap.cs
World.Parts.WalltrapAcid.cs World.Parts.WalltrapCrabs.cs
World.Parts.WalltrapFire.cs World.Parts.WalltrapShock.cs
6 File(s) 17,231 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Parts\Widgets
World.Parts.BethesdaColdZone.cs World.Parts.Bloodsplatter.cs
World.Parts.Firestarter.cs World.Parts.WalkStopper.cs
4 File(s) 4,622 bytes
Directory of X:\Documents\Programming\C#\XRL\XRL Application\World\Game Objects\Quest Managers
World.QuestManagers.Argive.cs World.QuestManagers.GritGate.cs
World.QuestManagers.Kyakukya.cs World.QuestManagers.Thull.cs
4 File(s) 20,252 bytes
Total Files Listed:
690 File(s) 3,083,510 bytes
0 Dir(s) 244,678,033,408 bytes free
|
|
#
?
Aug 3, 2012 07:08
|
|
- Hidden Asbestos
- Nov 24, 2003
-
[placeholder]
|
I think this is the best thread for this.
I made a utility yesterday for bug tracking my game projects. As I'm a lone developer with a previous games industry job I've had a bit of experience with QA software (PR Tracker, Test Track Pro, Trac, Bugzilla, Mantis). Now I'm working for myself I've not found that any of those systems suit my needs.
So I developed a little program in C# called 'dBug - Personal Bug Tracker'. I've made available for free and hopefully I'll get some nice feedback and suggestions.
The key features of my program vs. things like BugZilla (my most recent disappointment) are:
* NO USER MANAGEMENT. All bugs are entered by one developer (from external sources such as forums, e-mail or from self testing) and fixed by the same developer. dBug is built with no concept of departments/staff to assign bugs to - you're it!
* NO ADMINISTRATION. All report fields are dynamic editable plain text, there is no separate administrative screen to add new version numbers or platforms and components - simple make one up and type it in. You are left to organise reports as you see fit - dBug won't try to get in the way of your own workflow.
* LOCAL STORAGE, EXE BASED. dBug was developed in C# (.NET 2.0) and uses a single XML file (dBug.xml) to hold all reports.
* SIMPLE. dBug is a simple report manager. It has no particularly advanced features like complex filtering, time stamped history or file attachments. Also reports have no concept of 'priority' or other such external/management control.
So there you have it.
You can get a copy (with a manual and everything) here: http://www.davidwaltersdevelopment.com/labs/#dbug
Hope it works!
|
|
#
?
Aug 3, 2012 12:28
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
I think this is the best thread for this.
I made a utility yesterday for bug tracking my game projects. As I'm a lone developer with a previous games industry job I've had a bit of experience with QA software (PR Tracker, Test Track Pro, Trac, Bugzilla, Mantis). Now I'm working for myself I've not found that any of those systems suit my needs.
So I developed a little program in C# called 'dBug - Personal Bug Tracker'. I've made available for free and hopefully I'll get some nice feedback and suggestions.
The key features of my program vs. things like BugZilla (my most recent disappointment) are:
* NO USER MANAGEMENT. All bugs are entered by one developer (from external sources such as forums, e-mail or from self testing) and fixed by the same developer. dBug is built with no concept of departments/staff to assign bugs to - you're it!
* NO ADMINISTRATION. All report fields are dynamic editable plain text, there is no separate administrative screen to add new version numbers or platforms and components - simple make one up and type it in. You are left to organise reports as you see fit - dBug won't try to get in the way of your own workflow.
* LOCAL STORAGE, EXE BASED. dBug was developed in C# (.NET 2.0) and uses a single XML file (dBug.xml) to hold all reports.
* SIMPLE. dBug is a simple report manager. It has no particularly advanced features like complex filtering, time stamped history or file attachments. Also reports have no concept of 'priority' or other such external/management control.
So there you have it.
You can get a copy (with a manual and everything) here: http://www.davidwaltersdevelopment.com/labs/#dbug
Hope it works!
That's pretty cool, I wish you could double click on the white space on a line (not just text) to open an entry though 
|
|
#
?
Aug 3, 2012 15:12
|
|
- Pfhreak
- Jan 30, 2004
-
Frog Blast The Vent Core!
|
To address the point about Adjust Sword and Adjust Shield damage, no it'd be silly to have just those two on separate components.
My specific requirements for a pretty generic engine are to support situations like:
A web-spinning smart spider with wings, the ability to phase through solid objects and a mental force shield's body is taken over by the player via mind control (becoming the active player object [any object in the game is required to be fully controllable] the player can play the creature in full, as he could any creature or item in the game) who then picks up and equips a force bracelet that allows a similar but not identical kind of force field, takes an drug that turns his body (the spider) to rubber, and is then pushed down a 40 foot hole, landing on a pile of worms, survives because his body is made of rubber, but killing one of the worms with the impact which causes him (the spider) to gain enough experience to level up the spider allowing him to grow a set of quills, but causing enough damage to send the player back to his idle body.
...also tomorrow you are going to have to add a room full of chambers filled with cryogenic gas with breakable glass, including a plant that grows in a fractal pattern (unique to the game), and ancient unique bear-monster that wields a vibro blade and wears a jetpack capable of (unlike anything else in the entire game so far) jetting him around the room 30 squares at a time granting a huge bonus to penetration if hit hits anything in that time.
Next day, you have to add something else novel like that, you don't know what it's going to be.
Actual, non made up example. In my opinion, a pretty good case for a pretty generic and flexible component-driven system.
Not the common case in general, though.
I'm curious how you manage the priority of the various components. If a critter receives a Damage(500, "fire") message, and it has an Shield component, a Health component, and let's say a DamageSpawnsClones component or something else that responds to taking fire damage, but only if it affects the critter's health.
Is that just the critter class's job to manage where the message gets passed? How much of this is data driven vs hardcoded?
|
|
#
?
Aug 3, 2012 21:54
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
I'm curious how you manage the priority of the various components. If a critter receives a Damage(500, "fire") message, and it has an Shield component, a Health component, and let's say a DamageSpawnsClones component or something else that responds to taking fire damage, but only if it affects the critter's health.
Is that just the critter class's job to manage where the message gets passed? How much of this is data driven vs hardcoded?
In Caves of Qud I actually don't manage priority on components (though I do in later component engines for generic messages). For messages where I needed defined order I ended up with a message sequence like
BeforeX
X
AfterX
So actual damage seqences ended up like:
BeforeTakeDamage <- Most objects don't have registered handlers for this message
TakeDamageX <- The base physics component handles this one
AfterTakeDamage <- Most objects don't have registered handlers for this message
Not super efficient, but worked for my purposes. In later engines I just keep a priority-ordered list, assigning a numeric priority to a component. I've never really used those engines on a large scale though.
When a component is added to an object, it registers itself for any messages it will handle (which is just a hash-table with a list of recipients), when it's removed, the component is responsible for un-registering itself.
So I would create CritterClones, during it's registration call it would register itself, which looks sometihng like:
CritterClones::Register( GameObject Parent )
{
Parent.RegisterPartEvent( "AfterTakeDamage", this );
}
and then critter clones would just handle take damage:
After Take Damage Handler
{
// Do stuff here
}
All of the object definitions are entirely data driven, so, as a random example, I was able to create a Dune still-suit by just adding a liquid-volume component to a normal piece of armor, and creating a unique component that would fill it's parent's liquid volume component over time:
code: <object Name="Recycling Suit" Inherits="BaseArmor">
<part Name="Armor" AV="3" DV="0" RF="0" WornOn="Body"></part>
<part Name="Render" DisplayName="&Brecycling suit" ColorString="&B" RenderString="]"></part>
<part Name="Commerce" Value="95"></part>
<part Name="Examiner" Complexity="4"></part>
<part Name="LiquidVolume" MaxVolume="8" Volume="8" InitialLiquid="water-1000"></part>
<part Name="RecyclingSuitFiller"></part>
<part Name="Description" Short="This suit is made of extremely durable, rubbery, dark material. It is lined with small pouches which slowly collect and filter water that the suit collects from your sweaty, overworked body."></part>
<part Name="Physics" Weight="35"></part>
<part Name="TinkerItem" Bits="0034" CanDisassemble="true" CanBuild="true" CanRepair="true"></part>
<tag Name="Tier" Value="4"></tag>
</object>
Unormal fucked around with this message at 22:39 on Aug 3, 2012
|
|
#
?
Aug 3, 2012 22:31
|
|
- mmm11105
- Apr 27, 2010
-
|
Question for anyone who does 2d stuff in unity. How do you guys hadle varying screen size/densities (specifically on mobile)? Working on a mobile app, but especially on android screen densities vary so much, that my tiles could be twice the size they are on other devices. Do you guys just set a fixed view port and scale it up or down? How does that affect the sprites look (as they wouldn't be pixel perfect)?
|
|
#
?
Aug 3, 2012 23:28
|
|
- Azazel
- Jun 6, 2001
-
I bitch slap for a living - you want some?
|
Question for anyone who does 2d stuff in unity. How do you guys hadle varying screen size/densities (specifically on mobile)? Working on a mobile app, but especially on android screen densities vary so much, that my tiles could be twice the size they are on other devices. Do you guys just set a fixed view port and scale it up or down? How does that affect the sprites look (as they wouldn't be pixel perfect)?
The following is a breakdown of how I handled it in a game I just released. Feel free to use the code and save yourself some time. It works on all iOS devices correctly, and as far as I can tell all the Android phones my testers had used.
I created this to check the aspect ratios of a phone:
code:using UnityEngine;
using System.Collections;
public class GameConfig : MonoBehaviour {
// offset for different aspect ratios of phones
public static int nonFourThreeOffset = 15;
public static int sixteenNineOffset = 35;
public static bool isFourThreeAspect() {
int factor = gcd(Screen.width, Screen.height);
int wFactor = Screen.width / factor;
int hFactor = Screen.height / factor;
if (wFactor == 3 && hFactor == 4) {
return true;
} else {
return false;
}
}
public static bool isSixteenNineAspect() {
int factor = gcd(Screen.width, Screen.height);
int wFactor = Screen.width / factor;
int hFactor = Screen.height / factor;
if (wFactor == 9 && hFactor == 16) {
return true;
} else {
return false;
}
}
public static int gcd(int a, int b) {
return (b == 0) ? a : gcd (b, a % b);
}
}
code:using UnityEngine;
using System.Collections;
public class CameraOffset : MonoBehaviour {
public bool up = false;
void Start() {
Vector3 position = transform.position;
if (!GameConfig.isFourThreeAspect() && !GameConfig.isSixteenNineAspect()) {
if (up) {
position.y += GameConfig.nonFourThreeOffset;
} else {
position.y -= GameConfig.nonFourThreeOffset;
}
} else if (GameConfig.isSixteenNineAspect()) {
if (up) {
position.y += GameConfig.sixteenNineOffset;
} else {
position.y -= GameConfig.sixteenNineOffset;
}
}
transform.position = position;
}
}
code: if (!GameConfig.isFourThreeAspect() && !GameConfig.isSixteenNineAspect()) {
Camera.main.orthographicSize += GameConfig.nonFourThreeOffset;
GameObject.FindGameObjectWithTag("GUI Camera").GetComponent<Camera>().orthographicSize += GameConfig.nonFourThreeOffset;
} else if (GameConfig.isSixteenNineAspect()) {
Camera.main.orthographicSize += GameConfig.sixteenNineOffset;
GameObject.FindGameObjectWithTag("GUI Camera").GetComponent<Camera>().orthographicSize += GameConfig.sixteenNineOffset;
}
Azazel fucked around with this message at 01:40 on Aug 5, 2012
|
|
#
?
Aug 4, 2012 01:54
|
|
- TastyShrimpPlatter
- Dec 18, 2006
-
It's me, I'm the
|
In Unity, is it possible to deform a TextMesh along a curve or line? I'm trying to emulate the curve of a CRT monitor, but I don't have Unity Pro, so I can't use a Render Texture to just project it onto a curved surface. Are there camera settings or shaders I should look into?
|
|
#
?
Aug 5, 2012 01:21
|
|
- Pfhreak
- Jan 30, 2004
-
Frog Blast The Vent Core!
|
Now that the one month game dev competition is over, I'm rethinking my renderer for my AlephOne port to webGL. Currently, it renders the level in a very level specific way. I couldn't use the same code to, say, draw monsters, bullets, or items.
The current approach is for each surface in a polygon (floor, walls, ceiling) to register with a surface manager class each frame. This manager sorts those surfaces into their material ids, and updates an index buffer for each material every frame. So 32 materials = 32 altered index buffers. Then I iterate through the materials and issue one draw call per material.
This is fine for static level geometry, and the number of draws/updates is limited, but it doesn't really serve well for things that can move around, have multiple frame animations, etc.
I'm thinking of moving to a model where every drawable thing has a RenderComponent, which is a lightweight token describing how the thing should be rendered that moment -- material ID, transformation matrix, (optional)x/y texcoords so things can use a texture atlas. Then each frame I collect the render tokens and sort them by material id. For the level, I should be able to render the whole material at once, but for enemies I think I need to issue a separate draw call for each one since they'll all have different texture offsets/translation matrices. (Though I should be able to use the same index buffer, since all enemies are just a quad.)
tl;dr: Need some advice on rendering 2.5D games. Should I issue a separate draw call for every enemy billboard? Is there a better way?
|
|
#
?
Aug 5, 2012 04:19
|
|
- Flownerous
- Apr 16, 2012
-
|
tl;dr: Need some advice on rendering 2.5D games. Should I issue a separate draw call for every enemy billboard? Is there a better way?
It's more effort but if you need the render performance you can merge together the billboards. Use one big index and vertex buffer big enough for all the billboards you want, or one per material. Each frame you iterate over all the billboards, calculate and write out their world-space vertex positions and texcoords into the vertex buffer. It's generally how particle effects are written.
|
|
#
?
Aug 5, 2012 13:01
|
|
- Paniolo
- Oct 9, 2007
-
Heads will roll.
|
It's more effort but if you need the render performance you can merge together the billboards. Use one big index and vertex buffer big enough for all the billboards you want, or one per material. Each frame you iterate over all the billboards, calculate and write out their world-space vertex positions and texcoords into the vertex buffer. It's generally how particle effects are written.
Here's where you can get a lot of milage from texture atlases. By combining different textures into a single atlas, they can all be drawn in a single call, and the overhead of managing the vertex buffer is a lot smaller.
Otherwise, you'll either need to sort sprites by material within the vertex buffer, or have a lot more draw calls than you would otherwise.
There are other considerations you might want to make though. If some of your sprites barely move while others are constantly moving, separating them out into different buffers might be worthwhile. (Or not, depending on the overhead of additional draw calls vs larger memory transfers.) Splitting the vertex buffer into multiple buffers each containing one component such as position, texcoords, etc. can also help if one aspect is updated much more frequently than others.
Honestly though most of this is premature optimization. I have a hard time imagining you're going to run into performance issues with a port of an early 90's game even if everything is brute forced.
|
|
#
?
Aug 5, 2012 15:54
|
|
- Wozbo
- Jul 5, 2010
-
|
Hey guys, I've just started reading this thread not even a week ago, and I have a few questions for anyone willing to tell me I'm an idiot. I'm a junior level software engineer, and I really want to make my own game on the side. I just cannot for the life of me seem to overcome the first steps of actually making it though Like, I'll get the teapot redering, get something like Lua running in addition, and then just go "welp". I think the biggest thing that kills me is I can't seem to put together a proper design structure in my head for even the simplest of games. I draw a frigging blank. Does anyone have any tips/ resources that I could use to actually complete SOMETHING?
E: Before anyone says "USE A PREBUILT ENGINE," I really want to make a very small game where I can understand why everything works the way it does. Comprehension of as much as possible is my goal.
|
|
#
?
Aug 5, 2012 19:49
|
|
- roomforthetuna
- Mar 22, 2005
-
I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!
|
E: Before anyone says "USE A PREBUILT ENGINE," I really want to make a very small game where I can understand why everything works the way it does. Comprehension of as much as possible is my goal.
You don't have to stick with using a prebuilt engine, but making something with one will give you some sense of the structure of game-making, which is not really the same thing as the structure of engine-making. Without first having experience with the structure of a game, you'd probably make a terrible engine.
That said, if your intent is to learn to understand that sort of thing, Flixel is probably a better bet than Unity, because trying to make your own engine that works with the Unity structure would be a huge task, whereas Flixel provides little more than bare bones. The downside of Flixel being that you'll be stuck using Actionscript as your language.
|
|
#
?
Aug 5, 2012 20:26
|
|
- a lovely poster
- Aug 5, 2011
-
by Pipski
|
Hey guys, I've just started reading this thread not even a week ago, and I have a few questions for anyone willing to tell me I'm an idiot. I'm a junior level software engineer, and I really want to make my own game on the side. I just cannot for the life of me seem to overcome the first steps of actually making it though Like, I'll get the teapot redering, get something like Lua running in addition, and then just go "welp". I think the biggest thing that kills me is I can't seem to put together a proper design structure in my head for even the simplest of games. I draw a frigging blank. Does anyone have any tips/ resources that I could use to actually complete SOMETHING?
E: Before anyone says "USE A PREBUILT ENGINE," I really want to make a very small game where I can understand why everything works the way it does. Comprehension of as much as possible is my goal.
What language are you most comfortable with? What tools are you using? If it's just an idea problem, make a tetris clone to start or something already established.
|
|
#
?
Aug 5, 2012 20:39
|
|
- Shalinor
- Jun 10, 2002
-
Can I buy you a rootbeer?
|
E: Before anyone says "USE A PREBUILT ENGINE," I really want to make a very small game where I can understand why everything works the way it does. Comprehension of as much as possible is my goal.
What you're running up against is that making something from bare metal is lengthy, and involves a lot of rabbit hole'y systems design that you tend to fall down. Then you realize you've been making a stupid mesh file loader for a week, but still can't do anything with that mesh, because now you need an XML loader/parser for arguments related to the mesh. And oh, it turns out that rendering code you threw down plain doesn't work and takes 3 years to draw anything, so better redo it. And so on.
Start with a prebuilt engine. Unity's an ok choice for high level, but if you want to learn everything, avoid it (and any other high level game engine that's tools focused and doesn't come with source). Instead, check out OGRE, and the game engine the community has built up around it. You can get something going with it double fast, then as you get curious, dive further and further down into the code.
That approach to learning system design - start high, dig down - is usually a way better idea. Then you have at least one mental pattern for almost every system you're ever to need in a game. Without that? You tend to spin your wheels, and make asinine, useless faux engines. It takes you years to learn what top-down + the engine's community will teach you in a month.
I... think? that Crystal Space is still going too, but no idea. Might be another engine worth a look..
Shalinor fucked around with this message at 21:10 on Aug 5, 2012
|
|
#
?
Aug 5, 2012 21:05
|
|
- Paniolo
- Oct 9, 2007
-
Heads will roll.
|
It's too bad there isn't something with the maturity and community support of OGRE that isn't a little better designed and with less cruft than OGRE's accumulated over the years.
The other issue I have with OGRE is that it's ostensibly a rendering engine, but it forces you into using its resource management paradigm as well, so inevitably you end up with OGRE tendrils creeping into all of your systems that really should be separable from whatever rendering middleware you're using. You can avoid this if you take extraordinary care, but good luck finding any documentation on this, since most tutorials are focused on how you can do xyz in the fewest lines of code possible.
|
|
#
?
Aug 5, 2012 21:25
|
|
- Wozbo
- Jul 5, 2010
-
|
What language are you most comfortable with? What tools are you using? If it's just an idea problem, make a tetris clone to start or something already established.
C++ is my personal forte. I have an unnatural want to learn how to make lua my script language (somewhat experienced with it).
Thanks. I'll give it a shot. My personal preference would be something I could but not necessarily would be able to replace everything if I'm going to stick with something prebuilt. Or jut use UE4 because goddamn that tech demo was sexy with on the fly recompiling.
|
|
#
?
Aug 5, 2012 21:45
|
|
- a lovely poster
- Aug 5, 2011
-
by Pipski
|
C++ is my personal forte. I have an unnatural want to learn how to make lua my script language (somewhat experienced with it).
If you really want to work with LUA, let me recommend Love2D to you. Granted, there are issues when it comes to distribution, but as far as making games it's about as simple/easy as it gets. And if I'm not mistake you can extend it with C/C++ libraries.
|
|
#
?
Aug 5, 2012 23:48
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
|
#
?
May 12, 2024 00:30
|
|
- Unormal
- Nov 16, 2004
-
Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
-
Fun Shoe
|
I mean yes, theoretically of course they are, but quite different in syntax.
I should have said "classes", really, since javascript has 'objects'; it's just that the best syntactical way available to define them is basically the closure-based 'module pattern' syntax, not class definitions.
e: Nice article, btw.
Unormal fucked around with this message at 01:38 on Aug 6, 2012
|
|
#
?
Aug 6, 2012 01:35
|
|
#
?
Aug 3, 2012 02:48
Download again and be as terse as you like!
