New Language: Informal request for comments [LONG]

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
Oscar
Gnoblar
Posts: 9
Joined: Tue Jun 21, 2005 12:22 am

New Language: Informal request for comments [LONG]

Post by Oscar »

This post is relatively long but since Ogre3D was chosen as a primary component of the reference platform I thought it might be of interest to the Ogre3D community.

------[SNIP]------

Introduction:

This post is an informal request for comments concerning a new language supporting domain specific constructs for game development. Originally the specifications for the language assumed a runtime scripting engine rather than a traditional compile and link/load approach. During recent work on the language it was decided that neither a scripted nor compiled approach would be implied.

The goal of developing this language is not to duplicate or combine minor differences of existing languages such as Java, ECMA-334 (C#), D, or C++. The goal IS however based on the desire to include and/or significantly expand on existing features, constructs, and practices generally available only in closed source alternatives and/or spread across different technologies. One primary example is the introduction of delegate collections. In languages such as C# there exists the ability to declare delegate methods (to address the lack of function pointers) while proprietary languages such as UnrealScript support 'states' which act as collections of delegate methods. Both constructs expand on existing design patterns and are both are extremely desirable in dynamic environments.

A secondary goal of this effort is to utilize existing open source packages to reduce the development time and to provide a robust set of tools and information for testing and validation. The compiler itself will be released under an OSI approved license in order to make it available to the widest audience possible.

Work is presently being done on a prototype compiler (minus some items proposed in this document) that generates an abstract syntax tree (AST), includes syntax validation, and is able to generate pseudo code from the modified syntax tree. It is anticipated that the initial runtime and development environment for the prototype compiler will utilize components from the Mono project including the CLI implementation and MonoDevelop IDE. By leveraging the efforts of the Mono project a stable and usable testing environment is immediately available and an additional language supporting the Mono CLI becomes available. This provides developers with an easy and seamless method of interfacing an existing code base when those languages are supported by the Mono project (i.e. Python, Java, Javascript, and even C with the LCC compiler).

Once the language specification is complete the prototype will be used as part of the base reference implementation. The reference implementation will serve as a platform for validation and additional language development. The reference platform will include (but is not limited to) the following components:
  • The compiler.
    Minimal runtime environment using the Mono CLI.
    Compiler validation unit tests
    Integration with Mono Develop.
    Bindings for selected portions of Ogre3D
    Port of the Ogre3D Stonehenge demo
    Integration with Blender3D
    Plugin and integration with Quark (?)
All components listed for the reference platform were chosen to showcase the possibilities when using a language designed specifically for game development.



Game Development Technologies:

Since the primary goal is to provide a solid language for game development there may be some confusion as to exactly what role the language is intended to fill. The language is not intended to replace existing compilers or code but rather to supplement specific technologies. With that said the primary role of this language is intended to provide a solid environment for game extensions and modification (Mod development).

Since this language is intended specifically for game development there are some very unique possibilities for enhancement. Separate from this document are proposals for various features that are presently not included. The largest of these proposals is the integrated support for three shader languages Cg, HLSL, and GLSL. With these languages being similar to C in grammar and syntax it becomes possible to include support for them directly in the language itself. This extends the possibility for mod development in that shaders can be compiled and accessed directly in code rather than the use of external (possibly closed source) third party tools.




Language features:

Below is a list of features specific to the language. While some of the items can be implied as existing in a C# of Java derivative they are noted for explicit inclusion. While some of these features could easily be implemented with commonly used design patterns the implementation of the described functionality may not perform well when executed in a virtual machine. Since the requirements are still in draft I expect several items to be streamlined over the next few weeks in both the language and the runtime environment.


1. Object Oriented. While I see nothing wrong with plain procedural programming using an object oriented language generally provides a much cleaner approach and lends additional support for strongly typed constructs. By using explicit declarations for abstract interfaces and class implementations the language becomes cleaner. Includes support for interfaces, classes, inheritance, abstract methods, and finalization for classes and methods. Like many existing object oriented languages all classes inherit (at the very least) from a base class named Object.


2. Strongly typed. I know that a lot of people prefer dynamically typed languages but there are far too many pitfalls and performance bottlenecks associated with them. Support for typecasting will be significantly reduced and in some cases eliminated all together. The current expectation is to provide only explicit typecasting with “dynamic_cast” rather than the traditional “(classname)” typecast operator.


3. Lightweight runtime. Unlike Java, C#, etc. the requirements of the runtime environment are minimal and only include those items that are required for specific language constructs. Classes and interfaces for strings, reflection, threading, etc. are recommended and may be required in the final draft of the language and runtime specs.


4. No pointers. Where necessary the requirement (or desire) for pointer use has been replaced with delegates and built in iterators.


5. Exception handling (try/catch/throw). Unlike most languages the exception handling accepts only a single typed enumeration as it's argument. This eliminates the creation of objects when throwing an exception and forces the explicit use of constant values. This is a performance over flexibility decision. ***This may be changed to allow all user specified types to be passed to exception handlers***


6. Primitive types including boolean, char, byte, short, int, and float. Like primitives in other environments corresponding classes can be supported but are not necessary. No decision has been made to support automatic 'boxing' of primitive types with their corresponding class implementation. Includes modifiers such as static, const, and volatile.


7. Typed Enumerations.


8. Expressions in switch/case statements. Traditionally case statements in C, C++, and Java require a constant value. The use of constant values in switch/case statements allows the compiler to detect duplicate case statements using the same value. This removes the possibility that a case statement will be skipped if one before it uses the same value. In the case where two or more case statements are triggered by the same value, all will be called in the order in which they are declared.

Code: Select all

	int a;
	int b;

	a = 0;
	b = 0;

	/*
	 * In the following example case statements for a+b
	 * and a–b are both called. A performance hit is also
	 * incurred due to the expression.
	*/
	switch(value)
	case 1:		// No performance hit
		... do something ...
		break;

	case a + b:	// Performance hit for expression
		... do something ...
		break;

	case a – b:	// performance hit for expression
		... do something ...
		break;
	}

