mdgunn

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.

There seem to be roughly 3 things coming up 1) Fighting enemies (aiaf/mdgunn/thirsty panther) 2) Environmental puzzle mechanics (mdgunn) 3) Environmental management mechanics related to attack defense of island resources or player position/situation (aiaf). I will put some another update (maybe few mins) with some issues that I can put on the BB issue list. I will start with Enemy Fighting first as this has been a common theme now and earlier but the other items are also interesting to begin considering which may help build a world and backstory beyond 'kill all enemies'.

I will have a think and get back in a bit, think I can see a few common things.

Some of these are very basic but used sparingly give some option for some variety. - Move statues/blocks onto pressure plates. - Climb cliffs/walls to reach new area or push down puzzle elements (exploring environment in detail to find puzzle solution). - Companion can retrieve some types of items that you cannot but can't just fetch anything so can't just make all puzzles easy. For example can only fetch metal items and would be usually placed on purpose in areas you can't reach so you can understand the solution from existing knowledge of this common solution. - Move blocks around floor which blocks in certain directions so correct solution is not obvious straight away. - Use flooding mechanics to raise lower water level and make puzzle solution possible. - Puzzle elements may float and provide floating platforms to reach other areas. - Light torches before the lit ones go out (timer puzzle). - Stop timed elements by using freeze spell but only one spell at a time for multiple elements (see God of War). - Companion can assist in battle but only if you defend it. - Companion (and you?) have switchable defense/attack mechanics that make more sense in certain situation. - Enemies are succeptable to different damage. - Enemy knowledge gained through scan by companion but is lengthy procedure so must be defended during battle (may accumulate over fights). - Later similar enemy types have additional strengths which must be scanned know what needs to be equipped to counter. - Enemies may have a behaviour phases where they suddenly gang up - May be phase in which companion drone/orb attacked specifically and must be defended from gang attack. - Charge up companion with major attack to make special enemies normally invulnerable vulnerable to attack. For puzzles which may be subject to physics (if the physics is not faked) we may need mechanism to reset items to start location.

Good job with the suggestions. They seem focused and practical. I will to generate some as well.

For now I think we may be able to hold of on actual implementation and focus on nomination. We just need a list of small things that people think might be interesting in a game. NOTE: For multiple suggestions the mechanics/features they don't have to be something that would work all together in the same game. Could be suggestions based in completely different genres. They might be crazy suggestions too. Doesn't matter that much, just needs to be borne in mind that they may not make final cut if they are not practical but better to have the suggestion there and assess it than nothing there at all. In the end we would likely select a small set to implement from the larger set. I also think that we would not have to stick with them through development. We only prototype the feature (after selection) and if it isn't adding to gameplay or conflicts with something else it gets de-emphasised or deleted and we move on with something else. If we don't get too far with this I could brain storm some mechanics/features and we vote on them.

Just to be clear I would see these as just ideas not commitments. Things people themselves would like to see in a game. Could be from another mainstream game or could be from a demo project you've prototyped in the past. It wouldn't mean we do all of them but currently I feel that it's difficult to begin any prototyping of game mechanics till we have some ideas of what people might want to see in place. And I mean gameplay mechanics not overarching gameplay systems. It might seem weird to do this when we don't know the game story is but I suggest it might be better to drive out a story when we have some idea what we might want to do mechanically in the game. If the game is mechanically boring then I don't think it matters what the story is but you CAN have an interesting game with almost, or actually, no story.

As you've identified with this post I think it will actually be almost impossible to move forwards in a sensible way until we have some ideas on the table. It could be people are reluctant to put forward their own view and are happy for others to take the lead. Maybe. Personally I'm all for using existing games and game mechanics in our own or some variation. I think if people could supply 1 or 2 things from existing games and stating which game then this would be a good start. First person to say Skyrim DIES! The suggestion should be a game MECHANIC. By which it should demonstrate a direct impact on gameplay and it's increasing it's fun/engagement not some general overarching game system such as a skill tree. Whilst any suggestion would be welcome personally I'd be happiest to see suggestions that the nominators things they could deliver themselves or is pretty confident a team member could. Ideally the nominator would be confident they could deliver a prototype version of that feature in a week or less (not final, prototype). I'm not saying it HAS to be this way but at the end of the day someone has to code it or it doesn't exist and there is no game. That's the reality. In general I think a good example would be the sort of simplistic mechanics seen in a game such as ICO. Fighting simplistic simple enemies, box puzzles, torch puzzles etc. Some might find this very dated and boring, but again I say.....we have to implement what we suggest, keep it simple. I strongly reckon we could bring some of the mechanics of ICO in a limited form of a few small levels and have something half decent.

I think I will have a go at either redoing the existing level into a TPS level and/or doing another level. I have never tried to do a TPS level so initially this is likely to be rubbish and need to be thrown away. If anyone else has any more references to games that they think are useful influences for what a TPS version of our game might borrow from then please let me know.

Thanks for the reference. I'd heard about it a little from way back. I will add that to my mental picture. It is interesting that I saw a disgruntled user saying they have been playing this early access game for almost 3 years now. My worry is that we choose low poly to make graphics easier (isn't it?) but then we choose TPS which is often most often best displayed in multi-million dollar games with 3+ year time scale.

It should already be functional and do a map switch unless that is appearing to be broken in my check-in.

