next »

[Bad Sector]

Updated, read the end of this post

These days i'm working on a system that sits on top of my UndeadScript scripting engine and SDL, that provides a simple scripted environment for creating 2D games. That system, is named ssig (from Simple System for Ideal Games - I originally stood for interpreted, but i disliked since it's not the game that it is interpreted but the script... so i replaced with something less awful (Internet), but awful nontheless - if anyone has some better ideas for what to use for I, just tell me :-P - after a discussion, i decided on ideal).

The homepage is located here.

I spent a great amount of time to make this, so i would like to get some comments :-P. I wasn't sure if i should post it here or in the feedback forum, but i decided against the feedback forum since the header says it's only about games. Plus, this one is about development things.

For starters, this tool currently is in very early stage. In order to do something, you need to edit the scripts/main.us file (no other files there) and put your code there. There isn't any IDE or other development environment, but you can use any code editor you like. For syntax highlighting, you may want to use Java or C++ since the language is very similar (it's more like Java than C++).

At the site, you can check the API documentation, an example script and of course download ssig. The archive contains an offline copy of the API documentation and an introduction to UndeadScript for people that already know some other C/Java/JavaScript/PHP-like language.

Now while i mentioned that this is about games, there aren't any games made with it - currently. The idea is to provide some basic foundation first and then try to make a game with the tool.

Of course the API provides functions to check the state of keys, mouse and mouse buttons, load and draw images and do other stuff, so a simple game that doesn't require much, can be made.

At some point, a development environment will also be provided that has a script editor and several modules (such as a tile map editor, event editor, etc) which provide additional functionality for creating content - and the necessary functions in the API to load them.

So, well, i need your feedback :-P.

Update: I renamed ssig to SiSIG and launched a site, http://www.sisig.info/ about it. A new version of SiSIG is available, WIP-3, which includes some additional functionality. Also a Linux binary is now provided (full source to come soon).

In the site, a SiSIG-dedicated forum can be found (where questions, feature requests, bug reports, etc. can be posted) and a game list, which currently is empty (:-)) but once you have something you can submit it there for review (so i hope that soon new stuff will be added there).

Also the I now stands for Ideal not Internet. Doesn't really make much more sense now, but it's less confusing :-). And no, i'm not going to change it again... :-P

(at least not soon)

[PoV]

I've already mentioned in the past that I like it's "normal" C++/Java'isc syntax, versus the "conventional wisdom" of using a seemingly lighter weight scripting language/one that already exists.

I'm not sure though, that a mere graphics API on top of UndeadScript is that attractive a core development platform, yet.  Like everyone else would say, why not just use C++/Java and a graphics library?

I do see some potential in building an easy "learning to make games" stepping stone platform, streamlined easy workflow and all.  One of the few things I look back on QBasic and think, damn, "screen 13" to set my graphics mode was nice, with "pset(x,y), color" a straightforward way to draw pixels, and easy.  Nice and simple.  SDL and Allegro do a fine job these days though giving C/C++ that sort of simplicity, but I think you get the point.

And just a personal note on library naming style.  If I'm encouraged to use lower case variable names, you might want to distinguish system functions (Image is good, but "graphics" might be better off as "Graphics", though I see the argument for function name versus type).  And I don't think dot syntax is *that* bad ( brick.draw(x,y); vs. draw(brick,x,y); ).  None the less, all I'm really getting at is putting some care in to coding style.  Encourage positive code design. 

As I see it, the power of a scripting language is to simplify working with complicated systems found in a sophisticated engine (i.e. game engine or genre middleware).  Making red door in red room connect to red door is green room, or red switch activate orange lift.  That sort of thing.  With several more uses in menu layout and flow, etc.

[Bad Sector]

Thank you for your reply :-)


Currently i only have these basic functions there because that's what currently i have coded. I decided to release a version as soon as i have something to show so people can give me feedback. As i said in my original post, my plan is to make a full development system, something between Game Maker and BlitzBasic, but i want to put the foundation there first.