9. Data structures. In a gaming environment it can be extremely beneficial to allow scripts direct access to an internal data structure rather than going through the pain of creating and binding native accessors.

Code: Select all

	struct align(4) MyStruct {
		byte	flags1;		// Offset 0
		byte	flags2;		// Offset 1
		long	cookie;		// Offset 4
	};

10. Support for stand alone “finally” code blocks. This allows the declaration of a code block that is always called when returning from within a method call. This eliminates the need for supporting 'goto' which is commonly used to jump to code blocks responsible for cleaning up after a method has completed. Only one “finally” block may be included in any given method.

Code: Select all

	int test(int a, int b, int c) {

		// The following code is ONLY called before returning from
		// the call to test() and not during the normal flow of execution
		finally {
			a = (b * c) + (c / a) * (c – a);
		}

		if(0 == a) {
			// the code in the finally block is called BEFORE
			// the the return from calls to test() causing the
			// return value (a) to be recalculated before the
			// return
			return a;
		}

		if(a == b) {
			b++;
		}

		if(c == a || c == b) {
			c--;
		}

		return a;
	}

11. Delegates. This is similar to delegates in C# which addresses the lack of function pointers. Unlike C# however delegates come in two flavors. The first is the single declaration as in C# meant to represent a single function pointer. The second comes in a form similar to interfaces. This provides a form of dynamic polymorphism in that an object reference can be assigned to a delegate and only the required function calls are propagated.

This could be extended to include the same functionality as UnrealScript's 'state' mechanism. This would also eliminate the restriction in UnrealScript in which only one state can be active at a time. An example where this can be useful would be in weapons control such as a Gatling gun. One set of delegates would control the trigger mechanism while the other would control the visuals for the spinning barrels.

This extends the concept of both events and delegates (in regards to 'function pointers') into a more acceptable OO paradigm with named types and clearly defined interface requirements.

Code: Select all

	/*
	 * Standard delegates per C#
	*/
	delegate void SomeFunc(int val);

	void Test(int val) {
		... do something ...
	}

	main() {
		SomeFunc = Test;
	}

	/*
	 * Delegate interfaces and implementations for state machines
	*/
	delegate MyDelegate {
		void Func1();
		void Func2();
		bool Func3(IActor actor);
	}

	MyDelegate state1 default {
		void Func1() {
			... do something ...
		}

		void Func2() {
			... do something ...
		}

		bool Func3(IActor actor) {
			return false;
		}
	}

	void main() {
		SetState(state1);
	}
