mdgunn

Yeah pretty sure I checked that first but as I've imported so many models in the process of trying to test this that I think I have stopped doing that. Pretty sure it was same either way.

Great....any chance you could upload a screenshot?

I think I can see a way to bring everything together into a game design doc/notes. I have started doing this but will take a day or 2 I guess till things stop coming to mind and I then reorganise things a bit into a way that will help us move forwards.

Tried doing it in lau code on terrain entity start but results seems the same.... function Script:Start() --Create a shape for the terrain based on the terrain local shape = Shape:PolyMesh((self.entity:GetSurface(0))) self.entity:SetShape(shape) Debug:Assert(self.entity:GetShape()==shape) shape:Release() self.entity:SetCollisionType(Collision.Scene) end Ball intersecting terrain and terrain showing where physics is and is not.

I am trying to use some externally generated meshes as low-poly terrains but the editor is not generating the physics collision 'mesh' if I have terrains much above 10K (which doesn't seem very big). It finds some faces then seems to give up. Using Leadwerks terrain not an option as I want these terrains to be modeled meshes which are islands with underparts I want to be able to fly/go to. Find attached 4 models based on OBJ files from World Machine taken into Blender and Exported to Leadwerks as FBX. Models are 50K, 25K, 15K, 10K. Only the 10K generates the physics 'mesh' fully. Attached maps directory from Leadwerks 4.5 EMPTY starting template project. Contained all the files involved. If anything else required please ask. If someone has seen large poly mesh terrains work (regardless of these test files) then please let me know so I at least know it is....or was(?) possible. Thanks. If there is a different approach please let me know, but using some sort of tile system is not my preferred choice at this time. Maps.zip System: AMD 1600X CPU / AMD RX 480 GPU / WIN 10 64 bit NOT WORKING @ ~ 15K.... WORKING @~10K....

Overall I think I am happiest doing environments, props and art related stuff thought I like most of these other things too. Currently I am mostly spending time refining problems with FBX mesh terrains (I have an annoying issue with larger poly meshes currently) and have also been working on brush kit for outdoor areas. I always thought the islands would be problematic to integrate (for me anyway) so I'm not that surprised it is taking a while to work through various things.

I think I can see something of a way forward now following along from what I was mentioning above. I think if we split the work into the following major sections we may be able to split work among a few people and move forwards. We don't need to do all of these things to make a game but I've put the things down that came to mind so we can be aware of them in splitting up work if we want to pursue them. I think at the minute COMBAT SYSTEM and QUEST SYSTEM are some main areas which will help take us forwards but I see these as having dependent areas which may need to be done. For example QUEST SYSTEM suggests possible inventory system. Here is one possible way to break things down . Not all bits are the same size: 1) COMBAT SYSTEM - whatever the person who does it wants to put in place but basically I think we should probably have limited arena areas which get triggered as you enter key areas or do key tasks. The combat work does not really need to care what the areas are or that there are quests just that the combat area should lock player in (doors indoors or energy shield wall outdoors). Player would have to destroy all enemies usually but that may not be the only option. Combat might be best if mostly melee but could be whatever implementer wants. Only about 2 enemy types. Melee plus projectile. Implementer does not do the enemies, use only stand-in basic geometry or simple shape. 2) QUEST SYSTEM - Simple at first. Maybe brush trigger based. Player can trigger completions of entering areas. Next more complex would probably be player needs item present when entering zone or trying to use it. Develop incrementally. 'Hard code' first 1 or 2 quests if need be. Do NOT plan and develop fully fledged system. 3) DIALOGUE SYSTEM . May be tricky to split out as it may need to integrate with quest system. 'Hard code' first 1 or 2 things. DO NOT plan and develop fully fledged system. 4) INVENTORY SYSTEM - KEEP VERY SIMPLE!! Initially do in way which maybe does NOT scale and so have to be flexible, just works for say 3 items with icons showing if holding etc. 5) PLAYER MECHANICS - If we go third person need the character with animations in place. Personally I think there is enough work that going TP risks the project not completing cause other tasks are incomplete. Still think if we move carefully we can keep the option of TP open for later implementation. Instead of TP I think there will be enough to concern ourselves with getting together a main player character that integrates with other systems such as combat, quests, possible mini-map, small experience system etc. 6) TERRAIN GENERATION - Base island generation and establishment of different overall biome. Desert, mountain/forest, ice etc. Aiming for 3 different biomes may seem like too much work but I have done some tests and I think we could have at least mountain/forest and desert/rocky. 7) AREA GENRATION - The is about the construction of individual sub areas upon the terrain. I think we may be able to build sub-areas initially with brushes using the brush kits to get to prototype stage. Initially can be created outside of terrain using brushes and basic CSG ground rather than terrain. Individual sub areas can be seen as seperate little construction zones which are then placed or rebuilt in the terrain once concept or area is proved. May need cliffs, rocks, plantes etc which may be specific to biome that can be placed to guide and block routes we don't want user to pursue. ? PROP GENERATION - Low poly prop generation. Individual areas need additional simple assets beyond those required to establish the play area and goals of the area. 9) ENEMY GENERATION - Limited number (2?) of simple enemies organic or hard-surface (quicker?). THis is not concerned with actual combat but model generation and animation and getting into Leadwerks in way that combat scripts can control. 10) CINEMATICS - May be able to minimise this but some simple camera pans and/or cut scenes via camera moving on spline may be an area that could be seperated out. 11) GAME OPTIONS - Menu systems and control of menu settings effects into game itself. E.g. global sound level control, music etc. Save/Load/Checkpoint System. 12) Sound FX/MUSIC - This may be split down or we may leave the finessing of this to someone that finds this area engaging while others drop in simple stand-in assets. Also environmental effects are often forgotten but could be good chunk of work here to setup environment sounds in all locations. 13) Skybox/Sky generation - May fit along side terrain generation work, but may be suitable to just split out. 3 or more skyboxes for our terrains. I think there will be others but these came to mind first.

