Tuesday 20 May 2014

Tonne Of Tweaks Tuesday

Phew, what a day of tweaks we had today!  Just lots and lots (and lots) of very little fixes that iron out those little creases that can spoil a good thing. I am sure there are twenty times more small tweaks still needed, but it's good to see a lot of 'finished items' in the old spreadsheet.  Before we get into what was fixed, here is a shot I did last night (literally):


As you can see I was very busy testing the UZI, and might have got carried away a little.  Looking forward to adding ragdoll soon so they will stop experiencing the condition Rick has termed 'instant rigamortis'.

Looking at the sheet of fixes, here is a list dump for you. Keeping my blog short today as not my what you might call spare time for non-coding stuff. Anyhoo, if you ever wanted what your life might be like when you become a coder, here is a typical day:


  • Read through forum thread recommended by Rick, and watch video emailed to me reg. A.I & Videos
  • Add in rotation and scale commands so community can control their entities
  • Fix system so the entity picker will choose the HIGHEST entity over the cursor (items on tables, e.t.c.)
  • When using INSIDE edit mode, disable AUTOFLATTEN and also ensure AUTOFLATTEN reset on new selec.
  • When in INSIDE edit mode, and raise terrain, keep the buildings where they are so can fill inside with terrain
  • Find and fix the error prompt related to the A.I
  • Integrate use of CANTAKEWEAPON flag, QUANTITY to pickup, rate of fire, view cone angle, and remove START and DESTROY and SHOOT fields as they are redundant now
  • When jump into the water with no health, you do not die and should (quite quickly)
  • Add TRANSPARENCY=2 to all FPE of the fence to resolve the semi-transparency issue
  • The skyscroll texture effect for ROLFY is wrong (alpha shown at edges compared to V1.006) - see thread
  • Waypoints seems to have broken due to the emergency stop while running code, look into it
  • When character completely facing away from player, LookAtPlayer() gun point code should switch off/reset
  • When die, reset gun point rotation
  • ai still shooting backwards or at odd angles at times when running away from me
  • Put water in middle of map and then the player over water, but get black screen and drown (no start marker)
  • Use the always active flag to ensure characters cannot be frozen at distance
  • The shader settings HIGHEST is not being remembered when you leave and come back Test Level
  • Remove the line from the sky in  the two compounds level
  • "ViewRange" referred to in the AI scripts is hard coded, move it to the entity properties panel
  • Idle and twitching anims for AI scripts
  • The last soldier near the barrels then make him stood up AI
  • Rick: Add 2 check points (one at gate and one where battle starts)
  • RIck: Improve sandbag area so enemies can duck better
  • Rick: Close off around the gate area so player cannot just run over the hill
  • Rick: Blood splat takes too long to fade off (frame or time related?)
  • Simon: Make magnum half decent. Its less powerful than the colt!
  • Rick corden off the end area so the player cannot scope the enemies without entering a fight
  • Community has asked for ROTATION and SCALE commands for LUA commands, so they can make their animating animals and things move, animation and face the direction they are going
  • Rick - If you move close up to an enemy you find they are not pointing directly at you. Can this be changed and make them centre in on the player? eg the eyes and gun should look directly at the player, not to the left of the player;
  • Levels show the wrong terrain style when loaded. For this to happen you have to add a new terrain pack (eg the new desert pack). Then load a level and you will see it's using the wrong terrain.
  • When you press SPACE, you can jump out of the water, the space should not work when in water
  • You cannot RUN FAST backwards - IN FACT YOU CANNOT RUN BACKWARDS (SHIFT does nothing)
  • Make tweaks to level, including a building with the KEY and some furniture inside the building room

Another internal test is due for Wednesday so hopefully we can get on with much more of the same. Looking (and playing) good now!

