mdgunn

ok I think I see. I think I have not fully comprehended all that is going on in this room. I think to get to higher complexity you really are best with the user taking very small steps to understand by DOING rather than understand by READING (I mean in general, not necessarily for this example). As far a single room versus map changes... if it's best this is a single room that changes then that fine too. Maybe things just show and hide to help manage the complexity of puzzle steps, if there are steps. If we just want something complete without having to change much beyond making the room a bir more varied then we can just leave as is the puzzle though I think I did not understand the full scope of how the room works.

Added an image to image section showing what broken up block level might be like will play a bit more. As I didn't do the mechanics I'm avoiding tweaking those but the level layout I think could do with some variety while still allowing the main mechanism to not be broken up and hopefully to add some interest on the way to completing the puzzle. I will try to do what I can to move forward some of the concepts I mentioned above, not necessarily to get them complete but to show what I mean first too.

The teleport level is currently very square and all on a single 100% flat square area. The attached image is still square and roughly on the same level but is experimenting with a broken up level to add the simplest form of visual variation and level change into the level as a test of something which may change to less square, on a more broadly varied level and with less blocks to produce a wholly non-square design.

The text above is probably hard to follow so don't worry if you don't fully get it. If you have different ideas or things you'd prefer to add remove I'm not precious about anything said above. Also, in the above there is not really a notion of a flying island. If possible I might try to make it clear that there is a buried ship in the landscape with a distant circling camera shot as the meteor descends or something. It would be later on that the ship emerges and effectively becomes a flying island. If we went further later then we probably would be outside and moving around on the island/ship surface fighting AI but those things although partially developed still need work and due to numerous things interacting player, enemies, environment, health systems, weapons, navigation etc there is a lot that needs to be done to a good standard to be interesting and not feel a bit broken.