Alternatively the following could be used instead in order to present a cleaner implementation :

Code: Select all

	void main() {
		this = state1;
	}
In the above examples no performance hit is incurred as the methods can be resolved during compile time. This allows a base class or interface to define a known set of requirements for object states or general delegation while providing an optimal approach for binding.

Dynamic binding on the other hand can also be supported when nothing more than an object (of any type) is known:

Code: Select all

	class Test {

		delegate MyDelegate {
			void TriggerEvent(int eventID);
			void EnterState(int stateID);
		}

		void Test(Object parent) {
			MyDelegate  = parent;
		}

		void Begin() {
			EnterState(0);
			TriggerEvent(2);
			EnterState(4);
		}
	}
In the above example dynamic binding is used when passing 'parent' in the constructor. This allows the base implementation to change over time without requiring any subclasses to be recompiled. Typically this could be addressed by forcing all subclasses to inherit from a predefined base class or interface and providing a default implementation for each method. However for situations where dynamic binding is necessary or preferred this provides an explicit mechanism for doing so.

In order to provide an explicit requirement for a typed delegate collection additions to class and interface declarations have been included:

Code: Select all

	delegate MyDelegate {
		void DoSomething();
	}

	class Actor reflects MyDelegate {

		MyDelegate group1 {
			void DoSomething() {
			}
		}
	}
In the above example Actor and all classes that inherit from it are required to implement at least one set of delegates of type MyDelegate.

There are still several issues that need to be addressed such as using multiple delegates of different types, multiple delegates of the same type, ambiguity, and visibility. This could be expanded even further by including modifiers such as required, optional, ignore (as in UnrealScript) to further enhance event handling.


12. Events. Although the dynamic nature of delegates could aid in the handling of specific events it may be desirable to support a built in event handling mechanism. Unfortunately the requirements for event handling can be extremely broad and may be left up to the runtime for implementation.


13. Support for intrinsic functions. Due to the functional differences between virtual machines some may support operations that others do not. This allows the compiler (based on the target VM) to generate bytecode for a specific operation rather than making a call to native code. This can eliminate certain performance hits and allows direct execution of functions such as min(), max(), abs(), etc. to be executed 'inline' by the virtual machine.


14. Enhanced flow control. The 'abort' keyword has been included exit ALL for/do/while code blocks regardless of nesting level

Code: Select all

	for(i = 0; i < 100; i++) {
		for(x = 0; x < 100; x++) {
			if(5 == i && 23 == x) {
				abort;
			}
		}
	}

	// When abort is executed flow control automatically
	// jumps here
This addresses one of the commonly encountered uses of 'goto'.


15. Range specifications. Provides for a range of acceptable integer values for switch/case statements.

Code: Select all

	class MyClass {

		void SetLow(int  val) { ... }

		void SetHigh(int val) { ... }

		void SwitchCase(int a) {

			switch(a) {
			case range(0, 5):
				SetLow(a);
				break;

			case range(6, 10):
				SetHigh(a);
				break;
			}
		}
		
	}

16. Explicit Singletons. This adapts the singleton design pattern and provides an explicit language construct for declaring singleton classes. Classes declared as singletons may not be inherited and may not have any abstract methods. All attempts to instantiate an object of a singleton class will return a reference to the same object.

Code: Select all

	singleton class MySingleton {
	}

	void main() {
		MySingleton s1;
		MySingleton s2;

		s1 = new MySingleton();
		s2 = new MySingleton();
	}
In the above example both s1 and s2 point to the same instance of the MySingleton object.


17. Restricted classes and methods. This introduces the 'restricted' modifier for classes, member and instance variables, and methods. Restricted members can only be accessed by other classes found in the same package (similar to Java packages).


18. Impersonation. This is something that I tossed around while doing a couple of quick mods for Unreal Tournament. While developing the mod I found that I wanted to integrate it with some mods by other people. Doing this would have created a dependency on a new version of the other mod. At that point I thought it would be nice to have some way to tell the runtime to use a different class instead of the original.

The syntax for impersonation is similar to that of a class declaration except that it cannot have any abstract methods:

Code: Select all

	class Base {
		public void DoSomething() {}
	}

	class NewBase impersonates Base {
		public void DoSomething() {}
	}
