Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Einlander

Members
  • Content Count

    778
  • Joined

  • Last visited

Community Reputation

282 Excellent

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

21,539 profile views
  1. Einlander

    SIEGE

  2. Einlander

    Untitled

  3. Very simple breakable wall script.
  4. A short demo game i'm making for the steam workshop. Everything you see on screen can be found in the workshop, except for the arms, gun and the monster. Those can be found inside the editor.
  5. The platform tutorial level so far. No sounds for anything except moving platforms.
  6. Just showing some mechanics of one of the projects I'm working on. It needs more sound effects and some of the platforms need texturing. A few puzzle rooms will be added and it will be released for the Leadwerks Game Player.
  7. Could this be the article you were looking for? http://www.realtimerendering.com/resources/RTNews/html/rtnews1a.html#art4
  8. Einlander

    Bindless Textures

    How does it compare if at all to the ID, Rage/ Ubisoft, Far Cry / Dice implementations of Megatextures/Adaptive Virtual Textures ? Various Videos from the implimentors.
  9. Einlander

    Fun with JSON

    Don't forget a plug-in script/json should have a version property. It helps when updating scripts and making sure multiple scripts are interoperable with each other.
  10. Does it need to be in the Script namespace? Can you add a separate EditorWidget namespace or something?. This should allow you to create a plugin manager. And then you can have the plugins tell the editor about itself ie: EditorWidget.name = "Calender Widget" EditorWidget.about = "Lets player Select a date from a calendar" EditorWidget.author = "hacker Man" EditorWidget.version = "1.0" The only issue with this is if the game needs to use a feature from the plugin. For example, check if the day is a Tuesday. Would the editor script be available to the game at runtime?
  11. Using text for the interface is a good idea. I think you may have the system properties and custom interface thing mostly solved. Nope, everything that I can think of is hypothetical atm. The only thing that I would do is place every interface into a separate container and stack those. That way a custom interface will know that it needs to fit in the containers bounds. Currently I'm just thinking ahead to potentially more advanced input. Such as a curves/path widget as seen in the Emitter properties, Or even a calendar widget to input dates for days easter-eggs show up. Nothing act
  12. Something I did not cover in the last post, because I forgot about it: Methods to get the chosen values from the script properties. There would need to be a standardized way to get the values that were set. First the choice would need to be created at runtime. To access it you can have either: 1. A universal variable that you can always expect to have the value ie: chosenValue = Entity._scriptProperties.myEditChoice.Value 2. A specific variable per each property type ie: chosenPathValue = Entity._scriptProperties.myPath.SelectedPath chosenChoiceValue = Entity._scriptPropertie
  13. Just a suggestion/request. I am not part of the Turbo Engine /Leadwerks Next beta, but would it be possible to change the way Script Properties work? Currently Leadwerks Handles the Script properties with hints comments as seen here: Entity.myPath = "" --path "File location" "Texture File (*tex):tex|Texture" Entity.myChoice = 1 --choice "Choice list" "Monster, Zombie, Alien" Entity.myEditChoice = "Monster" --choiceedit "Choice list" "Monster, Zombie, Alien" Entity.myEntity = nil --entity "Some entity Would it be possible to change it to a more programmatic method such as t
×
×
  • Create New...