17 comments:

  1. That's some list Lee,hope you had time for dinner.

    ReplyDelete
  2. Nope, these days I start at 9AM on the dot and finish about 7PM, no dinner...no time!

    ReplyDelete
  3. Nice grass, although I'm pretty sure that guy's legs are inside that other guy's chest - lol! The guy who's closest, on the left. Need some character collision physics there. Then you could really pile the bodies.

    ReplyDelete
    Replies
    1. If the extra processing of inter-character collision is a concern, you could have it disabled for a character, unless its position is in proximity with another.

      This all gives rise to an idea hehe...

      You could create an amalgamation creature. When you have characters running around and pass through each other (since there's no collision between them), they could get stuck together and form an amalgamation creature. It would move and do whatever the sum of its characters wanted, thus it would be a bit confused (or well focused if a common target is in sights). You could slow and randomly vary the playback sampling rate of the character sounds (grunts, etc) to make them more confused/beastly-like. I bet you could do some funny stuff with all that.

      To save processing, you'd have to disable faces, animations, and textures that are facing inside the creature. This way a single creature of 10 wouldn't require 10x the processing power. Although you could also multiplex the processing among the stuck characters, thus slowing down the creature and adding to its confusion. So you could make processing conservation work ~for~ you in this case; make it part of the creature's nature.

      Delete
    2. If you had a routine that could combine meshes, removing any inside/unseen faces, creating a new texture from the others, and linking animation/AI to various limbs, and so on... then your amalgamation creature would ~be~ one character, and thus easier on processing. With that routine, you could also warp and add combination effects, running faces, blood spats, tears etc.

      You could allow the mesh-combining routine take several frames, and the player could watch the creature form. And chances are you wouldn't be adding more than 1 or at likely most 2 characters at a time. So it's not like it would have to combine 10 characters at once. In most cases, just 2: The new character and the already formed single amalgamation creature.

      This would also be an additional type of monster than zombies - and they would create themselves!

      You could even give the user the option of saving a creature, to use it as a starting character in another game!

      Delete
    3. A feature request if ever heard one ;) Thanks for the ideas!!

      Delete
    4. lol! Just a random brainstorm really. I'm actually not into shooter games :P But you're welcome!

      Delete
    5. Wow, talk about impossible to program! :P Imagine trying to mix the animations, let alone cutting up and splicing the bones! Haha great idea though ;)

      Delete
    6. Well thanks. It would be fun! :)

      And it's quite possible ;) Just think modularly and be flexible and adaptive. Again, you're creating one creature from several characters, let it evolve that way. That being the case, there's no reason not to creatively combine other aspects, such as animation, AI, etc., especially if it'll help processing speed. And it's not like the amalgamation creature needs to have the combined intelligence of all, moreso the opposite, which makes it easier. And it doesn't have to be (and shouldn't be) perfect. Much of such an amalgamation creation would be an random and inconsistent process anyway.

      Here, writing such a routine would be more a creative collaboration between programmer and software, rather than a programmer seeking to impose an inflexible will to the machine. Whatever apparent limitations you run into, find a creative way to ~use~ them as part of the creature.

      The same routine that does this could also do what Lee was talking about in his next day's post, just without the texture-combining, AI, and animation aspects. One routine could do both. Why not start by taking him up on his challenge, leaving that routine open to future expansion in this direction? :)

      Delete
    7. I just had another idea pop in about the creature... Not sure if I'd wanna use this idea or not, but I thought I would throw it out there! If assimilation of a new character into the creature will take some time, you could have the creature shit out deleted vertices, perhaps textured with a color that would be the sum of the deleted textures (or just a simple poop brown). You could set the specular highlights to a high value when it's fresh, and lower the value over time as it "dries". You could also darken the color, make it more black-like as over time as it "dries" as well. This poopy trail could be intermittent, as various deletion processes happen at different times (the trail could also be delayed from when the real deletions occur, since the real deletions will benefit processing speed as they occur).

      The poopy residue could be implemented as a decal or something simple and easy on processing power. Or maybe as terrain perturbations if you wanna be a little more adventurous. You could flatten them over time until only a decal is left.

      Implementation-wise, the drying effect would be very easy on processing. You could store a timestamp on when the poop was made, and only when visible, process/show it with the effects appropriate to the delta time.

      Delete
    8. Oh dear...vertex poop monster - it's so insane it will probably get created!!

      Delete
    9. Hahahaha!!

      Something else just occurred to me. You could use a similar idea to the texture tearing, ripping, bleeding, etc, of the creature... to morph ordinary characters into zombies (again which the user can save for later game-use), should they get bitten.

      Delete
  4. quite a list. Though all the things related to the engine itself and not the test level design, are what intrigue me the most.

    ReplyDelete
  5. This comment has been removed by the author.

    ReplyDelete
  6. Excellent. Enough said. Thanks for those things very much. Right on.

    :-)

    ReplyDelete
  7. When will we see basic water physics? Like be able to dive under water?

    ReplyDelete
  8. Excellent progress. Can't wait for 1.007.

    ReplyDelete