tung / quipkit Goto Github PK

Internal libpng error messages are not reported to Lua. Error messages in the Lua/PNG bindings should be made more informative by adding libpng's error messages.

Self-explanatory. If not too much effort, the PNG library could be tied in with the SDL surfaces to make said surface support more useful.

Quipkit should be able to load a PNG image and then show it on a simple OpenGL face.

As the title says. Important because SDL is used to demonstrate lots of things.

The main goals of Quipkit have shifted and morphed over time. First it was a Sphere replacement. Then it was a Sphere alternative. It's not Sphere, or ika, or Verge, or RPG Maker. It aims to inject bold, different new ideas into indie RPG development. It elevates tools to first class citizens in making RPGs. It has resources and separates RPGs into game states.

What is Quipkit?

This question deserves a lot of thought, since it reflects how the word is spread, who it's spread to, who should be using it and, more importantly, who shouldn't. It also gives form to the project itself.

Whatever the answer is, it should be reflected in the documentation, both online and in the software itself.

Preferably something that can be made to work in OpenGL. Text is rather important if you're out to make an RPG.

Currently, game.lua only handles rudimentary SDL and OpenGL setup and some basic game loop logic. There is high demand for this to be improved.

game.lua should be enhanced to include basic 2D sprite drawing, and also abstract away most of the details of using SDL, OpenGL and libpng.

As mentioned before, the editor will consist of a server and client processes representing launched tools.

Fork is needed to spawn tools as client processes.

Pipes are needed for the client processes and the server to communicate.

This functionality should be accessible to the editor somehow; most likely through Lua bindings.

As the title says, Quipkit should be able to build under Windows.

As a starting point, the editor should show a GUI window under Linux.

A code editing tool should be available that can load and save Lua scripts, allowing the user to edit them.

This tool should be configured by default to work on certain types of files from the editor.

This tool should also respect the basics of the client/server editor protocol agreed to earlier.

What the map engine is able to do determines how the map file format comes out, so it's important to hammer out what the map engine can and can't do.

Nothing's set in stone, but a small list of major features would really help down the track.

quipkit was started on an Arch Linux computer. Development will continue on an Ubuntu Linux computer, since running quipkit in Arch caused X to crash for no discernible reason.

quipkit should be adapted to build and run on the new Ubuntu system.

Once up, gamelets and gamelet instances in the stack will have explicit state. It should be possible to save and load this state with as little code as possible, in the form of a save file (maybe even a save file resource).

Both PNG.RGB and PNG.RGBA evaluate to Lua nil. They should have explicit and distinct values.

http://www.spheredev.org/smforums/index.php/topic,3897.msg55431.html#msg55431

I copied the test folder to go and tinker with things, and I already have a suggestion: could you make the Quipkit binary check what LUA file is passed as an argument, so I can start there? That's a bit easier than constantly editing main.lua in the root every time I want to try a different project (or starting point)...

A Code::Blocks project needs to be made for the Quipkit editor, and it needs to build and run at the very least, like its Linux counterpart.

There are more assumptions than there should be in the SDL bindings, e.g. many functions assume that the table they get is on top of the stack (implicitly at index -1). This makes them quite fragile.

They should be replaced with explicit code to remedy this.

Building in Release mode in Windows will build everything correctly, but the Lua stubs don't load those, instead using Debug-built bindings. This should be changed so that Release builds load Release libs, and Debug builds load Debug libs.

Right now, luaL_unref calls are within a redundant function which is called by both WaitEvent and PollEvent. This freeing should really occur as soon as the user data within the event is reified from the SDL_Event struct.

tl;dr Remove repeated code.

Or "game state stack", whatever you want to call it.

It should be possible to add instances of game states/"gamelets" to a stack. The default Quipkit game loop code should run the update and draw functions of the gamelet at the top of this stack.

This comes off the back of coming up with the map file format. It should be possible for a person other than me (tung) to use the map editor. This will probably just mean a bit of polish.

Continued improvements after this ticket is closed are encouraged.

Right now the luasdl bindings are hand-made and woefully incomplete. This stops people from using Quipkit right now from making demos. Future development of the bindings would also hinder other parts of the Quipkit project.

More complete bindings for Lua and SDL should be integrated into Quipkit to solve these problems.

