mdgunn

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! .

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.