mdgunn

Had a bit of a break after doc to refresh my mind. Ready to move forward again. I think if each person tries to construct a simple area with some simple mechanic and hopefully someway in which they can see it fitting loosely within the concepts in the doc then that would be a step forward. Something like this where I was testing out AI navigation and combat. This arena is about 3000 x 3000. Sounds like aiaf has a plan for a few levels. We still need to get combat finished (weapon ammo/pickups, shooting/attacking, taking hits, weapon inventory ammo counts etc). I can do that unless someone else feels they can do it. I'm happy to pass it over if someone else feels strongly about it. The other area I would like to finalise a bit further is a basic island/spacecraft. All the islands don't have to be spacecraft (could maybe just contain some tech power source). I think it will still be tricky to have both an island worth moving about on, and a spacecraft that looks good all in one (compared to just a floating rocky island) but I think I will still have a go. I suppose those are my 2 main areas that could be finished off. I in general I am also thinking generally about level creation and model creation and how we can try and make sure they look like they go together rather than looking like a strange Frankenstein's monster of different assets. Thirsty Panther what area do you think you would most be able or like to tackle first from this point? Could be mechanic focused or level/area focused or some balance of both.

Personally I'd probably let him know, though I'm not sure there's a clear way to replace. There were recent changes in model imports being discussed, relating to some new more portable format gltf or something (probably got that wrong). Not sure if those changes are actually on the standard release. I'd expect them to be on the beta branch but not sure. Anyway, you could be you're getting hit by a legitimate but rare bug only recently introduced and may be easier to locate and fix when Josh has recently been in this area.

Hmm I was going to suggest it could be related to the specs of the 940MX but it looks like it suggests OpenGL 4.5 so I think that should be fine. I have run Leadwerks on a few mobile chipsets and was fine too. Not too sure about causes yet. Would suggest trying a version a few back if you hadn't using beta tab. If it happened to work without problem then Josh might know what cause might be given changes in between and the type of error here. However given your situation I think I would expect stepping back not to work. Another thing to try is create a project with either or both the Marble Game project and the First-Person Shooter projects. If they both work then Leadwerks is probably mostly working and the issue is limited to just this area of model handling or new models and the scope may be narrow enough that Josh has a good idea about a possible cause and solution for you to test if you contact directly.

Could be something to do with different things on different drives but I have my various bits in different locations. My steamapps with Leadwerks is on D, my user data is on C and my Leadwerks are on various other drives such as E . I know when creating projects in Leadwerks it wants to put them in my User space in My Documents (I think) but I always specify a different folder such as E:\WORK\Leadwerks or whatever on an alternative SSD drive. Doesn't seem to have a problem when I create a project where I specify if you think this may have thrown it out. My Leadwerks.cfg remains in my user space as I think you are saying too. Could be Leadwerks is generating some additional logging information that might help you. It should appear inn User\<USERNAME>\Documents\Leadwerks. It will likely be showing similar information to what you should see in the editor at the bottom but it might have something extra, or be easier to see it all in this log file. Worth persevering a bit more. If have some possible info on the likely cause then and it is something Josh (the software) author can do something about it then it may well get fixed rapidly. It is common that issues that can be reproduced by Josh are fixed pretty much immediately (or it seems that way to me) and are pushed out to the beta branch (available in steam). It would be important that Josh can reproduce of course. If you have some good info I would recommend a direct message to Josh via the forums. BTW: Your test of the blender cube export via FBX is a good one and should have worked. I exported a from Blender all the time. It may be possible to export from Blender from an FBX version that Leadwerks does NOT understand (as one problem with FBX is the various binary and text versions that exist now) but I regularly export form Blender in FBX with the default version it specifies without problem.

