Jump to content

mdgunn

Members
  • Posts

    626
  • Joined

  • Last visited

Everything posted by mdgunn

  1. 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'.
  2. I will have a think and get back in a bit, think I can see a few common things.
  3. 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.
  4. Good job with the suggestions. They seem focused and practical. I will to generate some as well.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. It should already be functional and do a map switch unless that is appearing to be broken in my check-in.
  11. 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.
  12. 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).
  13. 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!
  14. 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.
  15. 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.
  16. 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
  17. 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.
  18. 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.
  19. Should the portal hide a load and is on a different map or is it there for effect and in same map. If there is a portal does it not leave you not knowing where you came from and how the new place relates? The game may well have some intentional confusion so maybe the portal adds to it, or may just seem confusing to the player and not just the character. Questions, question. Sounds like we do enemies later...at least for now.
  20. Posted info on a test map in graphics section, though arguably it's maybe more related to progressing the design so posting a link here to.
  21. This was done partly to serve the BB task for 'Starting Dungeon' (https://bitbucket.org/alexandru_afrasinei/forth/issues/22/graphics-starting-dungeon) and partly to test the Brush Based Building Pack. It isn't really trying to be a dungeon but rather just a fairly generic environment, possibly underground (no windows!). At the start there is a loose hint of the meteor cube and a crypt object near each other as a crash site. The exit ramp at then end then could lead on to the island. I haven't yet uploaded the brush pack nor the map. Might need to tidy up a bit but it probably could be put up any time. Wouldn't recommend people rely on the brush pack at this early stage or re-work may be required. probably best I iron out any problems of use first but feedback would be welcome. NOTE: Video contains spoilers
  22. Have started on the CSG based (at least at first) modular building pack. The idea was to help people construct rooms quickly and hopefully with some degree of uniformity. For example common door heights, wall thickness, level heights - this could be nailed down through docs instead though so there are other options to get some common specs in place.. Currently I'm not sure how useful this brush pack is for others. I will probably use it myself as I quite like working with the limitations of brushes for prototypes so will probably take it forward a little more for myself at least. I suspect that most people are already comfortable with their own way of doing things (which is fine) and that this may well not be that useful. Still I'll probably do a test version and see if anyone thinks it will help. The prefab section allow rooms to be constructed rapidly around a central grid and also has some whole rooms and corridors like below. However, so far these are quite boring and generic looking (partly on purpose to get a simple room actually in place). Not sure if I will pursue whole room prefabs too much. Have yet to decide fully. The room below has been dropped in place of a single drag and drop action. Unfortunately it's not a very exciting room!
  23. Test scene for a meteor strike. I think this is going to take some time to get to a final state (audio queues, volume fades, impact effects, corrected particle effects, explosions etc.) and now probably isn't the time to do this. This is more a a cinematic test than anything else to see if something like this would be what we want before we finalise something like it..
  24. Not a final scene, though modified might have made a title sequence perhaps. Test scene for meteor and possible 'artifact of power'. This stuff not in repo yet.
  25. In general if you want something to have a colour you need to select those faces in a 3d program and shrink them right down so they fit in the tiny square. Shouldn't really matter how you've unwrapped it as long as it's located in the small square of the colour you want.
×
×
  • Create New...