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]
Posts
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.
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.
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Twitch Page
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.
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Twitch Page
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?
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.
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.
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.
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Twitch Page
You might want to take a quick look at this game:Crescent Hawk's Revenge http://www.abandonia.com/en/games/977
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.
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.
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Twitch Page
But first, can anyone tell me why this would return a null reference?
I get a null reference exception when I call it here:
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.
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.
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
So I basically had to, instead of just using List<T>.Add, had to write a function to intercept additions to the list.
VALANCE
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.
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!
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
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.
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?
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.
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.
In other news, I may have just written the ugliest line of code in my game.
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.
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.
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