Yeah discord meeting probably necessary. I prefer text to voice chat but it probably doesn't matter as long as people are there. I type quick so for me all the typing is not a big deal. I think you're simple list of tasks (wizard melee etc.) is probably a way to move forward and just get these basic mechanics in place. I think if we can get some prototype mechanics in place and working together then I think we will be in a better place to commit to some big chunk of work in various areas which we can then split up and work on mostly in isolation without treading on toes too much. Recently I've struggled to find the time to pull my bits of work together due to some real life issues. I'd like to pull together what I have of combat but if others want to pursue combat mechanics then should be no big deal. I will do following post on what as I see as the possible areas for splitting up so we can think about this as we move onward.

Yeah ...ward to protect . OK so ward was wand, that's also what i thought. OK.

It's slightly tricky to figure out until you/ve done it. I'm still not sure of the exact steps, just that I can do it eventually. Basically in the Render tab there is a bake button and a checkbox to bake to vertex colour. Rather than full render you should select Textures as it's just the texture colour that we want. (that you've set up previously with UV mapping). I think you need to put the object into edit mode and maybe even select all faces (may not be necessary) and then hit the bake button. If you go into Vertex Paint mode...or maybe even in other modes now you should see the vertexes have a colour even if the mode is not showing the texture material (if you know what I mean).

Testing the look of an island in low poly style using only vertex colours from model. NO TEXTURES. Eye Level

Started some tests of low poly CSG brush assets for blocking out outdoor areas. It should be possible to make these better but the point isn't to use these as final assets so taking them too far is not the aim. These are entirely brush based so can be modified or added to without round tripping into other 3D software. Hopefully this would allow anyone to block out a simple outdoor level. I think I will be able to upload to repo soon. WARNING: You may find using these early assets might lead to crashes.till I identify any problem brushes. I have found carving CSG brushes can sometimes lead to problems with the resulting brushes that can lead to crashes. I think because if you scale it or modify it in some ways it gets re-evaluated and can encounter errors. The purpose of this work on this brush pack is is so we can move forwards getting some simple outdoor environment tests done with some mechanics in place though I would still develop the mechanics in isolation in a simple box plane level (1 flat ground cube, the player and your mechanic only). I think it's turned out OK so far, though this would be just the start. Ultimately we probably WOULD export out from the CSG prefab, mod in blender, export FBX and import back to prefab which should then update any levels using the prefab. That's the theory, in practice you often find you broke the prefab link. But anyway as we should be aiming to keep things very simple then even rebuilding the level should not be unthinkable if the prefabs are good. This is a kind of green forested/meadow area. There would probably be others such as desert, mountain, ice. Maybe....

