Some thoughts

[JRowe47]

Hey there

I've been learning what I can about various 3-D engines / Game engines out there, and bouncing around ideas about what I want to do with it. I have several ideas I wanted to improve on, as well as two projects I want to start.

First, the engines I've studied over the last few weeks are downright incredible. When you think about the state of technology, it's rather amazing that individuals living today are simply a few months of study, a couple hundred dollars of software, and an imagination away from creating their own worlds... potentially with a reality as intricate as the real one.

Ogre 3-D is phenomenal... and phenomenally complex. It's overdone for all except perhaps the most abstract and complex artificial creations. Yet even so, it would only take two or three weeks to familiarize one's self with the code, tutorials, and community to begin forging ahead with nearly any 3-D creation.

JMonkey Engine is another awe inspiring system... and it's incredibly simple. I had a simpleGame implementation, with an animated character running around a mirror up and running within an hour of downloading the SDK (and all the attendant Java madness.)

Panda3D is another great engine. Python is a great language. Easy to read, simple to write, and very powerful. The engine itself, along with the community, are an oasis in a very dry world.

I've explored alot of other engines (and have a whole ton of crap to delete from my hard drive to show for it.) Apocalyx is possibly the smallest and simplest engine I came across that is worth mention. The Baja 3D is similarly easy to use, however it is not yet developed enough, nor stable enough, for common use.

Now, however, Irrlicht is a delight to use. I see some high-handed mud slinging and e-p33n waving over the merits of various engines, but it simply comes down to this: use the tool/s best suited for the job at hand. Irrlicht happens to be the easiest c++ engine with modern capabilities... or the fastest easy engine to use. It takes hours to understand and begin creating a project, and the support is great from what I've seen thus far.

My 'job/s at hand' are fairly simple to begin with, I think. The first thing I want to do is create an IDE/Coding utility, which parses source code, fills in formatted tags in preceding //comments, then reads the whole of the code into a 3D environment. One would code an application by manipulating code objects around a central 'application' object, allowing simple use of gigantic libraries.

My idea for the central application object would be a dodecahedron, each of the faces representing a different discrete aspect of a program. Not all programs would utilize all faces, but every possibility would be covered. I'll post another thread detailing the design doc sometime later.

Read: a formatted database consisting of any and all useful code gathered from across the internet. I hope to be able to import any given project, such as Irrlicht, into the system, and have it's API automatically mapped into a toolkit, from which I can drag and drop functions, objects, and so on, without ever actually dealing with the source code at a text level. The philosophy behind such an effort is simple: programming languages are abstractions whose goal is to move programming itself to a higher level of understandability.

While programming sea-changes have almost always consisted of linguistic phenomenon (the move from assembly to c to java or python or cobol, for example,) I envision a visual paradigm, effectively black-boxing that information which should remain black-boxed while exposing the underlying systems in the clearest possible manner. UML is one area in which the underlying precepts have been explored, yet none have taken advantage of the full range of implications.

Coding is restricted, in my humble opinion, by the need for intimate system wide familiarity with the code one uses. By visually exposing the system, an immediate, intuitive grasp of the arrangement and logic can be had, and use can be made of the code that's already been written, leaving the algorithmic implementation as the only work to be done (the logic and flow of the program one wants to design.) The difference between this and scripting paradigms, however, is that logical mappings can be made language agnostic, and one could make use of any importable system through visual manipulation and minimal text coding.

Anyway, I plan on implementing irrXML, any of several c++ source code profilers, Irrlicht3D, a compiler, and some other packages.

My other project is a game idea, and I'm waiting on building my IDE before I dive into that, even though I have dozens of pages of design docs and random notes

I'd love some input on the IDE thoughts... everyone I've discussed it with has either been uninterested or opposed to the idea of visually designing programs.

[BlindSide]

Hey I was waiting on you to tell us about all the different engines you've tried after leaving Irrlicht, nice write up (Ok ok Ill actually read it when I have time ...)

EDIT: OK I read it.

