Recent Development Activity


Highlights
Comments Only
All Activity

Friday, September 25, 2020

jeff 
 

New Task Created!

Refactor the UI theme system by implementing a temporary "Theme2" class. Windows+widget combinations with Theme2 set will have access to a new UI rendering path that replaces the WindowDecorator system with theme-controlled rendering steps/layers. The new theme system should support: - "Point" based font sizes - Theme Values, value references, and value overrides on both windows and widgets. (Primarily for custom colorized window, may have other applications) - RenderSteps allow themes to specify and control layers before and after the Widget::draw() and Widget::drawChildren() functions. - Styles allow a theme to define multiple styles for a widget - States allow a theme to alter how a widget renders across multiple states (Window Active or Inactive, Button up or down, etc.) This eliminates the need for Borders to define multiple states. The idea is that all UI elements should continue to render with their existing theme, and new Theme2 files can be developed and widgets can be improved without stopping all other development or requiring a branch.
jeff 
 
Status changed from
In Progress
to
Complete
Reason:A new size and triangle count has been been determined.
jeff 
 

New Task Created!

The way network communications are currently implemented makes it easy to prototype, but is hardly efficient, and often encounters issues due to being based on the TCP protocol. Build a new network model based on UDP, with more options for reliable an unreliable packet delivery. Return to using a serializable Packet class in place of the current "binary JSON" approach to reduce packet size.
jeff 
 
Priority changed from
4
 Low to
X
 Blocking
Reason:This is blocking progress on rebasing SimulationObjectInstance onto SceneObject.
jeff 
 

New Task Created!

Currently SimulationObjectInstance has several functions into which a ServerSimulationFunctions or ClientSimulationFunctions class must be provided. This class will never change after activation, so it makes sense to have the instance simply store a reference to this class and clean up all the function calls that reference it. The instance should also provide access to these classes as it is really the component classes that make use of these features. Consider this change carefully - are we really cleaning things up or are we sewing confusion? Is there a better way to provide access to these functions without needing to pass a reference around?
jeff 
 
Priority changed from
X
 Blocking to
X
 Blocking
Reason:This is blocking progress on rebasing SimulationObjectInstance onto SceneObject.
jeff 
 
Priority changed from
4
 Low to
X
 Blocking
Reason:This is blocking progress on rebasing SimulationObjectInstance onto SceneObject.
jeff 
 

New Task Created!

Currently SimulationObjectComponent has numerous functions into which the SimulationObjectInstance is passed as a parameter. This is an artifact from the MMO implementation where components were members of the /template/ and did not store their own values. It would reduce complexity and clutter to have the SimulationObjectComponent simply store a reference to the SimulationObjectInstance that owns it.
jeff 
 
Priority changed from
4
 Low to
X
 Blocking
Reason:This is blocking progress on rebasing SimulationObjectInstance onto SceneObject.
jeff 
 

New Task Created!

The SimulationObjectInstance is using InstrospectionObject to try to automate value changes across server & client. While at first glance this functionality is convenient, it would be a better practice to use InstrospectionObject /*only*/ for editors, and to stop using it as an easy way to set values in C++ code.
jeff 
 
Priority changed from
4
 Low to
X
 Blocking
jeff 
 

New Task Created!

Currently the SimulationObjectIntance class holds a static list of all templates, which is pre-populated on loading. This is not the typical way ToiEngine handles references within resources, and is causing some ugly code in places like the editor where the templates are not loaded in advance. Refactor this to work in a more standard way. We can still cache the templates for both the client and server, but we should be doing that in a manner similar to how we cache other resources (such as shaders).

Monday, September 21, 2020

jeff 
 
Priority changed from
4
 Low to
X
 Blocking
jeff 
 

New Task Created!

Currently character movement is limited and the controls do not feel good. - Evaluate the current implementation and how it could be improved - Make better use of the MovementMode base class - Add a 'sprint' movement mode that requires a skill card - Fix gravity - Fix the "fixed update" function that ensures jumping response correctly - Improve the jumping controls - Improve the way the character turns around - Consider adding a temporary 'swim' mode with a temporary animation
jeff 
 

New Task Created!

Refactor the 3D hotbar with a more manageable 2D hotbar based on ToiGUI. The Hotbar will need: - 2 Center slots for right and left hand equipment - 3 slots to the left and right of each hand for associated techniques - 4 "generic" slots for actions and inventory items on the right - 4 "active effect" slots for equipping passive effects - Status graphs for: - Health - Energy - Food - Armor Status ? Eventually we would like to support multiple hotbars, but that is not a requirement for this release.
jeff 
 

New Task Created!

Implement a new UI for interacting with "container" Simulation objects such as crates, barrels, chests, and other furniture. The UI will need sections for: - Player Inventory - Container Inventory - Selection Information - Money
jeff 
 

New Task Created!

The current experimental 3D inventory is creating more problems than it solves. To simplify the project while improving the inventory it has been decided that we will return to a conventional 2D inventory and hotbar. This will reduce overall complexity and keep the UI more consistent. - Ensure all SimulationObjects that appear in the Inventory have an inventory icon - Implement a new Inventory GameMode. - Layout the new inventory with the following sections: - Character Equipment - Character Inventory - Money - Selection Information - Hotbar Some recent game design decisions that factor into this include: 1. Inventory will be limited by weight, not by a fixed number of slots. 2. The inventory UI will scroll vertically. The size of inventory and containers should be implemented in way that allows it to be relatively endless, or at least very large in the case of buildings. The player should be able to easily move an item across the full scope of the scrolling inventory. 3. The player can create "trays" to organize their inventory in. The trays serve as an organizational tool, but can also be moved all at once into free-standing containers. Clothing and armor might have a special "mannequin" tray that can be dropped onto the player to immediately change armor/clothing. 4. Items will have a "Slot Size" and can only be placed in appropriately shaped slot. The slot shapes will be "standard", "large", or "long". The inventory will display in the order of: First Trays, then "long" items (weapons/tools), then "standard" items, and last "large" items. (Future slot types may also be added, such as "aquarium" slots that keep fish alive, etc.) 5. Slots can be set up with "tags" which act as AI behavior indicators. For example a slot in a character's inventory or a free-standing container could be reserved or stocked with a particular item. Or it can be set up to indicate that whatever is placed there should be kept, discarded, or sold. 6. The Inventory UI will have an area reserved on the screen for displaying a 3D preview of the item and basic information about it. 7. The Inventory UI will also have an area reserved on the screen for displaying either a 3D preview of the character and changing equipment, or when accessing a free-standing container the contents of that container.
jeff 
 

New Task Created!

City buildings should be visible from a greater distance than our current solution allows. - Implement a system for rendering a texture palette based on wall, floor, ceiling, and roof styles when exporting a Building Theme - Implement a system for rendering a building as simple quads utilizing the building style texture palette as a low LOD solution
jeff 
 

New Task Created!

Consider if the "snap point" system on Scenery should be made into a generic feature for all SceneObjects including Simulation Objects. - Create new tasks as appropriate
jeff 
 

New Task Created!

Implement a generic system as part of Simulation Objects (or possibly SceneObject) that replaces the geometry of an object with a pre-rendered image. This will be used primarily for trees, but consider other scenarios where this could be used to improve the scene and speed up rendering (such as scenery).
Page: