Jump to content

YouGroove

Members
  • Posts

    4,978
  • Joined

  • Last visited

Posts posted by YouGroove

  1. You have a tendency to dismiss anything unique Leadwerks does, while continually asking me to copy other products.

    LE3 is going on it's own roadmap, im' not asking anything, the web player is just some sort of Unity Web Player with more possibilities.

    It was personnal opinions on two points , this has nothing to do with LE3 or 3D engines sleep.png

    - I was more talking as a player about another layer on top of steam for buying games : i manage all my games on Steam or have them in DVD, i don't like to have more multiple accounts lik Desura, GOG or others. So this is my personnal opinion only as player not as 3D engine user.

    - I was talking about strategy , the best time to show your game.

    Making games and exposing them too early is not perhaps the best strategy, could you make some game in LE3 or Unreal 4, if it plays **** and don't look good, you have more chances to not have people come back another time.

    While a polished demo will keep players come back to news about your game because they enjoyed the demo.

    This has nothing to do with 3D engines, it's more about your personnal strategy about when proposing a demo : in early stages or later.

     

    You can make some Desura site or anything else,i don't claim or ask anything, but i can give a personnal opinion, and perhaps the Player is the next big thing for LE3 and im' totally wrong.

    Don't take my personnal point of view too serioulsy rolleyes.gif , it's just another different point of view among billions people point of view.

    (This is why i must stay out of Hangouts laugh.png )

    • Upvote 1
  2. Main songs only come out when perfect in production, for sale to the public.

     

    It's like agmes, many people avoid Eraly Access because of unfinished product and some times when it's not a studio producing the game ,you don't get a lot better product at final or it takes ages to develop.

    Showing your game too early is showing potential big problems and bugs, not best graphics, not good sound , not so good gameplay.

    It can just make flee people from your game quickly also.

     

    That's why small studios make blogs instead of too early prorotype demos.

     

    For monetizing 3D assets , it's ok , because it's like Unity Asset Store, but monetizing games it will just won't work.

    Did you see Unity or Esenthel monetizing complete games in their stores ?

    • Upvote 1
  3. - If the game launcher does well, you'll (maybe) be able to publish, and monetize your games through the launcher.

    I don't think players will like the idea to have another launcher layer on top of steam to play some games. It complicates things.

    Players will expect to buy some indie game on Steam directly and have the game on the Steam list and launch the game fom Steam.

     

    If the plan is to make some another Desura games market places, but only for LE3, as it will be only few games i don't htink it's a good idea.

    Juts my two cents.

  4. I agree , but let's keep people have the choice to not use auto generated hitboxes.

    This way we can still manually add cube or capsule or our own custom model hitboxes and attach them to bones manually and adjust them as they are models we just added as child of a bone.

    Why custom :

    because of special cases : Ghost character monster where you need collision on torso and not on the floating clothing using bones also, or character parts that could not be hit like robot energy visual limbs using bones and many other custom uses etc ...

     

    But i understand the need in LE3 to simplfy the task for all new comers to game making and keeping character import as much simple as possible, for them automated collision is a must have.

     

    A capsule shape would be good for eliminating those outlying corners

    It's always valuable and good to look how it is done elsewhere, wink.png

  5. The only problem i see is for medieval precise FPS melee combat and FPS high zooming weapons,

    Seeing you should not hit the character and have in game the character hit by your weapon and players will quickly

    see the problem and think the game has bad collisions sad.png

     

    A big engine like Unreal 4 generates collision capsules per bones, but allow you to tweak and change them because they are never generated perfectly. Auto generation without ability to tweak is good only games that don't need precision like Dota or top down view games.

     

    For my LE3 sci fi game i will place manually HitBoxes to have character collision good and simple , so i think we can already place HitBoxes manually and in a better way then using some auto generated ones.

    LE3 should perhaps concentrate efforts in other areas after all.

    • Upvote 1
  6. Because it is more computing need to detect hitboxes and because we just need few essential hitboxes.

    I just want to be able to detect if firing hits a hand or some arm, i don't need hand fingers hitboxes.

    And it keeps things visually and also debugging in the game more clear and more simple.

     

    Why not when detecting bones on some imported model , let LE3 auto generate Hit Boxes for each bones and have some options like:

    - delete all hit boxes

    - delete selected hit box

    - create a new Hitbox for a selected bone

    - adjust hit box offset, scale and rotation

    This way anyone would have full control on the character hitboxes creation.

    • Upvote 1
  7. I agree with Eilander :

    We need lot less hitboxes than the character have bones.We don't need a hitbox per finger bone , also we don't need hit boxes per hair or face bones , or hitboxes on bones controlling some clothing parts.

    Some tool in the model editor to choose HitBoxes and visualize the bones will be needed in the future , specially because majority of games uses characters.

    Perhaps in LE4 some day laugh.png

  8. Some ideas for mobs:

    - AI attacking from distance firing some missile or fireball , able to move or teleport between when hit by the player

    - AI launching grenade like in a zone or to the player

    - traps, dangerous areas( poison or radioactive areas inflicting damage when you are in

    - weapons with poison/radioactive damage through time for a duration (melee, arrow)

    - AI moving randomly between some points or inside some area zone instead of patroling

    - AI dealing big damage shooting from distance or in melee, but turning slowly so the player have chances to avoid damage

    - fast AI running like dogs , light but fast attacks

    - AI running to the player and exploding when near the player

    - Flying AI ?

     

    For player :

    - strafe and fast rolling move

    -Grenade

    -Missile Homing

    - place traps using a weapon or some inventory item or a power : trap zone of poison that last some seconds, spikes etc ...

    - Impulse laser weapon : short firing time and big reload but heavy damage

     

    Quests :

    - follow and protect from point to another point

    - destroy all poison facility in some ennemy base

    - retrieve some item from some location

    - protect a base during some amount of time with ennemies spawning and around and attacking the base

     

    About the GUI, i would not include it, simply because LE3 don't have any official one and to keep your template very generic and usable for everyone without having to remove some GUI code and avoid GUI errors.

    Some way to manage your inventory could be simple vertical side tranparent rectangle and display real 3D object items on top of it, using keys to scroll up and down inventory and using basic text buttons to view, use, drop or sell your items.

    Invent%255B1%255D.png

     

     

    I would let down dialog ta this can become complex and it is even more dependent on GUI.

    For quest just have NPC display text and display "Y", "N" for accept or not the quest.

    I would keep it simple as possible and focus on portable gameplay and scripts instead.

     

     

    Good luck smile.png

    • Upvote 1
  9. I don't know. And it's even more complicated to manage then a team project already laugh.png

    You have lot more chances to finish a solid team project , than a community project wich many times never leads to a complete game.

    For people just toying or having fun making small code or models this is i think where a community project can be ineresting.

  10. People aren't getting paid to do a community project so their attention span will be very small and they will leave. If you can minimize the broad with a lot of responsibility type of jobs, then your chance for success is greater. What keeps a person on a project they aren't getting paid for and it's not THEIR idea? Nothing.

    Wise words Rick, specially because any participant will have it's own vision and ideas , and can leave any time to work in it's personnal game vision instead. I would say find good game ideas , a real project, then find some team mates and make it, it's perhaps better invested energy rolleyes.gif

     

    To interest people you must bring solid concepts and lay down some basic gameplay first, it will be more attractive like Unreal Tournament for ue4. For example if you plan some Halo style game, first bring on some basic gameplay, basic AI , basic driving car and a rought level map design.

    Having a playable prorotype i think will motivate lot more new comers. Then ask for participants to work on improvments :

    - better AI

    - follower or flying AI

    - more weapons

    - bridge model for the level

    - alien house asset

    - floor alien textures

    - sky

    - alien model

    - rigging and basic animations for some alien

    etc ...

    Coming with solid map concepts drawings, solid alien drawings, game ideas drawn down on paper ... I think this is the minimum base before asking any participation. Just my two cents laugh.png

    • Upvote 1
  11. I leraned it from Unity 2D rogue like tutorial, you manage a 2D array, each cell contain some model :

    -a room

    -a corridor

    - a corner etc ...

    Each model has different connection rules and directions( Up, Down, Left , RIght)

     

    You define a size for the dungeon and some parameters :

    1) connecting room probability (a room near another one)

    2) corridor connections probability (1,2,3 ... )

    3 ) corners probability ( 1,2,3 ...)

    And you start generation at center :

    - the more you get to border limits the more random probability of closing corridor or room is big. Also more probability for side level corridors.

    - when generation is done on last room it is some exit or a boss room.

     

    Each rooms and corridors will have doors, so only prefab tiles around the player will be loaded and detsroyed dynamically to keep a good framerate. Prefab tiles will have pivots for random placement of loot, monsters, lights, assets decoration.

    • Upvote 1
  12. I was talking about the offset we could need to keep.

     

    If i have in Blender a sphere model positionned at 10,10,10

    I would want after importing it in LE3 ,if i place the model in the scene at 0,0,0 , to have the sphere still at 10,10,10

     

    LE3 when importing a model recalculates the global center unfortunatelly.Having some option not not recalculate the object center could be usefull some times.

  13. Sometimes it can be useful to have the original position but in most cases it isn't it. An extra parameter for the Load command would suffice:

    Load("path", bool useOriginPosition)

     

     

    I got that case , and i would need the prefab to instanciate at original world offset position instead of having the prefab centered at position 0,0,0 as it is today. The main use is for using different 3D tiles and their management by code.

  14. If you add this to the script the problem goes away (but occlusion culling is disabled!):

     

    Hummm , not cool , we need occlusion. I think AMD Radeon cards have a different culling system. to not behave like Nvidia.

    This is not a big issue has choosing height = 0.5 or 1 for water and there is no more flickering, still some other Radeon users will encounter that flickering also if they use terrain and keep water height to a low value.

     

    The thread can be closed as there is no solution or have AMD submit a patch.

  15. Changing water height to 1 , and there is no more problem. The bug is only happenning with values like water height = 0.1

    whatever Camera range is.

     

    How to test :

    - Put water.map in your water directory

    - Put 3dPerson script in your base directory : "Scripts"

    - run the game and move camera up and down to see water disappearing

    water.zip

    post-3271-0-58541200-1428265898_thumb.jpg

×
×
  • Create New...