So, after some careful (and in some not-as-careful) moments of consideration, my general idea for RapidXNA while useful will end up being less than ideal for what I want to achieve. The major points that are causing this can be summarised quite concisely:
So, after some searching and asking around I found out some useful information that helped me with my decisions of which route to go. Firstly, the average Linux user does not mind having to compile a game to be able to run it (also, they prefer source over binaries in general). Secondly, you can develop for Android while running windows. So, I needed to choose a system that would allow me to target multiple platforms (whether needing extra builds or not) and not need to have to invest in having proper development environments for other platforms.
In the end, SDL sounds like the ideal choice. From their website:
SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.
But, that isn't the most important factor (in this case). The important fact is that SDL 2.0 is (hopefully) nearing release, which means there will be even more added power and functionality (like touch! Yay!) available in SDL.
Important Item 1: SDL can be run on iOS devices. Thanks goes to Armin Ronacher for the walkthrough.
Personally I try to avoid Objective-C and Xcode if possible. I am not a fan of the language and I rather keep my stuff in a way that I can port it to other platforms with little amount of extra work. As such SDL 1.3 and Cmake are ideal candidates to target iOS and still be under full control of your stuff with simple porting possible to other platforms.
Important Item 2: SDL can be used with the NDK (i.e. for Android)
- Android applications are Java-based, optionally with parts written in C
- As SDL apps are C-based, we use a small Java shim that uses JNI to talk to
the SDL library
- This means that your application C code must be placed inside an android
Java project, along with some C support code that communicates with Java
- This eventually produces a standard Android .apk package
Important Item 3: SDL is free and open source. What more needs to be said about this item?
So, this would simplify my goal of writing a library that can run on multiple platforms using almost the exact same code (there are some "breaking" differences between what needs to be done), but I can already see some ways that I could get passed some of the problems. So, what I think would be ideal is something along the following:
Basically, if I got it right it would mean that I can target Windows, Linux and Android directly (from a Windows development environment), and just need to know someone with a Mac that would do Mac/iOS builds for me, using the same code base.
The major issue will be to make it so that the library covers all the needed base eventualities possible (i.e. it should be usable by anyone for any graphics-requiring project they do) and in such a way that it can be used easily in time restrictive situations (like Ludum Dare).
Also, it is important to point out that I know there are several (really cool, and well built) engines and libraries out there that already do what I am trying to achieve here, but this I want to do for three reasons. Firstly, it is a good time for me to familiarise myself with DirectX and OpenGL (so I can understand more of SDL, and so I can have a better background to base future projects on). Secondly, I dislike that some of the tools cost way more than what I can afford, so writing an alternative is a win-win situation for me. Thirdly, a while back a friend and myself had an idea for an "Open Game Maker" of sorts, basically an open-source game development suite that targeted multiple platforms and that was as easy to use as Game Maker (as versatile too if we could get to it) and perhaps this is a good direction to go project wise to get that started. (Though, still thinking about the scripting in general, which warrants its own post).