Array Standard

The vision and promise of MMF must move forward.

In the past there was talk about "smart arrays" and that was a good start.

We all know that arrays are, and have been, the basic workhorse for storing and retrieving data, internally, in most programs. They are the bread and butter of the business.

And so, we now have the idea of an extension array standard, staring us in the face, waiting to be inspected, considered and explored. There is much potential here for the future, and I think it may have a large payoff, in the end.

When somebody wants to see if any four objects of a certain kind/color match by proximity, what do they do? That is a common problem that users face. An array standard might allow for very creative and variable ways to solve that problem and make it easy to do for the end user.

This applies to simulations and other games as well. It might turn out to be very appropirate for applications as well.

Now that the idea is out in the open and is more than ready to be exploited and turned into yet another Clickable solution, we would benefit most from deep infusion of ideas from our combined brain trust so that we can make it so.

We all have to try to get from the new idea of an array standard to the various, practical solutions that it might provide, and then, to the extensions that can fully utilize it.

I KNOW there will be great ideas and discussions on this matter from many of you.

Speak!

Let's imagine we have a specific problem:

We want users to be able to create a puzzle game where there are colored gems that can be moved around until 3, 4, or more connect. Those are pretty common and there are many variations on them.

Let's split that up into two, major parts:

The first part is the graphic, visual aspect where there are gems on a grid. Any gem can be clicked on to grab it and move it, and the rest of the gems horizontally or vertically on the axis. After the move, the objects in that line snap back into the grid.

Ok, then there is our visual and user interface aspect. That is just an array that you would assign objects to and it would respond by adjusting the positions of the various objects.

Now we have, perhaps, another array. It might use the Array Standard to work with the first one. The first one knows what objects are on screen and where they are in its "grid".

The second array would supply us with the logic for the game. What is the goal of this game? Well, connect the same gems together so that they touch in any direction and make sure there are 3 or more doing it.

Great, so we could do this with one of these object, but if we had a standard, then the logic extension/array could play nice with the visual one, (or any other visual one that works on the same principle but might have variations to it).

So, the logic array extension is able to do the pattern matching required, quickly. It would be optimized to check all the gems and find out whatever criteria has been set and report that back to the author:

What is the minimum number of objects of the same type that must coincide? Do they have to do so in a particular direction or directions? Do they have to form a shape? Etc.

Now we have the framework for this game in a simple way. Next, the logic extension has to tell the graphic one what to do. In this case, maybe set the animation of the chosen, connected objects to something flashy and destroy them all. Then, slide the remaining gems in to fill the empty space.

I think that sums up the problem and how it might be solved. From there, we could tackle more complex scenarios, (which might be provided by other logic arrays or updates based on the standard.

The above method might be applicable to many game types, once we have explored the basic concepts and have the groundwork in place.

This looks both exciting and promising and it is purely theoretical for now, but that is how most things start out. It might bomb, or it could be the next big thing for MMF2 extension capabilities. I am betting on the latter.

I just want to note that, if you read the above and see what it is getting at, (thanks to my lead and others bringing up great ideas) we are talking about something incredibly powerful and totally inline with the innovations that Clicking brought to people in the first place.

Of course, you all know that we are hear to struggle, think, interact, and find those things that are not obvious and make them totally real for users to benefit from and thoroughly enjoy as they create with ease and comfort.

We are getting there slowly, but can't drop the ball on vision, brainstorming, and risking new and unheard of ideas in this quest. The more we play with pushing the MMF envelope, the more we are likely to dream up and implement amazing new levels of power and ease of use that will do Yves and Francois proud because we are resourceful and bold enough to amplify what they started.

I think that the Array Standard is a viable piece of the puzzle we are always looking for in the process of making games and apps more intuitive and human in their creation -- the geeks give computer power to the laymen and that is altruistic. I am pretty certain it will turn out to be a major one, even though there are many pieces of that puzzle that are still occluded and obscured.

We can do this and do it to a degree that will eventually turn out to be evolutionary. It is already happening.

Just a question? How should the user set up the logic array in a simple way to handle different kinds of games? To set up that in this games N pieces forming "this shape" having "these features" should generate "this action"?

Hey Z!

Well, the devil is in the details, ey?

This is a place we need to go from fuzzy to clear and that may take some conceptual trial and error since there are so many variables to consider.

Let me see if I am on the same track with a hypothesis here:

(please do advise me on any technical problems with the ideas)
Let's say we have a Smart Array, (which is what I would dub the products based on an Array Standard). This one might work something like AGBO, but it is simply designed to accept game pieces and manipulate them.

We have to weed the many possible factors down to something manageable at first, right?

So, I know you were talking about the logic array, and we have adopted the notion that this system could potentially work better in layers, so for now, we would separate the graphic engine from the logic engine, but they would interact, perhaps?

Graphic Array:
Action: Assign objects to it. Maybe we have four colored gems, or a dozen puzzle pieces.

Action: We set the size and area of the Grid.

Now we want to tell it when and how to display the pieces. Perhaps there could be a "map" file that it works from for setting that up. There could be a random "fill" mode for the grid that populates all the cells. This could even be a multi-use object in those respects.

The other thing this object would do is respond to user input. There could be presets that allow for an expanding number of controls. Can the user move any of the objects, or a whole line of them with the keyboard or mouse, etc.? The user's actions could create and destroy objects in the grid, as well.

Now, we get to the "Logic". Again, considering the splitting of duties by various arrays. That object would be like a layer. Mayeb their could be different types of Logic Smart Arrays for different uses or with varying degrees of complexity. It really would be more flexible this way as different logic engines were created that could control various Graphic Smart Arrays.

This array would control the other side of the equation as the Graphic Array would handle populating the grid at startup, and user interaction.

And so, the Logic would cover the game rules. How many objects are touching? In what way/direction are they touching. Does there have to be a state that the object is in before it qualifies for an action?

Examples:

We might want to assign ten total pieces for the game, but only start with four and add one new type under a condition that triggers it: Pieces destroyed = 100, Add a piece.

Objects touch, all four directions, minimum: three, same color/type, not animating.

Objects touch, horizontal and vertical, minimum: four, same color, not moving.

Objects touch, diagonal, minimum:five, same color/type, object faces directions 0, 8, 16.

At this point we might tell it how to inform the graphic engine to move the pieces after one of those examples became true. Fill in the empty spaces with object already on screen? Add new pieces? Destroy certain kinds of objects? Add a new piece type? Etc.

I hope this is at least a start that puts some meat on the bones. It can seem overwhelming and complex at first if you overdo what the objects would cover. Later, as we get some prototypes going, we can consider various graphic and logic problems, decide if the are doable, and which Arrays will handle what.

Then, we can certainly expand on this idea without limits if it works out. Starting with the basic gem/chuzzle-style/puzzle game seems easiest, but there are many possibilities for Smart Arrays on the Standard, even simulators and non-grid games. I get the feeling that we can have more control and even go a step above Custom Movements with this.

This could, if the control doesn't get too complex from the user end, make many game genres very clickable, even for newer users.

How is this shaping up? Exciting and innovative or just plain nuts? :)

Plain nuts.. :p

Hope some other ED's also can do some brainstorming to get some more details.

Ah, good. I thought I was crazy ... heheh!

Find line between genius and insanity, you know.

Yes, the more discussion on this, especially on the technical pros and cons, the more we might whittle it down to something prototypical and consider going for some proof of concept.