Work Blog - JeffR

  • 1
  • 7
  • 8
  • 9
  • 10
  • 11
104 posts Page 11 of 11
SqHd
Posts: 55
Joined: Tue Apr 14, 2015 5:02 am
by SqHd » Fri Mar 10, 2017 3:44 am
@
User avatar
JeffR
: Btw, did you get the audio working with the RPG dialog?

Another feature on my wish list for that resource is NPCs that you can talk to that also have the ability to walk around or follow a path / nav.
JeffR
Steering Committee
Steering Committee
Posts: 646
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Mar 13, 2017 7:46 am
@
User avatar
SqHd
Not yet. It was pretty much a 'lets get this sucker working' first pass.

The good news is, because it's the module system and does some namespace function override trickery, you can just drop it in and it'll work with whatever AI is running, as per the video. The guard AI module implements their behavior, and the RPG dialog does the, well, RPG Dialog.

Obviously a more tightly implemented system would see different reactions between friendly and unfriendly AI, and more ideally a more custom AI thought solution so townsfolk will go to waypoints or whatnot to simulate a day-to-day. Not particularly hard behaviors to implement, but a bit past the scope of the initial 'lets see if this works at all' ;)

The longer term goal would be to hook both AI and the RPG Dialog stuff to the neat incoming Web/Node graph interface for doing up state machines. I think the RPG Dialog one would get a customized one for setting text for each dialog 'state', idle animations to play during them, yada yada. But the idea would be skipping out on any weird, complicated text interface and just being able to smash out a web graph tree for the dialog flow to make it lightning fast to make AI talk. It'd also be a good test for tools and custom editors that package in with a module, and finding out needs/wants to make that a super smooth system that's easy to use.

Same for AI behavior. Being able to slam out an AI state machine in a short time with a visual interface and drop it on a guy and they just GO would drasticaly simplify the workflow on that end as well.

Meanwhile, took about 2 hours before bed tonight to jam on something that's been annoying me for a bit:



Drag-and-Drop asset usage. In the video you see shape assets being D-n-D'd onto the main editor view to spawn an Entity with the mesh component, and the Shape Asset field on the mesh component on an entity in the inspector to assign the shape there as well.
Obviously pretty rough-cut, but the idea proved pretty simple to get basics working. The ideal would also see materials/images being able to be dropped on anything with a valid rendering component, and - via raycast testing to find the contact surface - able to quickly drop a material onto an object's surface in the editor view to apply the material to a mesh. Or obviously drop it onto the material inspector field to apply for cases where it may be harder to hit the right surface, or want of explicit control. Sorta like a reverse eyedropper.
This, and my talk of a Live-Tutorial mode really have me itching to implement a means to highlight gui controls with an outline or whatnot via arbitrary means. Being able to outline the ShapeAsset fields in the inspector or whatever else is a valid receiving target for this sort of thing would be a nice bit of polish that is a great bit of convenience.
Also want to have 'live dragging' in the case of the main editor view, so you can drag-and-place a mesh in one smooth action, instead of HAVING to drop and then move. Minor deal, but it would remove clicks from the editing process, which is always nice.

Also thinking of doing it for component assets onto the inspector with a selected entity to quickly add it to that entity, and other obvious ones like dropping a sound asset into the main view plops down a sound emitter, particles drop particles, etc, etc.

Because behavior like 'spawn static shape' can infer a lot of things to a lot of people, I'm thinking we'll want some kind of config for dictating what would be the spawning behavior in the video's example case. Some obvious components are, well, obvious, like the Mesh Component, and a Collision Component. Some things could be inferred from the inbound asset, like if the mesh has animations associated to it, add an Animation Component, but from there, interests may diverge project-to-project, or just what stage of editing the map.

So having some editor setting to assign a GameObject for what to spawn may be a useful means of overriding with custom behavior if needbe, or whatnot. Something to mull on.

Besides that, been drafting up some initial documentation for the wiki on getting started with the new Base Game template, and also some docs on how to convert existing projects, as well as looking at beginning to port my writings on modules/assets to the wiki to better consolidate. Hoping to get that up tomorrow, but it's a fair bit to write and document with images and the like. so we'll see.
JeffR
Steering Committee
Steering Committee
Posts: 646
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Mar 16, 2017 6:06 am
Been crunching on documentation for the BaseGame template - both starting a new project with it or converting an existing one - on the wiki.

There's a lot to cover, including documenting the modules and assets stuff in detail, so it's taking a bit, but you can scope out the in-progress work so far here:

http://wiki.torque3d.org/introduction:starting-with-the-basegame-template
http://wiki.torque3d.org/main:legacyprojects

Plan is to cover:
  • Creating a brand new project with the BaseGame template and a walkthrough of the directory layout
  • Dropping in an existing module to see how modules can interact and automatically load to bring content into your project
  • Creating a new module from scratch
  • Everything pertaining to the modules system
  • Everything pertaining to the assets system
  • Porting your existing project to the BaseGame template and what needs to be changed to bring it up to speed(this will also see updates as we shift to PBR, the Entity/Component system take over, and anything else that'll be revelvent to keeping your project up to date with major changes to help streamline the porting process)

As a fun aside, it broke at some point, so I need to fix it, but I'll have a contexted documentation pop-up entry in a lot of the RMB popup menus for 'Jump to Documentation'. The idea being that if you, say RMB click on a MeshComponent rollout in the inspector for an entity, or on a ImageAsset or what have you and click it, it'll jump straight to the wiki documentation detailing all the specifics for that particular thing.
Idea being to cut out as much manual searching and drudging through documentation as possible to jump you straight to what you need to know for the thing you're wondering about at the time.

This should help immensely with the learning process, and remembering details/functionality on things you don't often utilize.
Chelaru
Posts: 174
Joined: Wed Jul 01, 2015 10:33 am
by Chelaru » Thu Mar 16, 2017 3:53 pm
The part with the jump to wiki documentation will be nice.
  • 1
  • 7
  • 8
  • 9
  • 10
  • 11
104 posts Page 11 of 11

Who is online

Users browsing this forum: No registered users and 1 guest