I'm not sure yet where the Array Standard fits into this yet. I just want to keep that idea in the forefront as it may play into the entire scheme.
This is something that I think we at CT want to contract out and fully develop if the prototypical ideas pan out. So, R&D is where we are at right now.
This idea does not just apply to city-style simulators. It should be flexible enough to be used for anything from active circuits to dungeons and dragons.
I have some ideas and criteria mapped-out now to the point where this is looking much more feasible and useful. Again, whether we have separate arrays that interact, or one object, is not the main issue right now.
Of course, we start with a grid concept. Initially, we are working in 2D, but ISO/orthagonal would be desirable. It seems that a grid is essential due to speed and memory requirements, and just how small the lowest division of the grid can be is an issue to contend with. I think that HWA might help this project simply because the graphic elements of the game may be more on the GPU side, leavng more headroom for this effort.
We will leave the basic setup for the array(s) until later. That is going to be related to the following concepts:
First we will have to consider various layers that can have various uses and meanings, but are defined in this way:
NOTE: These layers are pretty much being defined in their proper order, but that is subject to change. Some layers may be multi-level in themselves, so naming conventions here are merely for utility right now.
Background - Represents static elements of a game, (color, type, condition). You could place ground, water, mountains, etc., using this. Keep in mind that placing a body of water would be a 9-point affair, but dragging a mountain might be one large tile, (various size mountains) with 9-point edges.
Utility - This layer would be mostly functional with visual elements optional. It could be water, transit, electricity, circuit wiring, dungeon roads and paths, etc. Of all the layers, this is the most complex one and may require more than one level of "utility". This is, along with relationships to other layers, going to be where the meat of the programming happens. We still don't know about speed hit with all things considered, but the most optimal routines possible will be required to make this work.
Structures - This would be where mountains, any structural items are placed and handled. Since I don't know where to put "characters" yet, we won't assign them as they may be a layer of their own or even go in Automata. The difference between structures and backgrounds is height and function. Structure goes on top of background and has a logic layer of its own, e.g., buildings, generators, electronic components, etc.
Automata - This are visual elements that may represent conditions on the map. They would tend to include animations that play over and around structures. This could also be the layer for chracters, (player/CPU) but I am hesitant to finalize that because the logic and requirements may be different and need to be seperated for the sake of simplicity.
Atmosphere - This is your "sky". It could be clouds, planes, or elements that appear and function over elements in the other layers. So, to break out of a city framework, it could be a circuit path showing that the connection is functional.
Interface - This is where we handle selections of the grid. This is where the rules and graphical elements of selecting, placing, plopping, destroying, changing, is handled. One could drag a mouse, catch that condition and have a layer of objects with semi-transparency and indicative colors highlight the area dragged until release or an action changes that state. Inteface can also have an effect on other layers to change various states of objects in the defined area, (animation, destroy, etc.).
Interface should allow for the potential to hold a state or leave a selection. I refer to SimCity where you zone tiles. In this case, we want to "color" a certain type of background until something happens, like a structure growing there.
One other element of interface, (and this relates to all tiles as well) is that you need a way to choose directions for tiles based on their position. Let's imagine that you drag from one coordinate to another and there is a blue highlight over everything in that area. That usually looks rather stark without a border. That border, (or even mountain or water tiles) needs to be relational to place and position. I think it is clear that at the start of a drag from top-left to right bottom, there would be nine different tile styles to represent each part: four types of corners, four sides, and the rest would be a single filler tile.
That concept needs to be available in any layer applicable.
I want to keep this basic for now and I think the above is a good start. If the design takes these items into account, we could start with one layer and work on conditions, relationships, and complex details after we can visualize and therefore, think more about the next steps and how to make it as easy for the user as possible.
I think we should break it down into easily digestible chunks, keeping in mind during design, (programaticaly) that there will be relationships and interactivity between these layers.
Naming is going to be important. For instance, levels and layers are really already taken and to use them might be confusing. So, these layer types might need a better name. I think levels might work.
I was thinking that the Interface level might be a good place to start. To create a background using the 9-point tile, you really need to have a functional interface, first.
Well, that omits a lot that needs to be considered, but it looks like a practical starting basis to me. Once we have the Interface and Background levels worked out, the more complex levels, (like Structures and Utility) may start to take shape in our ideas.
We may need a graphic artist to create the tiles and other graphics for the prototypes, as well.
Does this make the idea more tangible? Does it stimulate ideas, both creative and technical? Is the larger potential for MMF2 clear in that we can all see where this goes for users as a powerful benefit for many types of games? Does it look flexible enough as defined so far to be used flexibly, or did I miss something, (Like Character level?)
Reply With Quote
Originally Posted by Novabrain, dumbed down
It depends on the context.
.