I've found a recent game that I think we could practically lift some mechanics out of. Mulaka.... I've played a little of this game and personally I found some aspects of the game frustrating and sometimes a little boring but I think it probably gets better and seems to get good marks. I think we could probably pull SOME (and only some) aspects of the following game aspects into our own: COMBAT - locked in arena is artificial but gives good way to control combat and any craziness LW navmesh and AI may throw at us. Also may want our magic system to be resource (energy) powered and melee to be the basic method? QUEST system - a VERY simple dialog system is probably practical to get into the game. ART - reckon we could probably do the level of environment art here. Character and enemy probably doable but probably limit would be 1 or 2 simplified enemies (floating - no walk cycles, complex body animations). CONTROLLER - The game may help us refine a third person controller if wanted to keep in this direction. It would be nice but realistically i just can't see us delivering a polished enough character to make the time saved in just going FP initially (can always do third person mode when we actually HAVE a game). I suggest we keep TP in mind in any design and test with TP controller as well as FP initially till someone CAN deliver a character we can see working as the TP controller. This isn't necessarily a game I feel I must make (sometimes you feel for a game you want to make yeah?) but it's a game that may be practical make. Any thoughts?

I feel unsure about on how we get this game onto more solid ground and move forwards. We seem to lack the core of the game still. Islands and wizards are not a game, could be things in a book. What is it that is going to be the game? This still seems to be a problem and why game design is just hard. In a group environment it is particularly hard where things feel less solid. I think trying to collect together everyone's ideas is VERY difficult to feel a way forward. How do people feel we can move forwards? 1) GAME-JAM APPROACH: Maybe people do own mini-game featuring only 1 or 2 mechanics. Theme would be wizard/magic/tech and floating islands (though I think this is not really a theme but a setting - which is not that useful for ideas in themselves). These are then either fleshed out to their own mini-game or integrated. May seem tricky but I see the lack of clear game mechanics as a big problem and why a CSG mini-game could be a way around this. 2) DESIGN DOC APPROACH: We need a more defined design doc which contains some idea of mechanics and why this game would be played. I'd like to have a stab at the design doc but I think in a democratic group with various loose ideas put forwards it is hard to collect this into a game. I may still try to have a go at the design doc. 3) RIP-OFF APPROACH(in a good way!) :We rip of an existing game. Not a full game a subset of that EXACT game. This sounds bad but realistically it is probably the easiest way forwards. If we have a clear reference game then we can better know what we are aiming for which seems very difficult at this point. Not the same game but a subset of mechanics from 1 or 2 clearly identified games. I think my choices would either be 'Atlas Cube' or 'Ico'. Both are fairly abstract games with simple mechanics and limited play areas. I would ditch ANYTHING from either game that caused extra work beyond a simpler more direct solution and any version would clearly be a small subset of the mechanic of each game and would be developed 1 mechanic at a time. Other suggestions of how we move forward? One problem is I think right now I'm not clear who is active and who is doing what?

What the heck is a ward anyway. I thought people meant WAND but I've googled Wizard WARD specifically and it doesn't seem to be a wand and Google doesn't provide any clear picture of what a WARD is IMHO. Has this term come from some game I'm unfamiliar? Do people actually mean wand?

Nice modelling. Like the choice of subject. Its got some steampunk feel but has a strong character of its own.

Glad to see proof in my own eyes that standard Monster AI with navmesh can in fact navigate the island fairly well. I was quite worried that I'd find it just didn't like a large model mesh .Maybe some already knew this was not an issue but I wanted to know that the islands specifically would be fine without having to craft our own navigation if we didn't need to. For some reason the soldier AI won't move (which is the problem I had on another map) but I think the monster AI probably worked fine there too. The Navmesh is being generated at runtime here which slows things down. I couldn't get the navmesh to generate in the editor with various settings (collisionhull mesh in model didn't seem to work either in my tests). If someone knows what settings you need in the editor to generate a navmesh on a model (not CSG or terrain) then I'd be glad to know as it seems it should be possible.

As part of getting the AI playing nice navigating an Island I've created another test island while playing a bit with generation, textures etc.. Not tested the AI on it yet but if I can get the AI working OK on this I should be in a position to check in the island, and some basic AI with weapons soon. Playing a bit with more realistic textures than before, though at low level they have a pixelated look (on purpose). May go back to flatter low poly look later.