Suggested running order for trying to use what we have to put something together which has some linked environments which overall form a coherent story segment. I had a look round the last version of the code and so joined this together based on what seemed to be the intended levels though there may be other assets which could be used and maybe I chose the wrong things. This may help us tie things together though.... I can probably break this down better into clearer text and break out tasks. It may be necessary to see who might be able to do what before I spend too much time breaking this down if others don't have too much time to tie these things together. I don't think I would release what we have without attempting to compose the bits into something which makes sense as a whole.... Here goes..... In summary I think we can assemble the assets we have into the following prequel experience/demo giving a taste of the game with the following running order: 1. Improved menu with Save/Continue function. Think even in a demo we should not make users replay levels they complete and this is a simple task to track level. 2. Intro Cinematic - re-use space cube shot and reworked meteor hitting island and ending up in cryo room via camera track. Though this seems to be non-essential mechanically for the game there is opportunity here with our cryo room and some simple camera moves to establish a simple but engaging start to the game. 3. Dream Level - Minor environmental improvements and player feedback improvements. Reduce FPS slowdown. 4. Cryo room - Improve a few of the meshes slightly to be script driven objects (e.g. opening locker or chest so we can hide items there). Finalize the meshes with physics and simple textures with colour accents. Add simple fetch quests to link game items and together and reveal vague story via dialogs. 5. VR Monolith Teleporter level - Add some environmental interest and break up square linear room into small set of 3 sub-rooms which each are more complete in their structure (less holes) to symbolise us getting the ship systems back online. Think of a cross between Atlas Cube and Q.U.B.E 2 (see google images). Use environment probes, simple reflective textures and some glow effect to get a simple effective look. 6. Exit cyro room to ship surface/island - Leave room via roof escape tube and show robot enemies emerging from ship vents and about to attack, fade to white...END If we have more time then we would explore island fight some enemies, get ship/island into the air and do other stuff! I feel fairly confident that I could get all these bits joined together into coherent experience so what I've mentioned reflects what I think I could personally do on my own if I had to. None are huge complex things to my mind but together there is still quite a bit of time to complete all. Personally I work a day job have kids and my weekends are not necessarily my own so even with the cut down list above I could see it still take 2-3 weeks to get to the stage that I would be happy to release. Here is some expansion of these items. though you may find this hard to follow. - In order to inject some colour in the simplest way suggest we pick a basic enemy friendly and neutral colour - Decide enemy signature color. Red? Enemies will tend to have this colour on them matching cube. - Decide on good signature color. Green? Ship and hero (hand/weapons) will have hint of this. - Friendly environments/items will tend to have green highlights, enemy red. - Neutral elements may have blue highlights. Display planels, environment lights, colour highlights on objects. This gives us simple way to introduce meaningful colour into levels to avoid pure monochrome. Preload/Loading screen - Enhanced Menu Background - Visually upgraded title/menu screen. Shot of metor/cube either static or spinning. - New Game/Continue - CONTINUE Menu Should have new game or continue option enabled if user has made it to a certain level (so current level neeeds to be saved to config/storage entry and read back on load) ESTABLISHING CINEMATIC/IMAGES Initially could be still images/renders of these things but I think we can probably get in engine version as we have parts already. Meteor shot we already have with additional planet backdrop/ Cut to meteor coming down near ship vent protrusion and entering through port (simple move platform script or similar). Camera follow on spline path or linear path going down duct to show cube locked positioned in receptable in the bridge/table area of our sci-fi cryo room. Locking claws close around cube (simple leadwerks rotate script). Alarms go off and flashing lights. Camera cuts across room to cryo-tubes. tube 004 extends from wall (particle effects). Camera moves towards cryo tube where head would be and fades to black while alarms continue to play and artificial voice (or screen text) announces something such as 'Emergency Protocol: Cryo Tube zero zero four, accelerated revival initiated'. DREAM LEVEL - Pretty good. Platforms that dropped were a little confusing at first but the simple level traversal mechanic was engaging enough to encourage numerous retries. SUGESSTED IMPROVEMENTS - Clearer Indication WHEN (NOT WHICH) platforms drop - Sound indication and would be better if first platform to do this was somehow more in eyeline. maybe you jump down to it so it is clearer when it drops. Perhaps timed camera shake script. Visual Goal . Think it's always good to have a clear visible goal, even if the path there is not a direct line. Maybe super-sized version of the monolith that you need to move towards. This always adds more visual detail to the level. Additional visual details - Think there maybe should be some additional background detail. Perhaps something that links back to real world like cubes spining and descending in the distance. This would also add a touch of colour to the scene. CRYO CHAMBER Simple fetch quest within Have some simple collection of a few items around the room. E.g. tablet on table initially shows low battery icon (could just be sprite in position over screen). Then when powered up needs a pincode to be found, pin code hidden in locker in locker. in game mechanic terms just set 3 boolean flags to and normal ipad operation only triggers when 3 globals (or something similar) are true. ipad gives some backstory info and spoken password to access VR headset. When we know password VR Headset on table will activate once we have got the password this will take us to Monolith teleporter puzzle. MONOLITH TELEPORTER PUZZLE Storywise the purpose of this section could be to represent the user getting the ship sub-systems back online or perhaps just the escape system which will result in the upper escape tube in the cro room to descend and allow access to the surface (which actually the upper surface of the ship grown over with nature - which would be our floating island when the ship is fully restored and airborne - though our story may not go that far). Currently The puzzle is initially a bit overwhelming but in is actually quite intriguing and suprisingly complex in it's internal structure. I think the with some better presentation and perhaps done in 4 steps where code 1 is just to operate the right teleporter (like now), step 2 is a 2 step code to ensure user gets it and step 3 is 5 step code. I think each time the code is complete the user is teleported to a more intact structured level and at the end of the 4 codes the user ends up back at the ship and exiting the VR headset. I strongly think the room needs some simple added visual structure not flat square single level arena. I am thinking an 'floating' irregularly structured arena composed of blocks, some of which are missing and some of which are mis-aligned (suggesting a malfunctioning environment) There should be some variation in height to form a simple maze-like structure, but one without walls (and you can fall off). EXIT SHIP After VR section escape tube will descend in cro room. Player will enter. The tube will have a lift platform in it to take them the short distance (5-10 m? to the surface). After exiting the ship we see nice low poly landscape with some odd vent like structures near by. From the vents and floating alien enemies (that we have done already) emerge and possibly some floating tanks. We see our hand raise up with an embedded hand blaster weapon, we hear the weapon charge, the enemies continue to close. The screen fades to white and we hear blaster sounds and explosions and sound of electrical/mechanical sounds of descruction.

Looks like I may be getting a bit more freed up to try to help pull together a release. I'm fine if you want to move on. Totally understandable. I got to do some things I'd never done which is great. I might go on to take things a bit further. I checked out the levels and I think it has the feel of something that could be something. Personally I would not release these as is but take them just a bit further. I can probably help with that. I will see if I can get some ideas together of how I might approach getting something out from where this is now. Maybe some work can be split up. Hopefully add something later today.

I may be able to get back into things soon. Work has been busy and I've had some other things going on. I'll have a bit of a read though things when I get a chance.

Are you on the beta branch? I had an error just now when I was on the Beta branch but complaining of an error in Button.lua. I'm back on the non-beta and my build starting without error.

Been away for most of xmas so far. Hope to get back into things in the next day or so (been rather ill yesterday). Will check this out.

Wasn't there something in the workshop with some modified shaders that were aligned (more or less) with substance painter exports?