You have used some very advanced "programming-linguistic-theory-philosophy-ish" vocabulary there and it has left me kind of overwhelmed. But I think I get the basic idea.

Now for me, I'm kind of jealous of your broad-nature, I tend to stick to C++ and I tend to like. I can even be considered some sort of C++ elitist (And maybe and Irrlicht elitist at that, but not really).

Anyway your IDE sounds very plausable and great. It's use to me personally as an already established C++ programmer thats familiar with Irrlicht and IDE's and visualising the hard way how a project will turn out or look, I feel like I already have what you describe in the palm of my hand, simply using Irrlicht and a C++ IDE I can probably prototype and shell out things with as much ease and expressive capability as you described. But I think this is a personal matter, and one that might take a year or two to achieve.

I was also thinking recently of using IrrEdit's plugin functions, it allows you to code plugins that can do many things (And scripts also). You could for instance write an irr file interpreter (irr file as in the scene file that IrrEdit uses) and use the IrrEdit plugins to create an easy to use interface for users to visually and create their ideas. You can also use the already impemented scripting system to your advantage (Though you might have to code your own, im not too familiar as to how much access a custom plugin interface will have to IrrEdit's internal scripting systems).

Anyway thats my idea, and Ive been thinking about making an easy to use IrrEdit "IDE" type thing similar to the likes of "GameStudio" (Maybe even easier to use, who knows) for a while now, and I recommend to use something like this in your project (My thing wont happen anytime soon unless my ambigous personality wanders to it sometime randomly in the future, haha).

Cheers and I hope I was of use.

EDIT2: Wait, so you are proposing some kind of visual programming language that can be easy to grasp at first site and provide the user with instant recognition of the entire range of concepts and solutions involved with the API? It seems kind of hard, what kind of ideas have you had that would aid you in making this possible?

[JRowe47]

Actually, I'm proposing a visual abstraction of already existing languages, starting with c++.

The basics, like operators and grammatical structures like classes, functions, and so on, are simple to represent visually. Different attributes like shape and color are used to index characteristics of the term in question... a red line linking to constants or variables, one on top of the other, representing the subtraction of the bottom from the top... or perhaps a curved yellow line linking the variable to a constant, wrapping itself and another function in a shimmery yellow force-field type shell... representing a For/While loop.

Linking objects, via inheritance, would be done similarly, via lines or 3D effects, for easy visual comprehension.

Every program would consist of 12 discrete aspects, each of which would be contained on a single face of a dodecahedron.

I (very loosely) envision these 'aspects' of a program as the following:

1.) Main Loop
2.) Globals & Constants
3.) Objects (Classes)
4.) Functions
5.) GUI (+integrated GUI designer and real-time representation of the GUI itself), or 2D libraries
6.) Networking
7.) Databases (MySQL, postgreSQL, etc.)
8.) External Data (.xls, .txt, .3ds, .xml, etc, et al, ad infinitum... this is where the data the program uses is interpreted, defined, and otherwise manhandled.)
9.) 3D libraries, 3D logic
10.) External I/O (imported APIs, etc)
11.) Internal I/O (exported functions and wrapper definitions, etc.)
12.) Intitialization and Exit parameters (what to do on beginning or ending the program.)

One would navigate the 'code' by using your mouse to rotate the dodecahedron, displaying the different faces. when a face is selected, a pentagon would project from the face, and depending on how much code you have for a particular aspect, multiple pentagons would project, allowing you to further divide your code into layers, and you would use the mouse wheel to scroll through the individual layers.

When an object is selected, it's parameters would be available in a text box for editing. Multiple tabs would also allow direct editing of source code, although source could also be manipulated visually, through context menus and other interface widgetry.

It's still very rough, and visually representing abstractions like pointers in a meaningful way will be challenging, but I think a virtual representation of the stack would work (not 1-to-1 mapping, but an iconic display related to selected objects.)

At any rate, I think it would make programming a breeze