Although I think having a milestone of trying to get something working 'released' is good I don't necessarily think this needs to be a public release and in the state that I would probably get things in the next few days I think this is probably not yet the way to go. This is why I put it in commas usually when I say it. From my perspective I think I will not have the time to get it to the point that as an outsider I would want to spend much time investigating. Need at least a version 0.2 or even a 0.3. Best you could do for now might be some screen shots or show a few models but the value of that is probably limited. If we had some good operational mechanics then that may be more engaging to play with then maybe it might be interesting to show but with maps people are on MUCH better completed maps every time they launch any other game. With mechanics at least it may be something they haven't seen before. I have uploaded a slightly modified dungeon map with a teleport to an island with some props on it. It's not the same island as before but it is much lighter in resources which is what I wanted to test out. I would like to redo the other island as although it probably looked better it was words in other ways and am looking at ways still to produce islands in different shapes and balanced with resource usage. Should be checked in now. dungeon map is set as start.map and it leads on to island1.map both in root of maps. I will need to tidy up a few test maps soon I think. NOTE: I don't think the published EXE is working for me. I'd kinda assume that might not be my stuff and I'm not sure whey the exe doesn't load. For now run start.map from editor I guess. I also did a hack job on a FP hand to get a feel for maybe the start of having character weapon or item. This could equally well be something a third person controller has but for now it is easier for me to start from FP controller where it can use some existing LW mechanisms and scripts. It is totally not complete. The idea thematically was that this device comes down with the cube and latches onto the hand of our character/guardian/whatever. It can act like a wand or whatever or maybe augements to do different things, but I wanted to avoid the pure cliche of a classic wizard wand. The thing on the hand wasn't modelled for this purpose so yes it probably looks really bad but hopefully the suggestion is there for a possible direction to pursue should we want to.

About Third Person Controller: I don't really have a preference of First Person or Third Person though I see 3rd person as more of a risk which given the difficulties of getting ANY project successfully to the end has to be taken seriously. There is a balance of things and too many things on one side of the scales and the project fails. To me it's kinda as simple as that. 3rd person has some notorious issues that have plagued games for years and still do so I think we need to be quite sure as soon as possible that we are happy with our third person controller and the work required (character animations etc) if we are to pursue it. If this may take some time then is it the best time spent of that person in getting the project closer to finished? It MAY be if we have a few people that have experience doing 3rd person camera then we are OK. Even doing first person game has quite large risk compared to something like a simple abstract arcade game that might have only one screen and a couple of mechanics but I think we decided FP or TP environment so that people could work on isolated maps. I'd be really happy to see a super solid 3rd person controller for Leadwerks but I think we need to prove it's solid as soon as we can. It's true the map looks FPS-centric in the end but I think you could probably move some things about and it not be. Partly I was trying to get some brushes together to help do other levels more quickly and I don't think they are particularly FPS centric (suppose I could be wrong). My experience is more first person when trying to do LW games so given that we needed something fairly quickly I try to do something passable in FP than something more unknown to me in 3rd person. Maybe someone can do a more 3rd person map map then we can compare them both and move forwards from there . Maybe it's just a case of rearranging existing one, it's just brushes not 3D model, which of course is why I did it in brushes. If someone is having problems with the map I can help. At the minute I'm assuming it loads OK but for all I know prefabs don't load cause I missed adding something to git or something. As I've said before I think we probably need to focus on determining some interesting game mechanics that drive the game and then that might suggest which controller we need. What might help me is if people can suggest some examples of good third person controller on a small project team (1 person of few person). For me many console games with third person choose it for reasons which would be a DISASTER for us having excellent well animated characters within lush environments and strong story. Maybe someone can suggest some games so I can see in my head that we can make a leap to having a 3ps controller like game X that you name. In case of Atlas Cube in my mind I could see that FP game as being something doable, as far as it's environments and presentations (at least in a simple form).

No problem. I might face the same thing later on. Maybe you'll have more time later when the path is also a little clearer but also some polishing to be done. In the mean-time, focus on what you need to do. Cheers!

Thanks. Could be there are other things that can be done. I think I saw some discussion recently about avoiding clipping with the cameras and the FPS has some code for smoothing out movement when you're falling jumping so maybe there are solutions. Third person always seemed like it could be tricky to get working really well. We'll see. Nice to have some options at the start.

A good part of this relates to things I've been involved with so I will look at tying these together a bit more into something for a 'release'. I haven't tried to get the 3rd person controller working in the dungeon. Not sure it is ready to perform in that environment but I could give it a go, or if the map is loading up OK for Slas he could see how it performs there and we can establish the suitability for this FPS orientated environment for 3rd person. I will aim to tie up what I can from my side for a 'release' version within a few days. Should be before the weekend. Maybe something by Wed/Thurs. Unsure where gamecreator got to with any island work but I will continue to use mine for now.

Added the proposed start map to the repo along with the building brush pack. map is here. forth\AddOns\MDG Modular Building Pack\Maps\example1.map

Uploaded the Brush Building pack to the repo. Probably not ready for use but there in case anyone wants to comment. Some things are certainly still in progress so if something is confusing, might be because not tidied up yet. Here's what the building pack is looking like so far.

In the model editor you should reselect the correct material to make sure it is set up for the Simple/low_poly_palete.png material If still problems then it's probably that Blender might not have fully been setup to setup the material texture against the UVs. If you can see the model in blender with the right colour on faces then it is should be mapped correctly. See the image below of your model showing the colours and little uv'd faces on the low poly texure on the UV/Image view. Maybe check over the texture settings on the right, below making sure mapping is set to UV not generated. If you are in cycles then probably a bit different. Here is the model 'detector_mdg_test' in leadwerks after reselecting materials/simple/low_poly_palette.png You can delete the detector_MDG_TEST files when you are done with them when you want.