Yeah, correct. I happen to have a robot type thing as I could knock one out in a 3 minutes on a potentially throw away hard surface character than 30 minutes on a throw away organic model or a 3 minute organic model that is so bad I am annoyed every time I see it. The 'missile' is just a prefab that would be anything else. Fireball, whatever. I'm not really writing new stuff as such as just trying to get together a coherent approach with standard LW methods of weapon prefabs, projectiles etc.. Maybe someone even has better approach they are happy with if so maybe we can open it up for discussion. I think it is probably best that the 'missiles' have their own script, rather than being controlled by the character or weapon that fired it (though it could be that too when need be- though I think a reference back to the character would be better). If someone wants to generate whatever weapon or missile they want then they can probably just go ahead knowing that the missile thing can have it's own script and not have to tie it into the character or launching weapon. Just have something spawn it and let it fly. There is a spawner script in the addons directory (if anyone needed it), though I think it is is possible to get it to crash the game if the spawner AND item both try to delete themselves, so people can just use their own if they have issues with it. At the minute I have issues with the AI navigating a FBX based mesh (the island) so it seems to make sense to crack that otherwise if the AI is so useless that they can't GET to you it doesn't matter about all the firing/weapons etc. and we need to ditch navmesh navigation. I think I can get it to work at the minute but I need to find time to crack it and/or check-in a sensible change set for others to maybe put better AI in place etc.

Currently experimenting with the mesh terrain islands and standard AI nav mesh pathfinding. Initially wasn't sure how to even get navmesh generating on a model (rather than terrain and CSG) but got it generating now. However the AI seems to have issues with moving around so great so need to look into this some more. Did a bit more experimentation with islands. This can be quite time consuming.

Still working on enemy weapons. Not too far off having missile, gun and melee working (gun firing shown below). Currently working on enemy attacking player but should be able to get missile, gun and melee working for player. Using existing default script methods of projectiles and weapon prefabs. Enemy is switched to use Solder AI. We could do something completely different than using standard scripts if someone thinks they have better scripts but for now I'll continue using these as I'm not really expending time writing them. Enemy has a death animation now but of course this enemy isn't even supposed to necessarily IN the game so I'm not wasting too much time worrying about this, just refreshing my small knowledge of animation in blender and into LW. So hopefully in a few more days there will be the basics of enemies in the game which can melee, fire guns or rockets and the player can do the same (with mostly the same stuff). The hope is that the weapons, projectiles and explosions are all separate prefabs so these can all be separate things shared by enemies AND players. The white gun above is NOT part of the tank but mounted on it as a separate prefab. This isn't all there yet and maybe it will end up taking some more time to get all done so maybe I will do some more updates in a bit before it is complete. Maybe after this is all done people can jump in and use some of what we have so far to construct some play area, come up with their own enemies, weapons and ammo etc and this may help us move forwards some more with an action portion of the game.

EDIT: Probably would have been better posted in Development I guess. Added for aiaf to consider as possible start point of teleport functionality. Added teleport addon to repo. Wrote it some time ago. May have extra unnecessary stuff in there but I did a quick review and I think it could form a good start point. Kept it separate as an 'addon' for now. The teleport can be one way if you don't set a destination on one of them (see example start.map for what they look like hooked up).

Added teleport addon to repo. Wrote it some time ago. May have extra unnecessary stuff in there but I did a quick review and I think it could form a good start point. Kept it separate as an 'addon' for now. The teleport can be one way if you don't set a destination on one of them (see example start.map for what they look like hooked up).

Really want to redo at the map with structures under it. Was really only demo quality so will look into redoing. What would the portal system do? If it is teleporters then I have a teleporter addon I can add in as a starting point .

Yeah this was why I did one of the islands with a more man made looking round lobe coming out and the bits underneath. I was thinking maybe the 'land' on top could be overgrown from decline like soil has accumulated and plants have colonised rather than a bit of actual land that for some unexplicable reason is a floating island. The lumpy tech stuff underneath would be anti-grav generators, 'air-ship/glider' docks, etc yeah. This would suggest any internal 'cave levels' present would likely be more decayed sci-fantasy corridor than natural rock formation I suppose, unless this same tech has been used to raise land sections into the air too.