Right now, luagl is pre-compiled, and for Linux only. This makes it pretty fragile in respect to different systems and configurations. A better distribution method for luagl should be found and used.

Most of the Lua bindings build fresh tables and populate them. This is faster through lua_rawset than lua_settable, so instances of the latter should be replaced by the former.

lua_settable should not be replaced if an externally received table is being manipulated.

Sprites use OpenGL textures, but never free them, which might cause problems if lots of sprites are loaded and used. Sprites should free their textures when garbage collected.

Tk is a scripted GUI toolkit that works across platforms. Bindings between it and Lua would serve as a basis for the creation of the editor and custom scripted tools, so they should be added to the project.

Or integrate TkLua.

As the title says. Tcl and Tk development libraries and DLLs will probably be needed.

This involves getting tolua++ to compile, as well as use it in the Code::Blocks projects build processes. This could be challenging.

It isn't really hard to use OpenGL for 2D graphics, but people seem to need help all the same, so it'd be good if that were up there.

As title.

The recently committed proteaAudio bindings work with Arch Linux and ALSA, but not Ubuntu. I suspect the PulseAudio transition is behind this, but how or why eludes me.

Currently, only the engine binary exists. The editor binary should run Lua, like the engine. It should hook into any modules it needs to provide scripted tool support once they're added.

The 'quipkit' engine binary should be named 'game'. This paves the way for the editor to be named 'edit', so people don't have to guess which is which.

As the title says.

I'm okay with people making closed-source and commercial stuff in Quipkit, as long as source modifications to it and the existing Lua bindings are contributed back. LGPL? MIT? BSD?

The C code for the SDL bindings organise code awkwardly to use GCC's default C dialect. It should be cleaned up to use things like:

• in-code variable declarations
• for loop variable declarations
• C++ single line comments

Recently many commits were made talking about conforming to a new "coding standard". This coding standard should be included with the source, and perhaps on the GitHub wiki as well.

The editor server and the client process tools need to communicate in an agreed way. Either a Lua syntax subset, or JSON would be ideal here, though possibilities like YAML and protocol buffers should be considered as well.

The format should be documented e.g. on the wiki.

The messages that should be sent between the server and clients should then be documented. IPC is basically like network programming, so having a good idea of the protocol really matters. The needs of the server and the clients should be written down, and how they will be fulfilled should be decided.

The allowed messages themselves should also be documented e.g. on the wiki.

There needs to be a way of saving data outside of the save file system, for e.g. controls and screen configuration. The implementation of this should be roughly the same as for save files, except saving and loading occurs in the one configuration file.

Like the title says. Getting the DLLs in the right places should be enough.

The project Makefile contains many redundancies. Judicious use of variables would make it much more compact and readable.

RPGs can be thought of as a number of small sub-systems interacting with one another, so it'd help if the code could be arranged like this too. Each sub-system could be represented as a game state: a module of code with its own self-contained drawing and logic.

Game states should:

• Be modular, i.e. changing the state's logic should not accidentally affect outside logic.
• Have separate update and drawing functions.
• Allow creation of local instances to enable "game state stacking": a simple way to compose game states.

It should be possible to create game states and use them in a simple demo that showcases at least 2 sub-systems.

A module is needed to save and load Lua tables. This lays the groundwork for the persistent state framework that will make saving and loading configuration and games easier.

Lua's package.loadlib procedure apparently only works with full paths, so unless your name happens to be 'tung', these libraries won't load.

Find a way to get paths or load libraries relative to the current file's path.

Instead of loading multiple images for something to be animated, it should be possible for a single image with multiple frames to be loaded and drawn individually. This allows for very simple sprite sets to be made.

Adding a README would enhance the Github source front page and give people a reason to explore the project further, so it should be done.

Currently, nothing related to SDL surfaces, drawing or any of that (software mode) stuff is not implemented. It would be appreciated if it were because it's a lot easier than OpenGL.

People will probably want to play sound effects and music in their games. Enabling audio output would allow these things.

It should be possible to load PNGs within Lua.

With the map engine requirements down, a map file format should be developed in line with them. Creating a rudimentary map editor would help see how well this format comes together, though isn't strictly needed to close this ticket.