next »

[rogerlevy]

Hi, TIGForums.  I'd probably still be considered lurker status up til now (I've only posted a couple times in the music section), so, "Hi!"  I really love this community by the way and hope to enjoy a lot of correspondence and of course watch as the great games multiply and multiply...  but, anyway, I have been working on something that I'm now starting to question if it is worth my time in the short-term, and I want to see if others think this is cool ...

Right so about the subject, it's about game making tools (the self-contained kind), particularly the idea of there being a new one, and I'm asking anyone who thinks about this or is interested in the idea of one... and I'm aware of Game Maker, it's an excellent program actually, and there are countless others; it seems Python is gaining ground and Blender, XNA, 3DGS, Blitz, and even C++ are all popular choices.  All of them are fine. 

At some point I reached an apex after trying a lot of systems and I thought I could do it better.  I began work 9 years ago.  I've done some toy systems and some near-serious attempts - this time though the work is culminating into something that could be a mature finished product.

I was wondering if anyone would be interested in something like this ... of the features you'd expect, it currently has many of them, and *will* have all of them most likely, but let me try to describe some its special features, because these features are those that I have not found in other systems (obviously why I started this insane project...), so I'd like to see if people really feel this is needed the way I have.

Here are the unique features of this system. Note I will mostly be comparing this to Game Maker, though other programs have influenced my design as well.

• Managed loading time.  My system embeds game resources into the exported executable and  does not have to do export and reload an exe (which does a lengthy decompression procedure) to test, thus it is much faster at loading games than Game Maker. Furthermore it is designed to support background loading, for when you want to decide what to load and when, and when you have a lot of data that you don't need all at once.
• Interactive testing environment - Game Maker lacks proper testing tools, this will use its scripting language in ADDITION to a set of functions especially designed to facilitate interactive testing.  You will be able to call up arbitrary testing scenarios, and tweak them to test contingencies or new ideas, without having to go through a lengthy export/playtest loop. You can also "overlay" updated code (and objects) without having to reload the entire project from the beginning, saving more time. Obviously these are all advanced functions but they will be there, ready and waiting for the advanced user.
• Low-syntax programming language.  It can be thought of as a cross between BASIC, LOGO, and assembly language.  Based on the unique and widely misunderstood Forth language.  It supports a special customized type of object orientation that is simpler, more flexible and more lenient than any other OOP language I have used. You have to type much less than languages like GML or C# and your code can be much less redundant than languages like Blitz Basic.  I'm going to maintain that Forth has matured into a very modern language that deserves earnest scrutiny.
• Designed to support a modular interactive GUI environment for creating assets. All tools for creating assets will be written in the same language as the games they help create. Customization options are therefore unlimited. The interface will be clean and simple, discouraging clutter by providing hardcore organization tools (I am a stickler for being ultra organized in my work), and most importantly the system will remember your workspace EXACTLY, to the position and customized color of every item you create on the virtual desktop.  You could say it will be a kind of mini-OS... but the idea is a complete platform that does not feel like a mere application.
• Extremely efficient low-level foundation.  For instance in the multitasker, the task-switch routine is about 15 machine instructions long (so hundreds, maybe thousands of tasks will be allowed).  The custom memory manager does not rely on the OS, does not require a garbage collector, and is guaranteed to be very fast.  Late-binding in the OOP component is extremely fast, only 7 or 10 machine instructions.  Display-lists are automatically generated for drawable assets.  The language is compiled to machine language, not slowly interpreted like GML.  There is no essential difference between game code and the code the system itself is being written in.

As you might have gathered from the "forefront" feature list, I am most interested in accelerating development by removing itty bitty bits of time from many spots in the dev cycle, and trying to make runtime silky smooth and without jerks or user delay - every aspect of this system is about speed.  But I'm also trying to come up with something that anyone could use and yet has a lot of depth to explore, partly because it has an extremely "open" programming language (in terms of "not a black box") and partly because it should continue to expand with custom modules after its initial release.

The system is being developed on Windows XP and will use: OpenGL, SDL, FMOD, and perhaps later the Open Dynamics Engine lib for physics...

I have to end my post for now.  But I'll make some more posts with more detailed and concrete examples (particularly of the language) tomorrow.

I am VERY eager to hear what others' opinions of this system are from this description I've given.  If there is anything more you'd like to know about it, please ask.

[rogerlevy]

OH boy, I'm sorry, I posted this in the wrong place.  I meant for it to be in Technical.

[andy wolff]