When it comes to QBasic and "screen 13", i had in my mind and many times when i wanted to test a simple thing, i wished i didn't had to go through the hassle to create a new project, drop SDL in there and try that (and still isn't that easy - SDL doesn't provide much functionality... actually there isn't even a "put pixel" there). I didn't had this in my mind for ssig, though, but now that you mention it, it can be used for such things (although pixel plotting is *slow* - i only added it to create "precalculated" images in load time).

Learning to make games... that was one motive and just today i realised that it's a good thing. I posted the word about ssig in a Greek forum i visit where it's mostly games (but there is a "programming" forum too), and someone made this - although i'm not sure what this is about :-P. Others were very interested too :-).

Also two words on the naming and coding style... for naming i use Java's naming style, where functions are named in lowerCamelCase and types in UpperCamelCase. I think it's a simple style to use. For coding i decided to use a procedural interface for simple things, like drawing an image, setting graphics mode, getting events, etc. For more advanced stuff (or stuff that feel awkward using with functions), i use objects.

A 2D game engine isn't usually about images, but about sprites. Images are low level citizens there. When it comes to sprites, when added, they'll be objects. So you'll type "hero.draw(x, y)" instead of "drawSprite(hero, x, y)". This might look a little inconsistent though, so i'll think about that part again, but i believe that keeping a procedural API for simple tasks is a good idea.

[PoV]

SDL doesn't provide much functionality... actually there isn't even a "put pixel" there).

Oh yeah, that's right.  I guess that's the reason I always fall back to Allegro for my quick prototyping graphics library, 'cause I can draw pixels/lines/circles/images stock.  Yet I find myself in SDL land for OpenGL wrapper, as it's more stable.

Learning to make games... that was one motive and just today i realised that it's a good thing. I posted the word about ssig in a Greek forum i visit where it's mostly games (but there is a "programming" forum too), and someone made this - although i'm not sure what this is about :-P. Others were very interested too :-)

That's good to hear.  A friend of mine started a LUA based development platform way back when, except it imposed a silly "no resolution changing" restriction.  It did surprisingly well, even though resolution changing wouldn't have been much to add.

Back on the note of positives from QBasic, I suppose the language could develop in to an extendable language.  If an incredibly basic program is this.

Code:

// set graphics mode
graphics(640, 480, false);

Image brick = image("data/chocolate1.bmp");

draw(brick, 10, 10);

while (!key[KEY_ESC]) {
}

// shutdown graphics
graphics(-1, -1, false);

Then why not allow us to layer flexibility on top.  The above being a non back buffered example.  The following being one.

Code:

// set graphics mode
graphics(640, 480, false);
graphics.useBackBuffer();

Image brick = image("data/chocolate1.bmp");

while (!key[KEY_ESC]) {
	draw(brick, 10, 10);

	graphics.copyBuffer()
}

// shutdown graphics
graphics(-1, -1, false);

The next using Z buffering.

Code:

// set graphics mode
graphics(640, 480, false);
graphics.useBackBuffer();
graphics.useZBuffer();

Image brick = image("data/chocolate1.bmp");

while (!key[KEY_ESC]) {
	draw(brick, 10, 10);
	
	draw(brick, 25, 25, 10);

	graphics.copyBuffer()
}

// shutdown graphics
graphics(-1, -1, false);

The next adding rotation and scaling.

Code:

// set graphics mode
graphics(640, 480, false);
graphics.useBackBuffer();
graphics.useZBuffer();

Image brick = image("data/chocolate1.bmp");

while (!key[KEY_ESC]) {
	draw(brick.rotate(0.25), 10, 10);
	
	draw(brick.scale(2).rotate(0.1), 25, 25, 10);

	graphics.copyBuffer()
}

// shutdown graphics
graphics(-1, -1, false);

And so on.