Unfortunately this sounds like it might be very specific to your machine (I don't recall anyone with this issue before - but maybe I missed it). I can only suggest things to try and determine if that is indeed to problem and then to try to narrow down what might be the original cause. I personally have imported FBXs all the time over a number of years and different versions of Leadwerks and different computers (laptops and desktops) and I don't recall seeing this issue Try the following: Try a different machine - I know completely unhelpful if you don't have another machine, but if you do give this a try and report back on if the other machine does happen to work You can try an older version of Leadwerks in steam if you go into the beta tab. I suspect this won't fix it but it's quite a quick and easy test.

When doing vertex colours I usually still apply a super simple white material (usually the white one in Material/Simple) . I forget if this is necessary but it may be something you need to do. If you notice the colours freaking out in leadwerks (I've seen them flip colours to a 'negative' version) it is possible to get it back. Usually if you reassign the material or switch to another and back it sorts itself out. May be just a strange temporary editor issue rather than a permanently saved problem with the model material.

I did a video with a navmesh test see end of this post. AI worked fine. Something about the Soldier AI had an issue but the Monster AI was fine. I think up we agreed about 100m, I think it can be higher maybe up to 200m but then I think there will possibly be too much space to wander around in. Size could lead to slow down and we probably need some more tests for this but currently I didn't see it as a problem. I will do some further test though and maybe stick some test files in the repo of the same mesh but at different resolutions and test the slowdown.

I'm fine with helping with CSG and models. First I would probably go with CSG even for models .....Do you need some advice on how to tackle this? There are a few pitfalls but I can do a post if you want? Not saying we shouldn't do models. It can be fun for sure, but be an easy distraction from focusing down on the mechanics. You're idea for starting the first room is fine. I'll mention how I saw it as I think I did not fully expand the way I saw it so I may as well mention it so that you have more 'juice' to fuel your idea. Though if you prefer just ignore too to avoid 'contamination'. What I had in my head now (which I don't think ended up in the doc) was that the room we wake up in might be a smaller room of staff cryo pods. The hero staff member wakes up through some trigger they have put in place in the main computer. I was thinking they had programmed there waking to be triggered by the proximity to the ship of the incoming meteor shower cube/sphere devices. They wake up and need to get to the second main cryo room in order to stop the sphere activating the main re-awakening sequence. So I saw the first room being smaller and the second being a bit bigger, possibly with a first battle but also possibly just to pick up the hand-blaster thing and the battle being in the next room, perhaps she has to try blaster out with some shots in the first room. Maybe freeze thing thing, thaw this thing or whatever. The hand blaster thing instead of wand is just an idea. Some sort of wand thing fine too but I thought embedding something in a hand was a bit different and potentially super easy to do......get any old hand model and any old thing. stick them together with a pivot....DONE. Think I had it all done and shooting, though maybe we'd use a different hand model. Anyway don't think some of these details need to hold us up if we focus very much on simplistic CSG and mechanics.

I don't think I specifically said in this forum what happened before I switched to doing mostly the doc.... I added some info here now...

I don't think I really mentioned it but I'd encountered a Leadwerks issue where the physics collision mesh was not getting generated on the higher poly count islands that I was trying to generate. This is now resolved and the problem is to do with the objects not being scaled to a large enough scale BEFORE being imported in to Leadwerks, or that I think is part of it. The issue was rasied in the bug forum here. Now this is resolved and with the incremental tests done so far I think I am probably in a better position to generate something more final (though I still think there will be a few more iterations before we actually get to final). Now that the doc is out of the way and I have a solution to the bug I ran into I will move back to trying to get a 'final' island. Note: If anyone had some design for how they wanted an island to look and wanted to do a terrain in Leadwerks to test their shape then it is actually possible to take that Leadwerks terrain and take it's height map and run this through the process I'm using. Might need to test this process a few times, so don't go crazy generating loads of terrains but in principal it should work. Whether the terrain ends up looking as expected once taken to low poly and vertex colour is another matter. This image below was an example of a Leadwerks terrain taken part way through the process. The mountains say 'M1' - drawn badly in Leadwerks terrain editor. The pic is tiny as I'm at work and don't have the original.

No problem. I thought this was the intention. If we want to stay low poly then we still have a chunk of work todo unless we can get a low poly character out of mixamo. There are a few other options that would involve us putting in varying degrees of work. For now I personally think it would be better to not pursue the character model until after we have some prototypes done. I think third person should be born in mind for any levels, so more open than tight spaces. I would just develop with existing FP for now and secondarily test with the existing TP controller we have to see how any prototypes feel but not to adjust necessarily to fit completely with that controller above FP controller.

Not sure I mentioned but the terrain vertex colours were done by projecting an existing texture (which had been generated by the terrain program) onto the vertexes, not painting. If there are existing textures on objects then you can do the same to project their textures, otherwise you can paint them. Sometimes the way the vertex colours smear can look a bit odd and it can be better just to use the low poly palettes for objects. If the low poly palette is used by lots of objects then this very small texture shared by everything probably has virtually no hit hit on performance so no need to vertex paint. With the terrains the texture can be much bigger and has to be unique for every terrain so vertex paint can make more sense for low poly terrain than low poly objects.

Is there an issue here with high-poly character with low-poly design choice for world? Our reason for low-poly was (I think) partly to make sure modelling was quicker and more practical for us to do. It's a good choice for these reasons, even letting us get away with vertex colours for terrain if we wanted to. Having said that. I think that if we did want to go higher poly - by which I mean a bit higher res and proper texture maps - then that might be a possibility within what I think we're capable of though it probably would extend the time it takes.

004(Forth) - Game Design Document_v0.0.2b.pdf NOTE: This doc IS on google docs but I don't know how things work out with multiple people editing. Probably fine but not really done it. If anyone wants access to work on the doc I can open it up or we stick it in repo. Here is the final(ish) design doc. It could be taken further and loads more time could be spend to detail all assets etc. but I don't think that is necessarily the way to go with this. Think we probably need to just have a few ideas in writing so we can firm up our own ideas of what we want to work on (even if it's not in the doc) and evolve from there. Some things probably fee a bit incomplete. I've just tried to get some ideas down really. I could list a load more weapons or enemies but I don't think it's necessary as long as we have SOME thoughts down to think around. If people want a radically different story or radically different anything then fine by me. The story has ended up quite a lot more sci-fi than I intended and much less magical so others could make suggest how they want to bring the magic back if need be. I just followed where my decisions seemed to take me. I tried to throw a few things together so they at least made some sort of sense to me so I could reach an end point with the doc, but if we want to bring things back to purer fantasy or something completely different then fine. I think we are still in a place where we could change things.

I'd done a bit more work on the doc but it wouldn't stop you starting something. I will upload what I have in a few minutes (as soon as I can) whether there were a few bits undone or not... The doc is actually on Google Docs so editable if people had wanted to through I'm not sure how things get resolved if 2 people work on a doc at once. Will post back here in few mins.

OK thanks for the initial comment. Yeah....no tutorial at all to be started initially and perhaps nothing much at all ever (just screen text or whatever). Some things in the doc are just added so we can reject (or reject initially). That would be the right thing to do. I see this as the main purpose of the doc really. If people reject things from the doc in favour of something else then I'd consider that a success. I think most of the stuff in the doc could be flipped over to some sort of fantasy medieval equivalent if that was everyone's wish. There seem to be about 4 people appearing with regularity in the forums so if we have a good set of level ideas weapons and mechanics then I think we should be in a good position to pick things (or choose our own) to implement for 3-4 initial prototype sub-level areas as a next main step. Had a night off from the doc. Will likely finish it up tonight.

I'm aware that if we tried to do what is in this doc we would almost certainly not get it done by Christmas and would probably take maybe 3 months after that to do things very well. Currently I assume we're still just aiming for a rough prototype of 3 or 4 cut down sections of anything in this doc, or what others add in the later revisions and then we see where we go from there.

004(Forth) - Game Design Document-v0.0.1-PRE-RELEASE-DRAFT-WILL-CHANGE.pdf First EARLY INCOMPLETE VERSION. A few notes of warning: This doc is not yet complete(!!!) I'm releasing it now so that there may be some feedback before the weekend (and because I said I would try to). BUT - I may also choose to avoid reading any feedback until I have completed the document. so that I do not get derailed in where I was heading. I'd rather get to the end, then throw stuff away than get de-railled and get confused before getting to the end. Things are more sci-fi than might have been the case before but in order to get something consistent I'm trying to join up the dots and those dots are coming out more sci-fi-coloured....than fantasy-coloured.....in my head anyway. Many things are merely suggestions. Rather than keep saying 'possibly this' and 'possibly that' I'm just saying it though it may be something that I feel extremely unlikely or a poor choice for us to actually try and do in any first solid try at the game. Comments are welcomed but any comments that are offered may be superseded by whatever I end up doing to the final doc and may need incorporating in the next version. I'm still working through detailed versions of the levels so they are in a state of flux right now and not supposed to be concrete suggestions of 'we MUST have this level' I've neglected gameplay mechanics a bit still. I tried to go through the forum but I couldn't easily find somethings I thought I'd seen. I think I've missed a number of interesting things that were said so people will probably need to point me to them or suggest them again. I've started toying with the idea of the number '004' being a possible minor detail in the game. It's not really meant to be a name change or anything though I'm still confused as to how Fourth seemed to become Forth so I thought it funny that there's now a third variation of '004'. Some parts of the doc may be inconsistent with each other as I may be still rewriting sections over old ones. I have other ideas that are not added in yet. I may yet add them in may just keep the doc more cut down to just a single 'first chapter'. Remember...I may totally avoid reading any comments till I've finished my ongoing pass through the doc but please feel free to comment and then I may step on to incorporating any comments in after I've finished my first pass for the next published version. The document is getting pretty long but it's been fun thinking it through so far so I'm not too concerned if it ends up not being that useful or off-track for what we do. Might have the more complete version by the end of tomorrow, or certainly some time over the weekend.

Getting near the end of the doc now. I expect to have it done by the end of tomorrow. The first version may well just be the start and I'm sure won't reflect exactly what has been said on the forums. In the end it more than likely closely resembles my own thoughts more than others so others will have to assist in pulling it back in their preferred direction by raising comments (probably in the forum) and we can revise from there. After only a few days it will of course be only a set of rough ideas and there will likely be many issues as you'd expect in a hastily written document born in a soup of various peoples ideas. I expect I should have a version tomorrow with the only thing stopping me publishing probably would be that I might feel another days thought makes it easier and clearer to understand. I'll aim for tomorrow (night - UK). Current Table of Contents Looks like this...

I see Mulaka as an interesting game that could be a useful example to base some mechanics of our game from (potentially). There is a book in a book bundle at Story Bundle that retells the path of it's development. The books in these bundles are usually pretty good. 15 dollars gets you 11 books. The Mulaka one is only in the bonus tier. https://storybundle.com/games An interesting quote from the book..... Let's not be Edgar and his team! Developing a game is hard. Particularly 3D. So many bits to bring together. I think we can do it!

I think that initially we should to make a game as if it was 'chapter 1'. I think for the initial draft of the doc I will think of it like that. The other way would have been to try to plan out a full story arc and then we only pick to implement some of it. Perhaps start middle end but I think better to have our start, middle and end as only the start of something bigger. I think we should not give too much away even otherwise I think we're going to get hung up on backstory and story arc and people probably having different opinions on it. If we meet a boss character then we should not necessarily try to make it a final boss but think of it more as a chapter end boss. I don't know if anyone has actually implemented a decent boss fight in a game but I see this as a major hurdle. Personally I think I'd be find with a game that didn't conclude in a boss fight. I may mention it in the draft doc but I REALLY REALLY REALLY think we have to prove we can deliver even a SINGLE decent area that we ourselves want to play before we get hung up on the bigger picture. I think we do not worry too much about a boss fight until we have something very good in place. If the bits before the boss fight aren't engaging then nobody is going to get to the boss fight.

Yeah this set seemed about minimal to get some sort of progression through a few areas. The areas would not be the size indicated, and might be contain none of the screenshot concept in the end. It is more to indicate theme. I think only about 3-4 sub areas should be worked on to start with so new levels can be suggested and put in doc but we probably need to choose 3-4 to work on. If we actually get 1 or 2 done fast and progress is good then maybe we expand a list quickly but until we get ANY done I don't see any point committing to a long list. I would say these sub-levels should be rapidly built out CSG based levels (not 3D software) plus simple objects (ideally just CSG to avoid tinkering on models) plus scripts. CSG objects mean the level is accessible for all should someone go off radar. If someone ever works on what should be someone elses level then they should work on a copy and in general this should be avoided but due to communications I think waiting for someone to respond before you can try an idea out is probably not the way to go. If someone wants to go 3D software for level design then fair enough as something done is better than something not but they should bear in mind that having a half done level in some software that requires a license is not a good thing and not accessible for someone not competent with that software or 3D modelling in general. I was thinking that people could pick an area and do what they want with it and that each area would probably have a slightly different mechanic that may be implemented there (before other areas). E.g. a deserted village might contain some documents to read for background or quest info so need a 'view document' function and perhaps which we may choose to implement here . We can probably set up a vote on sub areas and mechanics and people can pick an area and mechanic to work on perhaps. When I get this design doc draft done (hopefully tonight or tomorrow ) then we can consider more how to proceed.

Nice... so looks like third person controller may be back on as a possibility. Do you think you will be able to get this working effectively with the TP controller or would you prefer someone else to?

I am hoping to have a first release of the design doc tomorrow. I will then probably add in some more detail after that if it makes sense. As part of this I've been considering some possible levels and wanted a little screenshot of what I meant for the doc so I've gone ahead and rapidly thrown together a number of small prototype maps in Leadwerks. Not in repo yet. These will just be the absolute minimum in presenting the level but could possible be used as a start point to prototype the mechanics before putting in place a larger more complex and complete version and integrating this into the terrain. So these areas may well be integrated finally into only 2 or 3 larger island maps but for prototyping I think the areas should be kept separate so there there is more choice to work on without having to work on same files and also so it loads quick and also screen clutter is minimal. Current prototype maps....3 need to be implemented yet. The others are roughed in. Some prototype maps.... Crypt exit/excavation site. Cliff traversal to air-ship station. air-ship station departure.

YEEEEEEEAH that's it! 50K one works fine now. It turns out that you MUST do the SCALE and then COLLAPSE. Collapse first then scale and it doesn't work. Seems like a bug, in the very least not informing the user if it encounters a problem. MANY MANY THANKS! .