I was just thinking one day of various concepts involved with programming, and they all converge at a common point... the interface. An interface is designed entirely to display the broadest amount of information in the most readable possible manner to the user, while maintaining ease of navigation and retaining functionality specific to the program. I thought... here we are, 30+ years settled into programming in human readable text, 10+ years into decent 3D technology, and we're still essentially using hopped up text editors to program with?

It's just another degree of abstraction. I think the linguistic abstractions have all panned out... COBOL is the ideal linguistic programming paradigm, but it doesn't translate well into a real-world scenario (unless of course you're a major financial institution.) If we got quantum computers tomorrow, this is all a moot point, as it would be a matter of weeks before we had thought-reading software that would do whatever we wanted it to.

Until then, I think that a visual approach is the best use of resources, and irrlicht is the sledgehammer for this particular fly

[bitplane]

I personally think the idea of moving programming completely from the linguistic to the visual won't work, for the simple reason that reasoning and logic have evolved because of language.

A written word as a series of letters or patterns is meaningless, it has to be read and processed by the part of the brain that deals with language (and therefore logic) for it to 'make sense' to us. The ability to recognise visual patterns and convert them into language is something that takes a very long time to develop, you spend your entire childhood learning reading and writing skills. In programming, we build upon these skills and use the linguistic parts of our brain to process the logic. Learning a totally new system would be pretty inefficient.

However, there are other pretty advanced skills we have which can be applied to design. We have good spatial awareness, which is great for navigation. This is what makes GUIs so useful, it's much easier to navigate using shapes than it to imagine squiggles as sounds and hear them give us directions. One programming example of this is code indentation, we learn to navigate code based on its shape rather than actually reading it. I would guess this could be expanded further with some success, like if you could identify functions and objects at a glance by simply seeing the patterns they consist of. We humans still need to process logic in sentences though, so I don't think a completely object based approach would work as well as simple text on a screen.

Perception/imagination of time/movement is another thing we're good at (maybe visualising threads?). Being tool-builders we have good spatial imagination, so it could be really useful to visualise programs as 3d objects.. I'm not sure how it would work though.

It's a pretty cool idea, I'd like to see how it pans out. I'm pretty sure in 100 years we won't be using glorified text editors

[Dorth]

Well, here's my 2 bits:
don't make a dodecahedron.
Actually, don't pre-decide the number of aspects the application might need.
Nor decide what those may be. Just grow a 3d shape based on the number of aspects present.
One game might use 2d, another 3d, another might just be the back-end for an online game thus no use of any graphical engine at all.
Some might use database, some might use files, other connect to a server.
etc.
You see my point
Also, don't skip step. You start from the most advanced game maker of today which are at best schematics and you want to go full 3d. This will be extremely hard for anyone learning it, losing you various important support on the way. Maybe keep the 3d effects to the minimum, like no shimmering sphere for a loop, as this is kinda counter intuitive (I'd personally see a circle with an arrow head on it turning around it's center or something the like.)
Hope it goes well, and if you can, make it open-source on sourceforge. You'll need help and this is something that might eventually help us all out there, so we all have something to gain from helping you ^^

[rooly]

hold on, so you want to use irrlicht for the 3d programming ide?

and about having integration of libraries for use, i assume someone would have to write a project template for each type of project, because i doubt it would be feasable to have your program be able to extrapolate usage of each function.

what language would it compile under?
moreso, if no specific language, would you have to make seperate compiler plugins for each?
If no current language, then would that mean your making a 4th generation language and compiler?

[JRowe47]

The ability to recognise visual patterns and convert them into language is something that takes a very long time to develop, you spend your entire childhood learning reading and writing skills. In programming, we build upon these skills and use the linguistic parts of our brain to process the logic. Learning a totally new system would be pretty inefficient.

I'd disagree somewhat, because of the instinctive adaptation I've made, and seen made, to game guis, associating keymaps and hand motions to the motions of an avatar, whether it be a FPS, or virtual fighting game, or a RTS. Starcraft is a prime example of logical mapping across a virtual space, even though the concepts are logistics and strategy.

I was thinking that I would use the c++ language, and use open source parsers and compilers. I don't want to reinvent the wheel, but I do want to strap on some wings.

Yes, to begin with people will have to create projects by hand, but I have a feeling that given a large enough database of snippets and formatted code, some sort of AI could be used to automagically tag code into it's appropriate category. Or the programmer could just use a comment line to tag his code as he goes.

PostPosted: Wed Jul 18, 2007 3:41 pm Post subject:
Well, here's my 2 bits:
don't make a dodecahedron.
Actually, don't pre-decide the number of aspects the application might need.
Nor decide what those may be. Just grow a 3d shape based on the number of aspects present.
One game might use 2d, another 3d, another might just be the back-end for an online game thus no use of any graphical engine at all.

The reason I would use a strictly defined polyhedron format, a dodecahedron, as opposed to an evolving framework, is for familiarity with the system over time. If you enable only certain aspects of a program, even though all aspects aren't used, you still have the ability to add on to your project at some later time. It would be an integral part of the GUI, as opposed to a dynamic structure, whose purpose is not accurate representation of the code objects, but to facilitate navigation of the source code. The actual code itself, such as classes and so on, would be dynamic structures, evolving visually as you built them (either via drag and drop or typing, the traditional way.)

It's much easier to associate and understand a single object with discrete characteristics than a series of objects whose characteristics are dynamic.

By creating a rigid classification system with a flexible selection of options, we create an ontological meta-framework. That's where code snippets and algorithmic structures can eventually be interpreted and dynamically translated from other languages, via a system like this: http://handhelds.freshmeat.net/articles/view/1910/

That's further down the road. To begin with, I'm putting together my basic objects. And yes, a line with arrows is more intuitive than a shimmery yellow force field. That was just a visual example to present the concept

I'm trying to logically present c++ in 3D, on paper, atm. I'll post that when I have a better rough outline.

[Dorth]

Again, I can't stress enough how important it wold be for your concept to work to not predetermine it's elements nor shape. Why would everything in the system evolve while a few shapes stay the same? Do you know why Visual AssistX and tools the likes are so popular? Because they offer you customization.

This article is interesting, but specifically this page: http://www.gamasutra.com/features/20060 ... s_02.shtml

If you want to feel as if your application is evolving, let it have life. It's easy to have a center core that simply devellop or lose faces as the development is ongoing. And that is natural. The same way the number of files in your project grows while the project itself grows. You can of course offer template, offer a basic layout (pyramid? 3, 2, 1 curved faces?) Offer choice and offer evolution, this helps learn, cause your environment reacts to your action.

[JRowe47]

I'll give it some thought... The problem is allowing a system to become needlessly complex.

I think that every program, everywhere, shares characteristics.

By boiling down that list to a set of basics, in that every program is going to have at least one, and at most all (no matter how complex,) then we can safely create an easily recognizable core object. Let's call these common characteristics 'Aspects'.

The other option is to assign each of those aspects visual characteristics which make them easily recognizable, either via shape or color.

The problem then, however, is the interface. Instead of rotating the core application object, you have to create a system of cycling through program features, and of organizing code in an interpretable manner.

It's doable, but many many times more complex, and I'm not certain that the added complexity gains us anything in the long run.

I would say it's primary advantage would be flexibility in creating custom Aspects. Maybe a streaming 3D content loader, which has Network
characteristics, and 3D, and Data... so instead of using all three, you bundle it into a custom Aspect node.

Either way has merit, I just need to consider how an evolving framework can be made as shallow (interface wise) as a closed structure system.

[Dorth]

Easy, have you ever seen TRON?
Have a central pillar of light or the likes.
When adding an aspect, you cover it by the side part of a cylinder. That part is clickable and display properties. 2nd aspect split the cylinder in 2 faces, different colors. And so on and so forth. You can even just put panes in front of it if you dont want to deal with cylinder faces and the like. Also, rotation around a single axis is EXTREMELLY simple and natural, no extra difficulty there