I don't even know how to start this thread, I don't even know how much merit the idea itself has.

I guess i'll start off by introducing myself (you may skip this part). My name is David Arayan (or DrHalfway) and earlier this year I deferred from uni (temporary leave) to work on a Game Project full time with my good friend. The project itself is coming along nicely and is nearing completion. We basically wanted to break into the Android market for games, the idea was to be able to make enough to sustain ourselves like we would with a full time job and at same time work on a "Dream Game" that we both had.

The initial idea of our Game Engine was to create a basic scripting language that works around a scripting module that comes with the engine. This idea was unfortunately scrapped due to time constraints, so currently we code our logic entirely using java syntax and special tags which our parser recognizes and converts directly into engine-call code.

While our Dream Game is years away, and will possibly require a complete new game engine I had this idea of a Universal Programming Language which i'd like to discuss in this thread, and would also like to know if the idea itself has merit since it is such a massive undertaking.

The idea of the UPL itself is simple, provide some form of easy to use syntax which mainly borrows from the best features of the most common languages around, code in that syntax and generate equivalent Java - C - C++ and C# code. The idea doesn't generate bytecode or native code directly, it is basically converting UPL code into one of the supported language codes and using the equivalent compiler of that language to compile into bytecode/native code or whatever machine code.

Ever since I mentioned the idea to my friend, he thinks its not really a programming language, but rather a scripting language, since we generate syntax for other languages, not the bytecode/native code directly. On a casual basis, I draw diagrams and come up with ideas for the syntax itself and the idea seems to grow on me more and more as time goes past. Thinking from a higher level, once the syntax is complete, it will be possible for example to create entire game engines using UPL and directly generate and compile into one of the supporting languages. Of course, UPL will need to come with its own library of containers, and will possibly be able to also create a common interface for performing openGL calls (and if the language in question supports it, will perform direct openGL rendering) or switch back to a software based renderer.

So now the idea itself grows even larger, becoming more of a language to be used by graphics programmers rather than a language to be used for general software development. Most language specific features can even be imitated.

So here is the great idea! code this UPL, then code the Game Engine for our dream game on top of it, and who knows? it could later be converted to some kind of library that comes packed with the UPL itself, allowing for rapid development of games that can run on one of the supported languages that UPL supports.

I understand that this is a massive undertaking and a huge challenge that will require extensive planning and documentation beforehand, not to mention possibly years of dedication to actually develop the thing. I'd like to discuss if this idea has merit, and would it actually be useful? or is it reinventing a well invented wheel and would be a complete and utter waste of time? or maybe i'm just way over my head and possibly underestimate the complexity of the idea that is brought forward. Discuss, Rant, Comment, fire away!

What is the gain from this "UPL", what does it offer as an advantage over all the existing libraries such as java/c/etc and their compilers/optimizers/libraries/etc.

Without wishing to poor cold water on your idea it seems like you have a solution looking for a problem rather than something actually new and useful.

The advantage is that you code in UPL and the equivalent code is generated for C/C++/Java/C# (initially). Any other language parser can be written and plugged in with UPL if needed. I'd actually prefer someone pour cold water on this idea, it would save me years of trouble and headache!