This sounds like a really fantastic project. If completed, I'd say it would be a great asset to development.

Good luck to you in your endeavors, good sir

[ElTipejoLoco]

I'm sure Derek or someone will move this topic in due time.

That aside, it does sound pretty awesome, and if free (or at least available as a trial with reasonable features enabled), I will be happy to tinker with it as soon as it comes out. Godspeed.

[William Broom]

It sounds great! I especially like the idea of a more flexible testing environment.

Designed to support a modular interactive GUI environment for creating assets.

I... don't understand this bit. What do you mean by assets? Like, graphics and music?

[Problem Machine]

This sounds excellent. I don't think there can ever be such a thing as too big a selection of good tools for game production, if that's what you're asking with the topic, and one as robust as what you describe would remove a lot of the limitations that make me leery of most of the existing tools. How far along are you in development?

[BorisTheBrave]

Sounds awesome. But having a "unique" scripting language is actually a turn off for me. I can see you have written a lot of things from scratch to fit your purpose, but whole languages are more complex. Plus it requires everyone to learn something new. If it's so similar to Forth, why not use that? I doubt you could improve much upon the Forth compiler.

All tools for creating assets will be written in the same language as the games they help create

This really encourages me. Any system powerful enough to write developer apps must be pretty good.

[rogerlevy]

This sounds excellent. I don't think there can ever be such a thing as too big a selection of good tools for game production, if that's what you're asking with the topic, and one as robust as what you describe would remove a lot of the limitations that make me leery of most of the existing tools. How far along are you in development?

Well, given that I've spent 9 years on it and I expect to have something usable by the end of the year, technically it's 90%, however that's taking the long long view in terms of all the revisions there have been.. work started on the latest *revision* in last October so if I am able to release something this summer, which I hope, then it's at about 50%.  That's a more meaningful progress percentage on the actual program itself.

[rogerlevy]

Sounds awesome. But having a "unique" scripting language is actually a turn off for me. I can see you have written a lot of things from scratch to fit your purpose, but whole languages are more complex. Plus it requires everyone to learn something new. If it's so similar to Forth, why not use that? I doubt you could improve much upon the Forth compiler.

It does in fact use a Forth compiler (SwiftForth) as its basis and is not completely built custom from the ground up language-wise.  I have taken a Forth and extended it, so it remains ANS compatible.  I have added many familiar features, such as structures, collections, interfaces, and some string manipulators (especially for filenames).  Also, though Forth has a rep for being terse due to being stack based, this has local variables, so you are not really missing anything (except strict type checking).  Also Forth is not what I'd consider a "hand-holding" language so I figure if what it lacks in terms of hand-holding what people cannot live without, I'd do my best later on to meet the demands in some form or another.

All tools for creating assets will be written in the same language as the games they help create

This really encourages me. Any system powerful enough to write developer apps must be pretty good.

I hope it lives up to that!  To me it's not really a big deal because I owe it to Forth for being an inherently extensible programming language. 

More on the game/tool-writing language to come...

[rogerlevy]

In this post I'll provide a preview of the OOP part of the language.