In the above example the runtime is instructed to replace all uses of Base with that of NewBase. NewBase automatically inherits all methods and attributes of Base. The only restriction is that root class Object cannot be impersonated.


19. Flow control using labels such as “break LABLE;” are supported.


20. Support for fixed sized arrays as a primitive type rather than the use of an Array class.


21. Support for 'assert'.


22. Inclusion of a 'transient' type modifier for exclusion during serialization.


23. Annotations.


24. Support for “try_cast” typecasting – similar to dynamic_cast but automatically throws exception on invalid cast.


25. 'foreach' with optional functor for filtered iteration. Functor can originate from within the object accessing the array or from the objects in the array (iif it is an array of objects). As with most languages that provide 'foreach' the reference to the current object and the index in the array visible throughout the iteration.


26. “if_exist” and “if_not_exist” for conditional inclusion of code blocks depending on whether a specified symbol exists or not.


27. Fixed point primitives up to 64 bits.


28. Additional operators for metaprogramming declarations and implementation.


29. A loose subset of the Prolog programming language with minor extensions to better support Expert systems and fuzzy logic. Note: This is a language feature only and is not implemented in the runtime. The prolog code will be compiled to intermediate bytecode leaving the developer to their own project specific logic engine.




There are several other items which are being considered but have not been added to the primary list of features. The following items are being considered and/or addressed:


1. Scalar destructor/finalize methods.
2. switch/case on object types
3. multiple inheritance
4. parameterized classes (templates/generics)
5. operator overloading
6. function overloading
7. explicit method overrides (C++ virtual) vs. implicit method overrides (Java)
8. Properties

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
x 3
Contact:

Post by Falagard »

Wow, that's a very detailed spec, and a tall order ;-)

I'm sure you've considered C# as a scripting language interpretted at runtime, and thrown away the idea. But with such detailed requirements, without having to write the scripting language yourself, you may want to reconsider just using C# for the scripting language.

Just my 2cents, you may get much better suggestions from others here. There have been many discussions regarding scripting languages here, and people have typically leaned towards lighter languages. Lua and AngelScript coming to mind. Python is also a favorite, and pretty powerful. It may in fact have the features you need, but I don't know much about it.

Good luck,

Clay

Oscar
Gnoblar
Posts: 9
Joined: Tue Jun 21, 2005 12:22 am

Post by Oscar »

Falagard wrote:I'm sure you've considered C# as a scripting language interpretted at runtime, and thrown away the idea. But with such detailed requirements, without having to write the scripting language yourself, you may want to reconsider just using C# for the scripting language.
Actually I've looked at quite a few languages including C#, AngelScript, Lua, Python, etc. and while the C derivatives were quite feature complete there were still quite a few shortcomings. For the game developer the shortcomings aren't that big of a deal as it's quite common to use an assortment of tools to combine various scripts and resources. Unfortunately that doesn't always translate well to the mod community.

Originally I started out with the intention of producing an open source implementation of UnrealScript. After doing some tests with a minimal grammar I found myself extending the language to support additional constructs (primarily to support functional programming). At that point I figured it was probably better to implement a stand along language.

Luckily I've written compilers before so at least I'm not going into it blind. The primary reason for not using C# (even the Mono implemenation) is that it adds the overhead of the entire runtime. While not an overwhelming issue it was something that needed to be considered.

User avatar
Feral
Halfling
Posts: 80
Joined: Thu May 26, 2005 9:12 pm
Location: NORTHERN California, USA

Post by Feral »

I’m no expert and I claim to have no clue, so for what it is worth.


2. I like strongly typed, would be exceedingly nice to be able to easily switch types about though. (in essence just have a way to convert from one type to another easily, I’d think.)


5. try/catch/throw

I’m fond of init/exit methodology, as such perhaps finally *in addition* the normal try{}catch{} style, in essence try{}catch{}finally{}, finally WILL be done at try{} end after possible catch{}.

“Single typed enumeration:”
Why not dual, throw{class, reason), meaning classification of throw, then a more specific reason.
Unsure if something like that would be needed or of value but would extend the number and perhaps organization of what can be thrown.

8. Useful for logic and such like would be:
I would like to see a switch{case} to be able to more cleanly impliment an if-elseif-else tree
For instance case able to support a range, “case 1-20:” or the like. Also, (case “string”:).
I would like case to be able to deal with any native type.

