Creating a prototyping framework

Miscellaneous Topics
#1

I don’t seem to get as much time to program recently, so I only tend to get short stints inbetween Real Life interupting things. And while Java is nice and all, it’s not idea for rapid prototyping (eg. for Ludum Dare 48 hour compos). In particular the pygame-based entries for Ludum Dare are getting more sophisitcated, and getting there quicker.

So I’m interested in creating a rapid prototyping framework for quick 2d game experiments. Ideally I’d like something where I can get a window with sprites/text/sounds etc. up and running in seconds rather than the hour plus it takes when setting up a Java project with all the required libraries from scratch.

General requirements I’m thinking of:

  • Really quick project setup
  • Handles window creation, drawing, input and sound with a really simple api
  • Rich set of drawing operations (sprites, rects, lines, circles, filters, shaders)
  • Collision primitives (circle, AABB, orientated rect, line, capsule)
  • Really simple game settings persistance
  • Minimal boiler plate code
  • Quick deployment as exe, mac bundle or webstart

What I’m currently leaning towards is taking a suitable JVM language, bolting that on to LWJGL and writing a small framework to make the whole thing ridiculously easy to use. Current favorites I’m eying up are JRuby and Groovy, Ruby because it’s quite an attractive language (IMHO) and JRuby is very mature. Groovy because it allows a smooth transition from Java since IIRC most Java code is also valid Groovy code, but as a downside it’s quite verbose.

Random questions:

  1. If this existed, would you be interested in using it?
  2. Any preferences on a VM language to build this on?
  3. Any missing features from the above?

Cheers

#2

IMHO [a nice framework] is more valuable than [a nice framework + some embedded language].

To introduce scripting in Java, you can use Janino, and compile stuff on the fly, with ‘java native’ runtime performance.

A tiny ‘IDE’ around that and that would be everything I’d need (although that might not be what everybody else needs). That IDE/editor would have a focus on items in the game, with a tree/hierarchy to attach stuff to it, like inventory, triggers, behaviours, maybe flow diagrams for finite state machines of the AI… something that’d allow to do a quick mockup AI, which is still (IMO) one of the hardest parts in a game, as Java is just too verbose for that.

#3

Further, having seen how cough some community projects cough currently are headed for ultra leet engines, and gameplay is nowhere to be seen (or even discussed) I think that if anybody should work on this, it should be slow by design. (rather long sleeps in the main loop) :persecutioncomplex: Just to prevent the innocent bystander from diving in the code and optimizing anything, before the darn thing is fully functional and tested.

the above example is more like a point I’m trying to make than a fully thought through advice