Classes are built using a pretty simple and familiar syntax, and it supports a subset of "complete OOP", for reasons that OOP as a principle is complicated enough, and I didn't want to be dealing with some of the knottier questions that I've had to deal with before in, say, ActionScript 3 (which, don't get me wrong, I love, BTW).  Here is a palette class I'm working on.  Below I'll comment on excerpts.


group class paletteset
   1 chars 50 chars ivar filename
   1 chars 64 chars ivar comment

   :m >filename   [[ filename ]] ;
   :m >comment  [[ comment count ]] ;
   :m .comment   [[ comment count type ]] ;
   :m comment!   [[ comment place ]] ;

   0 value plt

   :m construct  ( filename count )
      [[ filename place
      filename count exists? not if
         s" New palette set" comment place
         this save
      else
         filename count open dup to #1 map-file throw
         2dup drop
         count  2dup comment place  +
         @+ 0 ?do
            palette new dup this add to plt
            count   2dup plt comment!  +
            16 0 do @+ i plt color[]! loop
         loop drop
         unmap-file drop #1 close
      then  ]] ;

   protected
   : write-each-palette
      this each>
         dup >comment -1 /string  #1 write
         16 0 do
            i over &color[] cell  #1 write
         loop drop ;
   public

   :m save ( )
      [[ filename count createfile to #1
         comment count -1 /string #1 write
         this tally #1 write-cell
         write-each-palette
         #1 close ]] ;

end-class

Notice its got a pretty familiar structure.  Local properties at the top, a handful of accessors, and a constructor. The destructor is inherited here.

Now for the breakdown:

group class paletteset
   1 chars 50 chars ivar filename
   1 chars 64 chars ivar comment

At the top, PALETTESET is defined as a new class that derives from GROUP, which is a descendant of ACTOR, the basic game object class.  (This is actually temporary, I am going to change it to a NODE which is even more basic, for various reasons, but that's a tangent.)

Then we've got some local variable definitions.  Both of them are strings.  "1 chars" controls alignment. "50 chars" etc is the length. "ivar" makes a local variable that does not require you to qualify it with an object name, and it is ONLY accessible from inside the context of the class it belongs to, that is, when its context is available.  In the system there are NO "public" local vars, which is kind of an oxymoron if you think about it.  Accessors are the way to go and coming right next is an example of them:


   :m >filename   [[ filename count ]] ;
   :m >comment  [[ comment count ]] ;
   :m .comment   [[ comment count type ]] ;
   :m comment!   [[ comment place ]] ;


There's a lot new going on here but I'll try to break it down.

These are really psuedo-accessors, because you are not restricted to any particular syntax such as "get" or a "set".  I'll break it down line by line. 

   :m >filename   [[ filename count ]] ;   

This provides access to the local filename to the outside.  ":M" is the catch-all method defining keyword.  You use it to define methods (which are ALWAYS public), *override* methods (all methods are LATE-BOUND), and define and override methods inside and from interfaces.  Next we have the name of the new accessor, and then we have a tiny bit of code in between a pair of double brackets.  Double brackets "open and close" objects.  They allow access to the IVARs.  There are some reasons for this syntax but one benefit is it allows some routines to be faster by not requiring you to use IVARs, which are slower than another type of local var, IFIELD.

>FILENAME has a prototype but it is not noted or required to be typed.  In this language and Forth you do not have to list parameters by name, although I make a comment of it 99% of the time, and you can have function-context-locals if you wish.  I have documented the prototype for >FILENAME in the base class COMMON.  >COMMENT is very similar .COMMENT prints the comment associated with the palette.

In the language 99% of tokens or keywords (called simply "words") are processed from left to right, with little exception.  So we are taking FILENAME and executing COUNT on it, which gets its length.  By the time we get to the semicolon, we will return the address of a string and its length.  In this language you can return more than one parameter.  Semicolon basically compiles a return instruction.

.COMMENT means "print comment" and COMMENT! means "store comment".  So you can print the comment into the debug terminal, or by saying "<fontname> TEXT[ .COMMENT ]TEXT" you can print it using texture-based fonts to the graphics window.


      0 value plt

Nothing too interesting here.  Basically it's a psuedo-local variable.  In Forth you can redefine words indefinitely and it will not complain, so creating a variable with a "local sounding name" is a simple way of doing a local var with the added advantage of being able to debug a word it is used in without requiring a step-debugger ...


   :m construct  ( filename count )
      [[ filename place
      filename count exists? not if
         s" New palette set" comment place
         this save
      else
         filename count open dup to #1 map-file throw
         2dup drop
         count  2dup comment place  +
         @+ 0 ?do
            palette new dup this add to plt
            count   2dup plt comment!  +
            16 0 do @+ i plt color[]! loop
         loop drop
         unmap-file drop #1 close
      then  ]] ;

This is a constructor.  Notice the parameters listed in the declaration.  That's really just a comment, for reference, and the compiler does not use it.  This word loads a palette definition from a file.  Notice that it is quite short and small.  I'm not going to break it down step by step, but many keywords should be familiar or easy to guess, like IF, SAVE, ELSE, EXISTS?, THROW, ADD, COLOR[]! (store color), DO, LOOP, and CLOSE.  It supports exactly 16 colors per palette, this is a "for now" feature and was done on purpose.  MAP-FILE reads a file into temporary memory.  THEN is a quirky Forth thing, it closes an IF definition (so it is the same as ENDIF).  Comments on THEN are welcome ... the scripting language could provide ENDIF if people cannot get used to THEN.


   protected
   : write-each-palette
      this each>
         dup >comment -1 /string  #1 write
         16 0 do
            i over &color[] cell  #1 write
         loop drop ;
   public

   :m save ( )
      [[ filename count createfile to #1
         comment count -1 /string #1 write
         this tally #1 write-cell
         write-each-palette
         #1 close ]] ;

The word declaration between PROTECTED and PUBLIC cannot be accessed outside of the class context.  You can "peek into" the class with a debugging word, FROM:, in order to test it (of course), but mainly, it is designed to be used when you want to break down a method into sub functions, and to make it clear that it should not be used outside of a [[ ]] pair.

SAVE was called further above to create a new paletteset.


end-class


Fin.

I hope that this has given you a good glimpse into what this language is like.  My only disclaimer on this is, if the language is hard to read, take my assurance that the game-scripting language will be simpler and less "low-level", which should be the point.

Comments and questions welcome.

[Hideous]

 

i haven't read your entire post but MAN
i can't read that language

[ElTipejoLoco]

I could, but only after finishing reading the explanations accompanied by it.

I'm enthralled by what's been done so far, but yeah, it does need to be a tiny bit more user-friendly. But you made it sound like that's the goal once the game creation setting settles in.

I'm curious as to why you're forcing a 16-bit palette right now, though. I could take an uneducated guess- and I will: Will you be including a small mini-demo to show us what can be done with this once you're done?

[rogerlevy]

It sounds great! I especially like the idea of a more flexible testing environment.

Designed to support a modular interactive GUI environment for creating assets.

I... don't understand this bit. What do you mean by assets? Like, graphics and music?

That's right, basic assets such as graphics, animation, tiles, and maps, but also more high-level things such as game character definitions, and uniquely, documentation, which does not go into the exported game.  No music editor (at least at first, though no promises). The main BG music methods will be those that FMOD directly supports - streaming mp3's, MOD's, and MIDI's.

[rogerlevy]

I could, but only after finishing reading the explanations accompanied by it.

Good, then I guess I didn't do a terrible job.

I'm enthralled by what's been done so far, but yeah, it does need to be a tiny bit more user-friendly. But you made it sound like that's the goal once the game creation setting settles in.

That makes me glad.  Yes, user-friendliness is definitely in the "high priority" category.  Ideally the only times a person would need to even touch the scripting language are:
1) to do advanced debugging,
2) to develop custom actor classes,
and 3) to develop new extensions to the dev environment.

EDIT: Doh. Didn't even address the language itself.  Yes this code I showed would not mean to be understandable by a "designer type" user.  The "design language", or the part that would let you script game behavior, would be explained along with a subset of Forth, relying more on variables and locals than I typically do at the low level, allowing people to skip past some of the more esoteric features, like data stack shuffling.  But the power of Forth will still be there for those trying to get the most speed or who develop a taste for it.

I'm curious as to why you're forcing a 16-bit palette right now, though. I could take an uneducated guess- and I will: Will you be including a small mini-demo to show us what can be done with this once you're done?

The reason that palettes only have 16 colors is because, as you guessed, I'm making an example game, and it will have retro-type graphics.  I like to design sprites in 16 colors because they store efficiently and 16 colors is more than enough.  Everything gets converted to hi-color textures so the palettes are not even used in-game but only in the editor.  At least for now.

[rogerlevy]

I just wanted to say before I went to bed that it is really encouraging to get such a positive response and I thank all who took the time to read about it.  I didn't know that this would actually be *wanted*, so that's nice.  Of course there is a major amount of stuff that I have left to flesh out in it so I'll probably spend time working on that rather than continue to blab on about it.

Thanks again guys.

[ChevyRay]

Two thumbs up on this. This sounds incredible, and I can't even fathom how much dedication it must take to develop something like this. You've got me watching, anyhow; good luck!

[Gold Cray]

The shear amount of stuff involved in making games in C++ has started to annoy be a bit, and python is cool but really slow. I've considered trying game maker again, but it's not cross-platform. I'm looking forward to seeing where this goes.

[andy wolff]

I've considered trying game maker again, but it's not cross-platform.

not sure this is entirely true. if it is, it isn't for long

[Bennett]

Here is my 2 cents: you are using only open-source APIs that are cross-platform. If you could release simultaneously on Mac, Linux and PC, you would instantly have a massive fanbase of people defecting from GameMaker, who are really dragging their feet on the mac port. In fact, I won't be surprised if they don't release their mac port for another six months or a year. People desperately want to release indie games for all three platforms.

The extensible idea is a really good one, by the way. I hope you figure out how to make it easy to download and install editor plugins, so that you can browse and obtain a map editor or a sprite animation package without leaving the GUI.

[dbest]

Ofcourse there is a need for another game making tool.

The more user friendly your tool is, the sooner it will be taken up by many. From your initial post, the comparison is mainly against GameMaker, so I am assuming that it would be a better game making tool then GameMaker.