graphics.fullScreen() to go fullscreen.
graphics.usePerspective() to use a normal perspective drawing.
graphics.useOrtho() for normal no perspective drawing.
graphics.useMatrix( M ) to use a custom transformation matrix.

And the list goes on.  "draw( ... )" takes transformable object types, be it an image, an image with a rotation, a 3D model, or so on.

Just some ideas.

[Bad Sector]

These are nice ideas, although there is double buffering (actually it's the only option - you have to call update() at the end of each frame to flip/copy buffers) and i'm not planning to put 3D in there. However i've got the point and i think these are nice ideas (still not in the OO-fashion... draw(brick.rotate(5), x, y) would possibly be drawRotated(brick, x, y, 5) - sticks with the "low level is procedural" idea :-).

Also the system will be extendable via external dll/so/dylib files, so 3D stuff could be possible as modules.

[PoV]

I'd consider pushing more "features" in the core library.  I think Z buffering is an interesting proposition to introduce early on, and giving the flexibility to arrange in 3D space.  Oddly, as far as a learning tool API is concerned, I like the "no backbuffer" step.  It makes it easier to demonstrate why we do it, rather than a user just "taking our word".

I suppose there's nothing stopping you from doing both member "draw" and "rotate" functions, it just depends on your goals.  In fact, the frontend "draw" and "drawRotated" functions could call "myImage.draw(x,y)" and "myImage.rotate(angle).draw(x,y)" respectfully.  I think there's nothing wrong teaching object oriented concepts early, as it really is a beneficial design practice.  They don't have to do it in their code design initially, but seeing this dot syntax may encourage them to ask some questions about their designs.

Hehe, now I'm thinking API design. 

Right now I fall back on Allegro when I want to pound out an idea.  I take selections of my engine's math library, and power through the problem or concept.  The issue with Allegro is it's very antiquated (DOS era) and not the most elegantly designed API (little inconsistencies in underscore use).  But, it covers all the bases with line draw code, circles, images, etc.  I do have a library that wraps SDL+GL+DX, but it was generally rushed just 'cause I needed something portable.

I suppose it'd be nice not to have to use Allegro, one day.

Don't mind me.  Just muttering out loud. 

[Bad Sector]

Oddly, as far as a learning tool API is concerned, I like the "no backbuffer" step.  It makes it easier to demonstrate why we do it, rather than a user just "taking our word".

Well, i'm not doing for so unexperienced users :-P. I'm just trying to make it easy for people to pick it up, even if they have made no games at the past. At minimum, i would like people who learned a bit of programming themselves by trial-and-error, or people who just started learning about programming in their school or university. Still it's the minimum and the guy i mentioned above is in the first case (learned a bit of programming himself).

I suppose there's nothing stopping you from doing both member "draw" and "rotate" functions, it just depends on your goals. In fact, the frontend "draw" and "drawRotated" functions could call "myImage.draw(x,y)" and "myImage.rotate(angle).draw(x,y)" respectfully.

Well, technically it needs more work from the native side. Also i haven't tested well enough the native side of "garbage collectable" objects and this part has a few limitations. Last, object addressing (blah.bleh) is a little slower than global function calling, although that's the case with all scripting and high level languages (even sun's java with it's fancy auto-optimizing JIT has this).

But most important, i am fond of using procedural APIs where there is no real need for object oriented programming. IMHO brick.rotate(5).draw(x, y) has no advantage over drawRotated(brick, x, y, 5) - actually it imposes an optimization problem because brick.rotate(5) seems to create a new object each time is called. A temporary object could be made, for sure, but what if brick.rotate(5).scale(3).draw(x, y) was used? At this point i'm starting to thinking about a dynamic array of "cache" objects, but things are getting rather ugly and still there is the issue of making new objects on the fly, too much indirection and lots of procedure calls.

Classes could be used for other higher level or more intuitive for OOP things. For example, i find it masochistic to not use an object oriented design for a GUI system.

I think there's nothing wrong teaching object oriented concepts early, as it really is a beneficial design practice.  They don't have to do it in their code design initially, but seeing this dot syntax may encourage them to ask some questions about their designs.

Note that although i am interested in this to be used for learning game development, i'm not interested in teaching programming. Besides, from my experience, it's easier for people to think this:

move(ball, x, y)

as "move the ball to x, y" rather than

ball.move(x, y)

Also keep in mind that programming techniques and patterns are "holy areas" in programming where everyone has his and her own opinion on what's right :-). UndeadScript can use both procedural and object oriented methods and i'm just using what i find right. However, anyone can wrap my functions to classes if he feels that using a pure OO system is superior.

Personally i'm against OO purity and procedural purity. I prefer a mixed approach.

The issue with Allegro is it's very antiquated (DOS era) and not the most elegantly designed API (little inconsistencies in underscore use).  But, it covers all the bases with line draw code, circles, images, etc.

And not only that, but lots of stuff have made with Allegro (i've even used it for a 32bit DOS-based GUI i was making some years ago), which proves that API design it isn't really that important - in fact too much API design ("overengineering") is considered a bad thing.

Don't mind me.  Just muttering out loud. 

Ancient Greeks came up with all those philosophies by exchanging their thoughts, so no matter if we agree or disagree, it never is a bad thing to hear others' opinions.

Besides, if i wasn't interested on what others have to say, i wouldn't release it so early :-).

[PoV]

But most important, i am fond of using procedural APIs where there is no real need for object oriented programming. IMHO brick.rotate(5).draw(x, y) has no advantage over drawRotated(brick, x, y, 5) - actually it imposes an optimization problem because brick.rotate(5) seems to create a new object each time is called.

You're right.  I neglected my lovely optimizing C++ compiler I always have available to me.  I actually starting consider an API, and that unknowingly bled over in to this discussion. 

Technically speaking, since you did write the scripting language, if the syntax was notable, then you could create some clever munging of the entire instance+function that turns the parameters to arguments.  It is still more work processing that than mere comma separated functions, but it depends if ordering and omitting arguments are important to you.

Personally, I'm rather tired of dummy arguments when they're a certain value 99% of the time.  Akin to a nasty Windows API program, where you need to populate a few structures to create a window.  Yuck.  I'm big on function overloading and using default values where possible.

Well, i'm not doing for so unexperienced users :-P

Alright then. 

I've toyed with the idea of creating a "code processor" that generates C/C++ code, that can then be fed in to GCC or CL.  Essentially, fix my "problems" with the language. Some readability things, word operators ("DOT" for dot product (r = x DOT y), situations where a symbol isn't functionally clear enough), adding singleton and other pattern keywords, a few things from those new C++ standards (vector<vector<int>>), and so on.  I use makefiles, so it's not much effort for me to add it to a process.  And the tool could always launch/pass arguments to the GCC itself (as GCC already does with CPP, LD, and so on).

But my ideas can be crazy sometimes. 

[Bad Sector]

If i'm not mistaken that's what GNU Pascal and GNU Fortran (the gfortran part) does: converts their source code to gcc (c compiler) source code. So it's not that crazy :-P.

[PoV]

Not so much crazy in concept, but crazy for considering doing it.

[Bad Sector]

New version in a new dedicated site, http://www.sisig.info/, with a new name (SiSIG), game submission (for the games list in the site) and a shiny new forum. See the first post :-)

[Bad Sector]

Yay, someone made a game (Balloon Xeskiser) with SiSIG 0.1 WIP-5 

The above archive contains the original package (which was hosted in rapidshare) with linux and freebsd binaries for SiSIG added. That's the only difference between the original and the my repackaging.

The author is Dimitris (jim) <something> aka Toublo (i don't know his last name :-p). He is a new promising programmer and with the development of this little game, he helped me to find and fix many bugs with SiSIG.