Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Inventing on Principle

  1. #1
    PGDCE Developer Carver413's Avatar
    Join Date
    Jun 2010
    Location
    Spokane,WA,Usa
    Posts
    206

    Inventing on Principle

    Great video, I would like to implement some of these Ideas in my own code
    http://vimeo.com/36579366


    Last edited by WILL; 26-02-2012 at 02:10 AM. Reason: Embed, embed, embed! :)

  2. #2
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    He has some interesting ideas. I would be nice to have game development tools that act and behave much more like this than the completely separated code vs. concept approach that we usually start with.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  3. #3
    PGDCE Developer Carver413's Avatar
    Join Date
    Jun 2010
    Location
    Spokane,WA,Usa
    Posts
    206
    the framework I'm building has scripting built into the core so you can bet I'll be playing around with a few of these Ideas.

  4. #4
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    If you could create a game using a sort of 'Hypercard' type of design work for scenes, that would be awesome.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  5. #5

  6. #6
    PGDCE Developer Carver413's Avatar
    Join Date
    Jun 2010
    Location
    Spokane,WA,Usa
    Posts
    206
    Nice work Eric

  7. #7
    The video is a nice demonstration of an extremely good implementation of data driven approach. Where the data is the code.
    When I worked on particle effects for one of my games, the particles were driven by a script and I was able to change the behaviour in real time modifying the script within the game editor. This way I got very nice effects in very short time.
    This is the reason why I think that a game engine should be built with a data-driven architecture an should have an editor with WYSIWYG capabilities.

  8. #8
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Hey great proof of concept Eric!

    I'm still wondering however if this can be applied to an OpenGL or DirectX environment. Mistakes, as you've mentioned in the post on your site, can happen and with an environment such as 3D/2D graphics processing could cause your system to suddenly slow to a crawl. Especially if it's an older or lower spec system.

    I still like where this is going and would love to se more pick-up of the idea. Maybe a serious game engine or design tool of some kind?
    Jason McMillen
    Pascal Game Development
    Co-Founder





  9. #9
    Quote Originally Posted by WILL View Post
    Mistakes, as you've mentioned in the post on your site, can happen and with an environment such as 3D/2D graphics processing could cause your system to suddenly slow to a crawl. Especially if it's an older or lower spec system.
    Indeed, all parts of the application you're testing have to be fault-tolerant (not to mention capable of getting restored from a known state in a quick and reliable fashion).

    DirectX & OpenGL are not very tolerant indeed, if you mess up you can quickly end up in a crawl, using all memory or cause a system crash.

    On the other end, this is an issue that is currently being worked on for the web-based 3D standards, because well, that's the main issue of WebGL (do a shader wrong, and the system will crawl/crash). So I guess it's only a matter of times before things evolve, there is a massive push in that direction from Apple & Google, and they arguably got a portion of 3D acceleration stable enough to be used in browser compositing (and the basic 3D stuff through CSS 3D).

    The most problematic stuff is the lack in DirectX/OpenGL of constraints, such as memory limits, fill-rate limits or shader execution time limits, but that's something that could technically be introduced in drivers.

    Another option could be a revival of fixed-functionality pipelines, but much richer than before, and where you would have all the common lighting and rendering techniques exposed.

    That's somewhat the direction taken by CSS, and it has merit as it shoves the low-level hardware-specific complexity back in the hands of the drivers and composition engines, which is certainly more future-proof than all of the existing shader approaches (a bump mapped phong lighting will always be a bump-mapped phong lighting, rather than the optimized-for-special-cases-of-bump-mapped-phong shaders you see these days, that f.i. don't scale with an arbitrary number of lights, handle only point lights or parallel lights, etc.).

  10. #10
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    I was thinking that perhaps if there was a way to omit executing the potentially crashing/dangerous code and maybe highlight it in red or something until it meets up with a safe set of parameters. How restrictive those would need to be and what to restrict and what is safe could be a cause for debate.

    I think in terms of OpenGL vs. DirectX some functions work well for this concept and some are more tricky to execute code in real-time. Perhaps for those tricky bits having some kind of special code block that won't execute until you close it would come in handy? This would prevent major mayhem when tweaking code that if done improperly or executed on the fly as you type would normally cause a ton of memory errors, etc...

    But perhaps we are taking the Inventing on Principle concept too literally by going right down to API level...
    Jason McMillen
    Pascal Game Development
    Co-Founder





Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •