First of all, sorry for the late response. In my defense, the post counter was at exactly 42... And I was visiting my girlfriend.
But I'm back, and ready to give Malice the answer he deserves!

Quad already got the basics covered, but to recap: Once you know one language, you know all of them (with the exception of Haskell, Erlang and Lisp (mom, look, I'm funny on the internet!)). What's important is to master the API that you have to deal with, the rest ist just sticking what you know together in a way that solves your problem. Basically that's what programming is all about, you have a set of tool, you know your goal, and then you try to find a solution that fits your tools and that you base on past experience. That's why it takes so long to become sufficiently good at programming, you just need to learn a lot of things that are everything but the language itself (which can be taught in week).

Well, I've mentioned it already, Rayne uses C++. The most modern flavour of C++, C++11, which is pretty fucking sweet, I have to say. With a different language come new paradigms, C++ heavily focuses on OOP, and so it's no surprise that programming for Rayne feels different than it does for Acknex.
On top of that, I would like to add that Rayne isn't as comfortable as Acknex is. It can't be, and quite frankly, we don't want it to be. Hacking the language and creating a bastard like Lite-C isn't our goal, sorry.

So, let's talk API for a second. We are working very hard on having a consistent API. We have coding guidelines and naming conventions that we follow internally, and we want Rayne to be as easy to pick up as possible. Once you got the basic naming conventions and concepts figured out, you can work with every piece of API that the engine offers you, and you will know right away how its formed and how it should be used. On top of that, there is going to be extensive documentation, not just of the classes Rayne has to offer, but also of core engine concepts, and there will also be example code.

However, there will be no transitioning guide for Gamestudio to Rayne. Why? First of all, there aren't enough people here and it's more than just a few lines that need to be changed. Sorry, but we have to be realistic here: We are three guys with a real life, we can't take time from actually developing the engine and put it into writing a transition guide. Yep, sucks, but there is only so much we can do. That doesn't mean we won't help you, if you encounter an actual problem, talk to us! But seriously, just do the tutorials, read the documentation and you are good to go!

I like your example of a creating a window (mainly because I was the sucker who had to write the code that abstracts away windows on Windows and Mac OS X), so here is how to create a "Hello Rayne" with a window.

First of all, you need a base class that inherits from RN::Application, and a function that creates an instance of it. Here you go:
Code:
// .h
namespace TG
{
	class Application : public RN::Application
	{
	public:
		Application();
	 	~Application() override;
		
		void Start() override;
	};
}

// .cpp
namespace TG
{
	Application::Application()
	{
		SetTitle("My Awesome Game");
	}
	
	Application::~Application()
	{}

	void Application::Start()
	{
		// Entry point!
	}
}

extern "C"
{
	RN::Application *RNApplicationCreate(RN::Kernel *kernel)
	{
		return static_cast<RN::Application *>(new TG::Application());
	}
}


Congratulations, you now have a 1024x768 window with black content on your screen and "My Awesome Game" as title. Exciting, isn't it? With this being done, let's talk about creating a level and a camera. There is no level_load(NULL), instead, you normally subclass the World class and implement your own logic in there, let's skip that for now and just create an empty world!

Code:
// .h
namespace TG
{
	class Application : public RN::Application
	{
	public:
		Application();
	 	~Application() override;
		
		void Start() override;
		void WillExit() override;
		
    private:
        RN::World *_world;
        RN::Camera *_camera;
	};
}

// .cpp
namespace TG
{
	Application::Application() :
		_world(nullptr)
	{
		SetTitle("My Awesome Game");
	}
	
	Application::~Application()
	{}

	void Application::Start()
	{
		_world = new RN::World("GenericSceneManager"); // Create the world, and let it use the generic scene manager
		
		// Let's create a skycube
		RN::Model *sky = RN::Model::WithSkyCube("textures/sky_up.png", "textures/sky_down.png", "textures/sky_left.png", "textures/sky_right.png", "textures/sky_front.png", "textures/sky_back.png");
		
		// Create a full screen camera		
		_camera = new Camera(RN::Vector2(), nullptr, RN::Camera::FlagDefaults);
		_camera->SetSky(sky);
	}
	
	void Application::WillExit()
	{
		// Clean up, because we are nice citizens
		delete _camera;
    		delete _world;
    }
}

extern "C"
{
	RN::Application *RNApplicationCreate(RN::Kernel *kernel)
	{
		return static_cast<RN::Application *>(new TG::Application());
	}
}


So, now you have a camera, a world and a skycube. Congratulations, you could technically burn it on a CD and sell it as the next Simulator game laugh

However, the last example goes slightly against the concepts of Rayne, though technically it is possible: Encapsulations. Unlike Lite-C were you basically litter the global namespace with all your stuff, Rayne focuses heavily on encapsulations. The Application class for example is designed to drive your applications, respond to events and in general just be the vehicle that drives the app. The game logic itself would be encapsulated in entities and a separate world subclass, which would then for example take care of creating the camera and cleaning the world up afterwards.

Anyways, I hope that gave a tiny bit of an idea of Rayne. If you still have questions, go ahead and ask!


Also, if you are still with me, here is a round of announcements!
1) We open sourced something!!! Wohoo, our commit bot. Yeah, boring, but there is more to come in the future: https://github.com/uberpixel/commit-bot
2) We are going to open source a tiny bit of the documentation and the repository that it's in in the upcoming week. Mostly to help us write it, because we would like to get your feedback on it!
3) We are planning on releasing a first beta at the end of the year. Stay tuned!
4) I'm going to double post in a few days unless someone posts first.

Shitlord by trade and passion. Graphics programmer at Laminar Research.
I write blog posts at feresignum.com