OK. Not meaning to disrespect your idea. They are not bad ideas and as you say may have been relatively easy to do. It's not that I want to ditch the story but I think it may be best if some of it is backstory we know about but we try to mostly let things unfold through action. The story is still a good way for us to have a common idea about what is going (the back story) even if we leave it a little less clear to the user where it may be enough that it is clear they need to do a thing because they need to not die, rather than because its exact position in a larger picture. Maybe. I'm no narrative expert. Currently I guess in my mind I am trying to also see a way to get to a 'milestone' point as I think you are. A position where we have a demo of sorts. I think I don't know for sure if this will work out but I think I would do would be like this:- - Refine your dream section a bit. Maybe re-using some ship models for wall, floor etc. - I finish cryo room modelling. Add in some simple interactions like your dream room, such as a) turn of alarm, reset systems, get info on initial task (stop incoming drones waking rest of ship). - Secondary ('solider' cryo room ) - can re-use bits of first. Small enemy skirmish, disable wake-up machinery, gain hand-weapon. - Simple key quest to open outer door. Move through a few simple rooms and corridors. Enemies can pop in with simple spawn mechanics. Hand-weapon thaw-freeze might be used to activate or freeze mechanics or hazards. - Exit ship to island and navigate island natural environment and deal with incoming enemy threats around a few key locations (e.g. exit, village etc.). - Get to some key ship location at other end of island (e.g. escape fighter bay). - There can then be a reversal of sorts of entering ship navigating corridors and then entering key room (control room/fighter bay - maybe we go to both). - I think at this point we then end after a last fight enemy fight in fighter bay or in escape fighter protecting our bigger ship or something). I am not cross-referencing doc when putting this together so it might not quite fit what I said there but in general I think maybe the outline above could work. This is still quite a lot of work. If you have any interesting mechanics then they could be brought into one of the items above or replace it. Not trying to dictate the exact path here so if you have suggestions please let me know. If you want you could propose an alternate way of getting to a natural end point and we can merge things together.

Interesting ideas for sure. Not sure our player would understand what they are doing. Currently I am imagining the things are coming from space are not the monolith but these smaller these numerous activating spheres. These are like little simple drones sent in large quantities. They are like little seeds. They are getting scattered across the planet. If they land near a ship/island they can burn/bury down in the ground down to the ship and enter the ship. These might be about 50-75 cm across and I had imagined inside there might be a sort of power core sphere and that the freeze/thaw weapon is taken or merges with our character near the start when she stops her own ship waking up, by blocking/destroying the incoming spheres in a second room (or room near the start). At the minute I had imagined that this process had happened already (a sphere had entered) and this was maybe what had woken up our character as she had set this as an alert event before she went to sleep. Could be that the island starts submerged and no sphere yet and we start a bit further back but although showing all these earlier things might be cool it's probably a lot of work and best at this point to work forwards with some easier game mechanics until we have a few things tied together. If need be there could be static images and text that tell this earlier story. We have to watch how big this thing gets. Could STILL be that the monolith also came from space, perhaps it is like an AI/computer inside also sent in response to the awakening spheres and that this has been sent to trigger the characters awakening. I think narratively it might be confusing that in the early stage you seem to actually BE this monolith - the player will automatically associate controlling a thing with being the thing I believe. And then you're not the thing and you're this other person. I think it might be best to avoid a lot of the story telling, but avoid things that might be confusing (e.g. switching characters). I'm not saying ditch all the story so far. It's still important for us to discuss these things as backstory. I think it's useful, but I think we should be careful about actual show and telling to the player.

Yeah I'd destructible objects was something I'd considered. I've had the mechanics for this working before (an object which can take a certain amount of damage before getting destroyed). The bit I didn't do was the actual visual destruction (falling apart) with physics looking right for the destroyed bits. Should be possible but can't say I've done that.

Way back I think there has been mention of possible fire and ice spell/effect/weapon. I've been thinking about this a bit. I'm a bit wary about combat with AI being a possible area of long term interest for the character, and problems in implementation (e.g. AI getting stuck on walls etc.). I was thinking that maybe this freeze burn mechanic might be useful as a puzzle element (and also in combat). In theory it seems that it would be fairly simplistic to use this freeze burn(thaw) mechanic to start stop physics based elements (e.g. using a motor), or perhaps to just use programmed step motion (meaning not physics based). WARNING: I could be very wrong and it there MIGHT be a lot of hassle in trying to pause and resume physics based processes. God of War had some good use of ice and fire in both puzzles and combat. Could be an area for future thoughts if anyone has any. As far as combat usage I did do a bit of testing with item effects (e.g. poison, burning, ice/slowdown) some time ago. Don't think I got it finished but I think it looked like it was going to work out OK. I think I basically passed an effect along to the usual Take Damage function and then use it to apply a setting on the object and start a timer if it was going to be a timed effect (e.g. poison). Anyway, something to think about.