Think of it this way, you've coded an engine using Java, spent day and night on it, wrote something like 30,000 lines of code and decided you now want to support a platform that does not have java, or can be done better using a different language... my guess would be you'd need to re-write most, if not all of that code (though it'd take you less time, its still bloody annoying).

There are already tools to convert languages onto other platforms. Java by its very nature is highly portable, and there are tools to convert it to objective C etc for platforms where Java doesn't function.

I think you are also forgetting the problem of libraries etc.

For example even if you converted the java syntax that wouldn't give you access to all the libraries (such as the Collections library) which you would either have to convert yourself or do your own version of.

Yes, obviously a collections library needs to be written in UPL that gets converted along with everything else, aswell as a graphics library which mirrors openGL (and uses it on platforms when available).

I think this is getting closer and closer towards what Unity already does, although Unity can't be used to write other applications (where as UPL can).

I think this is a very bad idea... It is not just collections you would need to rewrite but absolutely every single library/utility class used in the code. And what would the point be of a lowest-common-denominator program that could be compiled into several languages? I already reach all my platforms with Java.

I came up with a Game Engine idea when I was about 14-15 years old, at the time I accepted the fact that my knowledge and skills where nowhere near enough to make it into a reality, and here I am, years later making the same idea into a reality! Probably the best action would be for me to shelf this idea and possibly revisit it later in life.

There are alot of things I love about java, and alot of things I love about C++ and other languages aswell, would have been nice to have a "blend" of all in a single package!

The closest we will ever come to a UPL is if all coders/CEOs/everyone related to electronics and anything in general, came up with a language that would run on everything and supported it and all new hardware was made for it kinda like the whole IEEE floating point thing, even then their are many variants. Basically, egg heads who thing their idea is the best will never agree to make one language that will be used for ALL future electronics. Even if they did, the logistics would be impossible. What we have is fine. No one will ever be able to program everything well. People specialize for a reason and it has very little to do with language. I want to go for 3D graphics and all that jazz...one baby step at a time.

You should shelf this idea for now unless you are doing if for fun. But bare in mind, if you do continue doing this, don't expect anyone to really care because well.....

Code generation is almost always bad practice.As soon as there will be need - and it will - to modify generated code, the idea is beaten. You can't just generate code for different runtime environments and libraries with different approaches to handle things like threads, UI, events.Should the people handle two IDEs or mess with crappy plugins, what about debugging, what about turn around times ? Java can even often replace classes at runtime.Far more important than fancy language features is the overall development environment, productivity, matured flexible libraries. And for cross platform, a runtime is the way to go like Java proves.Then, who's going to use a new unknown language without being backed by community or company ? No one, way too risky.As mentioned by others, the amount of effort is insane. And if takes years, who knows how the development world generally looks like in the future ?

Looks to me you are just trying to do what XMLVM does, except for every programming language for ultimate portability. However, since these languages are ever changing with additions and subtractions of data and libraries every day. You will pretty much end up coding into a dead-end. Unlike Java, you can't guarantee backward compatibility or that you will be able to get performance in Device A at the same speed as Device B using your conversion methods from language to language. Also, given the fact that all those languages are changing day-to-day would mean your expansion rate will have to be x^n as fast as the other guys. They have a team, you are only a small group (hopefully).

Instead, the best thing would be just to focus on completing the game. If this is a game engine production, then make sure it can at least do the game purpose first, before moving on to something astronomically large like UML. Small ideas can turn into huge breakthroughs, but you have to complete it all in small steps.

XMLVM is probably the daftest most esoteric idea around. Every time I read back the concept to myself in my head I just end up shaking it slowly, bemused. Reminds me of the story about the king, the toaster, and the software engineer again.

We will need a scripting language for the engine anyway, which will be developed alongside the engine (good to have, but not strictly needed). If I ever go ahead with this UPL idea, its more likely to end up with whatever Unity is, a cross platform engine with a powerful and flexible scripting module.

Having said that, before we even start with our "dream game", we need a way to sustain ourselves by making small-scale games, which is what our current engine is meant to do anyway.

No one really cares about these sort of things until some kind of working-prototype or working concept is displayed anyway, just wanted to start a discussion, or flame war with community to see if the idea holds merit... even then, to even consider starting something as astronomical as this would require some kind of miracle from heaven to give me unlimited motivation, dedication and patience. I think creating a game engine was enough of a challenge at this point in time... i'll be making games for a few good years to make up for this past year alone

We will need a scripting language for the engine anyway, which will be developed alongside the engine (good to have, but not strictly needed). If I ever go ahead with this UPL idea, its more likely to end up with whatever Unity is, a cross platform engine with a powerful and flexible scripting module.

Having said that, before we even start with our "dream game", we need a way to sustain ourselves by making small-scale games, which is what our current engine is meant to do anyway.

No one really cares about these sort of things until some kind of working-prototype or working concept is displayed anyway, just wanted to start a discussion, or flame war with community to see if the idea holds merit... even then, to even consider starting something as astronomical as this would require some kind of miracle from heaven to give me unlimited motivation, dedication and patience. I think creating a game engine was enough of a challenge at this point in time... i'll be making games for a few good years to make up for this past year alone

In truth your first 5-15 games will suck hard so just make them hastily and learn from experience. This is also true for game engines. Your first iterations will be unusable. Just focus on games its also much more fun.

I have written many games, and they did indeed suck, and i've written about 7 game engines, which, well, as you've guessed, were also unusable. The last engine was a prototype created for submitting an assignment for university for a game of breakout. It was coded in C++ that involved about 1500 - 2000 lines of code, it had a basic GUI system for rendering text, a basic scene manager for managing the scene, it had a renderer that could render basic untextured primitives and a basic collision detection system that used SAT. You could say that it was the predecessor for our current engine written in Java. (we chose java at a flip of a coin by the way)

I love games, I love coding the tools and systems required for making those games, its difficult, its a challenge, its a major pain in the ass, but I love it. I lack the creativity needed for coding the games, but am quite good at making the systems that the games run on, interesting isnt it?

Go look at something like something like http://strategoxt.org/Spoofax. How good is you're compiler knowledge? Functional programming? My strong suggestion is to do something else. Too much effort, too much risk and too little likelihood of success.

There are alot of things I love about java, and alot of things I love about C++ and other languages aswell, would have been nice to have a "blend" of all in a single package!

If you're doing this because you have heard the phrase "all programming languages are the same except for syntax" then turn back now.

No. That is like blending orange juice and mint ice cream. It does not matter how much you like them separate. There are a thousand simple reasons why they do not (cannot) belong together. If it's not obvious why then you need to spend more time in one language or the other. Also note this post.

I question the use of the term "universal" if you are only aiming to model algol-based languages, and not lisp-based families and other interesting off-shoots.

Also, it seems to me that there has been lots written about folks trying to use the methodology of one language to write code in the other, and getting into loads of trouble. I recall reading a book ("Dreaming in Code") where a bunch of expert Java (and other backgrounds) programmers decided to work in Python, but didn't really have a good feel for the Python way of doing things. And this lead to massive project delays, not to mention terrifically inefficient and slow code.

Wouldn't this project necessarily run into just this problem on a massive scale? The architecture and structure that works for one language, won't necessarily code smoothly into another. Roquen just mentioned the problems of a functional-coding-based language vs OOP. The two paradigms lead to very different organization of classes and methods.

Roquen's mention of compiler experience also makes good sense. Your concept seems to say compilation is not the goal since your target is other languages, not machine code. But it is still essentially a compilation process, and having some strong experience and understanding of compiler theory would be highly pertinent.

Programming is often about making some very specific, nigglely things work, much of it obscure and annoying idiosyncratic. Is this tool an attempt to magically hand-wave away the messy details?

I recently came across this little essay: "There is No One-Size-Fits-All Solution" by Randy Staford, in the book "97 Things Every Software Architect Should Know."

a couple snips...

Quote

A big problem in the software industry, in my opinion, is that people are often responsible for solving problems requiring more contextual sense than they've accumulated...Typical examples include failure to apply domain-driven design when appropriate, straying from a pragmatic outlook and over-designing a software solution for the essential need at hand...

My vote: too ambitious. Put it off for a few more years and narrow your scope. Accumulate more contextual sense.

In fact, from what I've read, your goal of earning money via Android games will be a serious challenge in its own right. Have you seen the threads here about the difficulties with pirated code there? I would love to hear about it if you and your partners are able to generate any income there.

i can only say that it's definitely a challenge. A compiler alone is only half the puzzle, you'll also need strong tooling support and a community to keep things alive.

i would not treat it as a critical piece in your bread and butter infrastructure. however, i think it's nice to explore new grounds, no matter if the outcome is useful itself. worst case you learned about lexing, parsing, ASTs, and all sorts of nitty gritty details that broaden your view when approaching new projects. prototype something i'd say, without putting pressure on yourself. make it a sideproject, just for fun.

you might also want to look into haxe. they are essentially trying todo something like you have in mind, with mixed results.

XMLVM is probably the daftest most esoteric idea around. Every time I read back the concept to myself in my head I just end up shaking it slowly, bemused. Reminds me of the story about the king, the toaster, and the software engineer again.

There are already so many scripting solutions, even available in the JDK itself. After a few weeks of vacation with total detachment from everything programming related I conclude that it is time for more articles about actual game development and less about technical wizardry. Inventing your own scripting language is very cool (been there, done that) but it just doesn't help you progress towards creating a game as you'll be busy maintaining that very complex piece of tech and not writing game logic.

My premature goals for 2013: focus more on using stuff that already exists in stead of constantly wanting to roll my own. I already started with LibGDX which I adore, adding scriptability to a game using existing tools is also an interesting query to research, answer and document. Would Groovy work I wonder? JRuby perhaps?

One reason to use it, most certainly. I've seen some other appliances though, such as for the purpose of not having to hard code everything into the game itself but allow certain things to be open even after deployment. Most features requiring scripting only become useful when you want to open up your game to modding however, which most of us should not be doing if we want to actually finish something sometime. I see some potential in games that have RPG elements though, worlds/levels will often have "business logic" tied to them. That logic might just be in the form of scripts that can be weaved into the level/world data in stead of your application code.

@Drhalfway: really I've been where you are. But you invite a murderer into your home called "context switching"; a murderer of focus to be more precise. Something as big as a scripting language AND the interpreter to go with it can hardly be considered a 'side project'.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org