10. I’m pleased to see a function finally, I suggest a different format however:
int test(int a, int b, int c) {…}finally { … }
layout for continuity with try/catch;

I’ve oft thought this was a good idea to ensure a function cleaned up after itself or the like.

14. ‘abort’ seems an inappropriate term. Given 19 (break lables) I suggest calling this “break outerbrace” or such like.

15. made mention of range specifications at 8; I suggest “case lower-upper:” as syntactic sugar. Perhaps also “case <value:” and “case>value:” (etc.)


Make string manipulation both built in and stupidly simple (I like python’s slice operator) … string+“value”, or perhaps string<<“value” , or perhaps string.. “value” … you get the idea I imagine (=

I also think attention should be paid to ease of use for iteration.


My apologies if I miss-read or miss-understood something.
Just sand in the wind (=

Oscar
Gnoblar
Posts: 9
Joined: Tue Jun 21, 2005 12:22 am

Post by Oscar »

Feral wrote:....would be exceedingly nice to be able to easily switch types about though...
Runtime polymorphism is one of the things that I'm still looking into. While not difficult in syntax it can be very messy during runtime. I'm hoping to find a good balance with the runtime type information to allow not only combining classes but to disengage child implementations on a per object basis.
Feral wrote:...in essence try{}catch{}finally{}...
Adding the finally clause was pending based on finding a clean syntax for the finally code block in regards to exiting a function. With the suggestion you provided including try/catch/finally is now on the list.
Feral wrote:...throw{class, reason)...
Actually this was more of an optimization decision rather than a functional one. After thinking about it a bit more there's really no reason to limit it to just typed enumerations. The spec has been updated to allow object types as well.

Feral wrote:...a switch{case} to ...support a range, “case 1-20:” or the like. Also, (case “string”:).
In the spec switch/case already supports ranges (constant or expression) as well as traditional expressions. I like the idea of expanding it to support strings with case sensativity optional. The range() construct was originally added to provide an explicit use of a constant range (optimization decision) rather than using an expression (x > 5 && x < 10). This is no longer the case as the optimizer will handle it as part of it's constant folding option.

Feral wrote:‘abort’ seems an inappropriate...suggest calling this “break outerbrace” or such like.
I never particularly like the use of 'abort' either. I definitely think the 'break outerbrace' syntax is much better.
Feral wrote:Make string manipulation both built in and stupidly simple
This is one of the things that I haven't had a chance to think about yet but super simple string manipulation is definitely on the list.

Feral wrote:I also think attention should be paid to ease of use for iteration.
With support for "foreach" and functors there's going to be quite a bit of built in iteration functionality. A lot of it depends on the runtime though so I haven't had much of a change to get everything added to the list yet.

User avatar
Chris Jones
Lich
Posts: 1742
Joined: Tue Apr 05, 2005 1:11 pm
Location: Gosport, South England
x 1

Post by Chris Jones »

why arent pointers going to be implemented? i like pointers, theyre usefull, why dont many people like pointers? theyre not even that hard to use
i no theres a way of using a kindof of pointer in c# but its not the same. why cant u implement pointers? and let people choose between pointers and c# style version?

Oscar
Gnoblar
Posts: 9
Joined: Tue Jun 21, 2005 12:22 am

Post by Oscar »

Chris Jones wrote:why arent pointers going to be implemented? i like pointers, theyre usefull, why dont many people like pointers? theyre not even that hard to use i no theres a way of using a kindof of pointer in c# but its not the same. why cant u implement pointers? and let people choose between pointers and c# style version?

Pointers, in the traditional sense, are simply not necessary. By traditional I mean the explicit declarations as used in C and it's derivatives. As with Java, C#, and similar languages objects and arrays are references (implicit pointers if you will). One of the complaints with other languages though is the lack of any support for C style pointer arithmetic. This is addressed with built in iterators.

The following examples show the same unsafe iteration through a character array (assumed to be a null terminated string).

C Implementation:

Code: Select all

char *ptr;
ptr = strPtr;
while(*ptr) {
	if('5' == *ptr) {
		ptr += 2;
	}
	ptr++;
}
Implementation under the proposed language:

Code: Select all

char[].iterator ptr;
ptr = strPtr;
while(ptr.value) {
	if('5' == ptr.value) {
		ptr += 2;
	}
	ptr++;
}
Both implementations are similar and do the exact same thing except that the second example will throw an exception if you try to iterate past the last element of the array.

If you can provide a specific example of why pointers are an absolute necessity I'd love to see it.

User avatar
Chris Jones
Lich
Posts: 1742
Joined: Tue Apr 05, 2005 1:11 pm
Location: Gosport, South England
x 1

Post by Chris Jones »

doesnt that run slower? seeing that it is for games, and if u need something to be as fast as possble, and ur using a pointer (or reference), surly the pointer would be alot faster?

(sorry if that doesnt make much sense, i just woke up :? )

Oscar
Gnoblar
Posts: 9
Joined: Tue Jun 21, 2005 12:22 am

Post by Oscar »

Chris Jones wrote:doesnt that run slower? seeing that it is for games, and if u need something to be as fast as possble, and ur using a pointer (or reference), surly the pointer would be alot faster?

Well good morning sunshine! :D


Does it run slower? Not necessarily. Since the iterators are part of the actual language rather than a seperate class implementation (see Java iterators) the compiler has a lot more options for doing optimizations.

In a scripted or similar environment that uses garbage collection the reference to the array can be locked so that a) it doesn't get relocated in memory and b) it remains valid. Because of this less checks need to be done during the iteration.

If the code is being compiled to native code that will most likely depend on the implementation of the code generator so there's really no clear answer. It could implement the same mechanisms as with the scripted environment or it may just treat it as a pointer as in C.

However if you are iterating over that many elements of an array or linked list chances are the amount of time spent incrementing the iterator and doing bounds checking will be insignificant to the other operations performed.


Also keep in mind that once your for/foreach/do/while loop grows to a certain level of complexity (arithmetic, calling member functions, nested loops) the difference in performance (native code vs. iterators) may become negligable - mostly due to the amount of register spilling and reloads that need to be done.

Mawen
Halfling
Posts: 54
Joined: Wed Jun 04, 2003 7:34 pm
Location: Calgary, Canada
Contact:

Crazy projects unite!

Post by Mawen »

It's interesting to see your new language project. I wish you success.

I have my own ambitions in making games easier to mod. My approach targets the architectural constructs in a game. My goal is to provide a framework that would allow a modder the ability to tweak game objects and scripts, online, with support for distributing these changes during a game. I want to make introspection and reflection of business obejcts open to the user of an application, if only in modding mode. I want to keep the object structure conceptually pure, extending objects with decorators for all sorts of purposes, and to make everything open to events as well. No writing callback methods or passing delegates around, because the observer pattern is inherent in everything.

This project, called Dycen, is a language neutral glue-framework and distributed object system. If my webserver hasn't overheated yet, you can find out more about it at http://dycen.melsib.net:8080.

I also plan to assimilate Ogre into this glue as one of the first reflected components. I plan to create language bindings for C++ and a scripting language (haven't decided yet, maybe python) to start, and maybe D and some other scripting languages later, if things take off.

I guess my only comment to you is, how much will a new language help you, and do you have the resources to complete such a thing? While languages are nice, IMHO (I don't really have experience as a modder), I think modders would benefit more from RAD rapid-prototyping tools, and small game developers (including the "initial" mod of the game) would benefit more from a framework that makes designing, using and implementing solid and consistent architectural patterns, and distributed objects.

Have you seen DigitalMars' D? It is a brilliant and awesome uplift of C++, but despite many years of effort, it hasn't really been able to reach the point where it can take off yet, and it doesn't look like it will happen anytime in the short term (although I suppose it faces a lot more challenges for adoption as a compiled language.)

Again whatever you decide to do, good luck with it.

Oscar
Gnoblar
Posts: 9
Joined: Tue Jun 21, 2005 12:22 am

Re: Crazy projects unite!

Post by Oscar »

Mawen wrote:It's interesting to see your new language project. I wish you success.
Thanks. It's definitely a long term project but hopefully my choice of toolsets will help eliminate some of the headaches common with creating a new compiler.

Dycen looks very interesting and I can already see some very useful possibilities with a framework like that.
Mawen wrote:I guess my only comment to you is, how much will a new language help you, and do you have the resources to complete such a thing?
I definitely have the resources and background to see it through completion. I've written several compilers in the past - some for existing languages others for small to medium sized languages - along with code generators for various packages (LCC, BCC, TinyC).

As for how much it will help game developers and modders I can't really give you an answer until the package is done so developers can evaluate it. There are a lot of good packages out there such as Angel Script, Lua, and Python all of which are high quality so at least I know what the expectations will be.
Mawen wrote:Have you seen DigitalMars' D?
Yes, I've actually had the pleasure of using it in a smaller project some time back and was quite impressed with it. I think people are a little weary about switching to an enhanced or extended version of a language for application development because it rarely if ever has decent size userbase and may limit the use of an existing codebase (internal or third party).

User avatar
kikito
Gnoblar
Posts: 11
Joined: Wed Dec 11, 2002 7:18 pm
Location: spain

Post by kikito »

Hi Oscar,

I'm also interested in scripting & compilers, and I had an idea similar to yours, but never had the time to put it in place.

What about the 3 best (IMHO) features UnrealScript offers for games? I'm talking about the Class/State/Member hierarchi, Thread transparency & network integration.

1. Class/State/Member hierarchy
In Unrealscript classes can have "states" - sets of rules & data. States are inherited via certain rules. Only one state is active, and there are commands for switching the active state. For example, the "Guard" class has "Idle", "Chasing", "Hiding", etc.

2. Thread transparency
In Unrealscript you don't see "threads". Instances execute their code until they reach certain points (for example "execute this animation"). In that moment the next instance takes the baton, and executes its code, etc. This is done in a transparent way (you don't have to use a "yield" directive like in LUA)

3. Network integration
Clases have "server members" & "client members", with a degree of "importance" (so the main ones are sent first & the rest are sent if there's bandwith left) & a "codification method" (ints are sent as chars sometimes). Once they are stablished, the client/server architecture kind of "just works".

Just my two cents... ;)

Oscar
Gnoblar
Posts: 9
Joined: Tue Jun 21, 2005 12:22 am

Post by Oscar »

Hello Kikito,
kikito wrote:1. Class/State/Member hierarchy
In Unrealscript classes can have "states" - sets of rules & data.....
The proposed delegate collection operates in a similar fashion as UnrealScript's events with only a few minor differences (and several enhancements).
kikito wrote:2. Thread transparency
In Unrealscript you don't see "threads". Instances execute their code until they reach certain points....
If you are referring to "latent" functions then yes there will be a modifier to indicate a function requires exclusive access. While minor support will be supplied in the runtime anything other than a generic interface or support will be deferred to the developer. It's definitely something that needs to be addressed though.

kikito wrote:3. Network integration
Clases have "server members" & "client members", with a degree of...
This is purely a runtime requirement issue and is something that shouldn't be dictated (or handled) by the language. Like threading this is something that needs to be dealt with. As a basic part of the runtime integration and binding between native languages and the one proposed needs to be flexible.

Of course a lot of issues concerning the runtime are pure assumption rather than an explicit requirement. One example would be a base class implemented natively. If you want to inherit from that class the runtime has to know how to create it, how to access it's methods, etc. Necessary? probably not. Highly desirable? Absolutely.


Definitely something I need to look into.

Oscar
Gnoblar
Posts: 9
Joined: Tue Jun 21, 2005 12:22 am

Post by Oscar »

I should also note that a new addition to the proposal is a meta data construct. This will allow runtime/project specific information to be associated with classes without requiring the compiler or language to be changed.

You will be able to declare a meta definition to describe the type of information the runtime requires. Meta definitions contain only data. This is the opposite of interfaces that only include methods. Because they are declared in the same fashion meta definitions can benefit from inheritance.

Example:

Code: Select all

public metablock MyData {

	// Settings and their default values
	useActorClass = "game.citizens.GhostActor";
	allowSniping = false;
	maxClones = 10;

	// Declaration must supply this value

	nodefault actorName;
}


class A {
	
	MyData [i]label[/i] {
		actorName = "Gomer";
	}
}
In the above example "label" is optional when only one instance of the same metablock is used. All meta data is compiled and stored with the class it is used in. Metablocks and also be nested and are accessed in the same fasion as struct and class members.

The metablock could easily be done with existing class and interface constructs but this is more intuitive and expresses the block as a unique type.

Post Reply