Dreams Of A Game Designer

General overview

Different tools, not a seamless interface.
Brick by brick building with no higher level control.
Long compile times, long wait before previews.
Complicated setup/configuration of tools.
Only way to test triggers (audio etc) and other kinds of strange logic is in-game after compilation.
Not easy to create new things in the game editors (can not edit geometry and such).

Group things into sets, mix-and-match with some variability control (a tree for example made of trunk etc and different trees have different height and some other variations).
An in-game editor should have several different views of the game (from the point of view of a guy walking around, from top down, isometric etc)
Macros and other scriting things (like mel) for batch creation etc.
Easy sharing of assets. Importing things from other files and possibly referencing.
Creating wizards for components and other things.
Low level interface which is very similar to programming the components, only in a scripting language. A lot of flexibility for people who know how to use it. Wizard for people who are not so technical but still want the flexibility.
Single admin client.
Creating components "in-place" while creating new objects. Possibly a single interface or otherwise very seamless.

Working inside the client is nice for touchups, but general content creation should be in an external editor.
Streamlined and automated workflow needed.
Choose a default definition (template or existing object) and add pieces to it.
A lot of the complexity should be handled in the tools, while the actual low level interface would be rather simple and quite technical. The implementation should contain only enough stuff to allow for things that need to be done in-game.

Logic is mostly specified as reactions of the object to a given event.
The same reaction could be used for several events.
Actions mostly consists of two types of logic components.
1. Reaction to the event on the object being acted on.
2. Action of the actor that creates the event.
Inheritance and overriding actions are important. So that logic does not have to be separately specified for everything and can be generalized for base types, while still being able to specify a different logic for special cases.
Inheritance and such could work by having templates that are referenced rather than just used as a base.
Could have a Maya Hypershade like interface for creating new logic components.
Everything should be able to be utilized not only as scripts and such, but also as compiled C++.
Should be a way to compile smaller components into larger ones for optimization purposes.
Component grouping, templates and such is very important for reusability.

Separate data components (data domains), however created as part of the logic components, since they are usually connected.
Data components have their own logic that deals with calculating output attributes.
Data components also deal with data propagation (dirty propagation, lazy loading).

Different types of views that are related.
- The server has views to access data in a non-standard way (perception of energy level, weight etc).
- The client has views that actually display data and have a GUI.
Views are components...sorta.
Some sort of a way to figure out if a view can be attached to a given object or not (probably part of the view logic, that checks if a certain data component exists).