I'd been thinking the same that the minimalistic style as the first level might be jarring if it is lengthy and different to rest of game. However, I also thought it was quite a neat idea of having some pre-wake up sequence where something is happening to trigger the character out of deep sleep. I believe there's something similar in Prometheus? So, at the minute I would not totally rule out a short dream/wake-up sequence but I think it would have to be quite interesting in it's environment visually but also short. Could then be introduced in a more significant way later on as you say. I like you're thinking here. Maybe there is scope for some simple puzzles and info gathering within rooms and corridors on way to surface?

Did a quick test with the lights tutorial level. Seemed OK even on high though I'm on Vega56 now. When I originally played with it way back (generally actually avoid it because of past experience) It seemed to have increasingly negative impact beyond the first several clicks up from zero (before half way I seem to recall). Perhaps it is not the volumetric light itself but it's effect on other things such as certain shadow settings. Could be I was on a limited laptop GPU in some of these experiments so maybe this was also a factor. Maybe it operates differently these days. Anyway I'm really pretty sure I wasn't imagining things. It did seem something was occurring. Very possibly side effects of bad setup, but then how would a new user know this if it can be this?

Yeah volume light is SUPER SUPER heavy on FPS. You can almost get away with it if you keep the setting very close to minimum. If it was present it would probably need to be something that could be specifically toggled off in settings or with a low/med/high setting and it only on at high.

I can try and do some particles for the teleport if you want me to try that bit. Here is a vid of some I did a while ago. I've probably lost the assets I used here but I can recreate.

Revised teleport pad. Nothing fancy. Think you will find in Prefabs/Architecture/teleport_pad_v3

You can change the scale of the instance in one or more directions to adjust apparent if you just want it smaller in a certain direction but yeah it's pretty awful . It was one of the last ones I did. so after doing all the rest just wanted to get something out and stop modelling for a bit. Maybe I'll just do a teleport pad with just a bottom bit. If you wanted any more props or wall/floor elements and stuff like that you can let me know. I don't want to get hung up on trying to finalise lots of models but prototyping some fast ones (e.g. untextured) that even might get thrown away may help solidify a style. So, just let me know if there's anything else. Don't mind doing alternate versions of any, though I might shift focus back to other things for a bit too.

I got it working There are a few things needed for things to work out. You need a property named 'enable' on the script attached to the object you want to use/trigger You also need a method named use in that script. Like this... Script.enabled = true--bool "Enabled" function Script:Use() System:Print("USE CALLED ON TRIGGERMAPMUTATION") end You will find these present in your working script. The other thing is less obvious. The other issue here is that I had to collapse the model. I think in some situation you don't want to do this and I may need to work with this a bit and understand what is going on. I think basically the top level object of the teleport is probably empty like a null or empty so there is nothing for the raycast to hit, even though physics seems to be on. It is probably ON on the lower level objects but not this top level object. By ON I suppose I mean the physics are really defined for this lower child object but there is no geometry at the root for there to be anything to be hit. I think when you collapse the model all the geometry that might be on lower branches all end up on the root so a raycast will hit it. Sometimes you don't want this. For example I think you could make it so that you have a hitbox specifically setup on the HEAD of a character which might be a child of the body. You can then specifically detect headshots if you do the right programming. For the simple raycast that the FPS controller current uses I think it is probably simplistic and just expects to hit something at the top level where the script is attached. So in summary 3 things needed: 1) Collapse any models in model editor if relying on simplistic FPS use/raycast check. 2) Add enabled property to the script (Script.enabled=true--bool "Enabled"). 3) Add Use method to script (Script:Use() ) Any problems just get back to me. It's useful to work through these first teething problems.

FYI Josh: Unsure if it's connected but there was a recent FBX issue in the forums. They struggled with importing the tutorial assets. Got a bit better results on an old version 4.1 but never got current version working properly I believe.

Probably Props collision, but have you added a collision type to the MDL file in the model editor, if not set there to be box, or object mesh etc. then the RigidBody type doesn't have any physics mesh to collide with. On way out so can't check your example but may have time much later when back.

Though 'dream room' might have been interesting if it had a sort of abstract geometry or even abstract maze you progress through as you unlock info or items or something. Like the walls or floors retract or shift as you progress (maybe that is frustrating and confusing)....thinking a bit like bound (PS4 VR game). Just an idea though .

Gonna have to head out. When things are entities I think FindEntity may not find them as I believe they actually don't get a name value if an instance. I'm, not sure there is a good Leadwerks reason for this, I was surprised by this too (if we are talking of same thing). It sort of makes sense, if an instance it is not really a full proper copy. May be a way to get round it (in script). I think the easiest thing is if you just go ahead and break the prefab link so it is a full instance (just edit a property to get the dialog up). Keeping prefab links in place is something to watch out for as we further develop but for now a few broken links are OK and probably necessary and quite reasonable so don't worry to much, especially for unique objects. Where we have genuinely lots of copies of something then keeping the link can be more important.