mdgunn

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.

Working on missile launching and splash damage. Trying to keep things generic so player can also launch missile. Missile is a prefab so could be spell or whatever with life time etc.

In case the post I put in Design was not seen...I added a basic arena and an enemy that can be killed. Of course don't expect it to look amazing, as can be seen from the task list, getting something apparently simple like an AI enemy complete with FX and bone animation is significant work. Everything is just using the standard scripts for Monster_AI and FPS_Gun for now. Enemy can do idle, chase, attack and die. Currently the attack is a melee attack on player which seems odd for a tank thing but as it's not that important for now as it is just a starting point.

Added simple test arena, enemy model and prefab with only single idle animationHooked up to standard FPS controller and scripts for hadngun and enemy AI (copied to modified script - ready for modification). Enemies will pursue and you can kill them (they stop - no die animations yet). Added in a few more model items (health and potion) but these not hooked up yet. Map is Maps/Test/Arena/arena1.map See this topic for further info on how we came to start the enemy implementation.

Oh yeah 10 kill enemies is totally silly goal. It's just a placeholder to start things going but it is a defined end point and something to start considering how we might actually support goal conditions in the game starting from this most very basic of conditions.

Added another task for sound effects to BB. Not split it down into multiples right now but may be necessary. I have seen there are some added already (by Thirsty Panther I think). I have not checked if some of those cover those needed for enemy fighting so some may be catered for already and we may be able to just use some stand-ins from the FPS template at first. I think the ones below are correct but it may depend on final mechanisms we adopt. Enemy idle Enemy searching Enemy engaging player Enemy hurt with damage Sword attack Sword ricochet Sword hit/wound Sword Drawn Gun shot Gun ricochet Gun hit/wound Gun reload Gun drawn Missile launch Missile ricochet Missile hit/wound Missile reload Missile Launcher Drawn

I have created the tasks in BB and taken most of the modelling ones but I only intend to do very basic models in most cases and then someone can take further if want, or we just get on with other tasks. If anyone wants to do the modelling then we can discuss. It just seemed these not being there may hold things up and i think I can knock something out possibly by tomorrow for most.

Suggested New Enemy Fighting Tasks Though the following suggestions revolve around robots and therefore sci-fi I see these as potentially completely temporary if we want. In general I think we can move faster with hard surface modelling (like robots) then organic enemies. Maybe in a secondary phase or if others wish to pick up we can do a second organic set which may take longer. If people want to do organic now then fine too. Model Hoverbot Enemy Model that can carry 3 different weapons or have 3 different variants (sword/gun/missile launcher). This can be used to test melee combat, gun and area effect damage. 3D models of Sword, Gun, Missile Luncher for enemy (or player?) Implement melee attack of player on enemy with enemy damage. Implement gun attack of player on enemy with enemy damage. Implement missile attack of player on enemy with enemy damage. Implement melee, gun and missile attacks by enemy on player. Create health and mana models. Homing missile super basic model and script. Fireball missile based on basic homing missile may be mostly the look of the thing if the homing missile and area damage provide the mechanics. Implement energy on player controller. current and max limit. Random energy and health spawns of relevant models off dead enemies. Simple Arena level (indoor or out) with obstacles and some height changes that would be suitable for TP controller primarily and works with FPS too. Implement first basic goal condition. 10 enemies killed. Simple counter like health on TPS and/or FPS controller. May need to be more complex later. I think I may also do some additions to the brush kit for some arena or outdoor brushes. I think I can bash out some quick models for he modelling tasks listed to get us started. As I don't intend to spend long on that I think it would be fine if others wanted to submit models for these modelling items as long as they are OK that these may all be replaced by better versions later. Sound OK? Let me know if anyone wants different direction if you have time and wish to apply elsewhere.