Rha - A sort of alternate client

Hey guys. As some of you already know, I’ve been occasional working on my own custom game client. If you guys want to see what it is like so far, you can do so here:
http://suckerfreegames.com/_rha/rha_client_3.zip

I want to know what you guys are specifically looking for when you create your server experiments. I ask because I am getting to the point where my client can take off in a couple different directions. First, let me explain how it currently works:

Everything in the game is a scene object. There are 4 types of scene objects: blank, static image, animated, and tiled image. Scene objects can have any position, scale, or rotation. Levels are just scenes that contain a bunch of scene maps. If you want to think of it in Graal terms, the gmap is the level and each individual .nw file is just a tiled image scene object arranged to resemble a connected set of levels.

There is really no analog to Graal’s levels. You can see this in the client currently: I load the starting level twice, scale it, and make it maneuverable/rotatable/scalable using the keypad. If you wanted to, you could make the player BE the level. The player can be any scene object, in fact. Because of this, you can’t easily manipulate level tiles like you could in Graal. If you wanted a destroyable bush, the easiest thing to do would be to make the bush be a scene object that hides itself when attacked.

Next, I currently use AngelScript for scripting. It is a C++ like scripting language. I chose it because it was suuuuuper easy and quick to implement. I, of course, would be open to changing which scripting language the client uses. What I want to touch on, however, is the “class” system. Every scene object is part of a class. Classes have their own attributes (more on this in a sec) and their own script. In fact, a scene object can have a script in its class, and its own custom script. Classes are just ways to easily make duplicate scene objects. Also, each server has its own “client script” file. All movement and client logic is scripted. The current client script emulates a Graal-like experience, but it could easily be modified to provide a platformer experience. This would allow servers to develop their own custom movement system without bothering to hack around a built-in system, like we have to do with Graal.

Next, I made the system incredibly flexible by way of an attributes/properties system. Properties are static elements that every scene object has. They are: level, x/y/z positions, x/y scale, x/y velocity, x/y force, torque, rotation, direction, and image. Technically, properties are just pre-defined attributes. Now, what makes everything special is that classes and scene objects can create their own attributes. The attributes will be shared across the network with all the players. Think of them like your gani parameters, except you can make however many you want, and with whatever name you want. These attributes can also be used in ganis. You could, for example, create an attribute that specifies the location of an image in a gani.

Now, I want to mention local/global scene objects. I currently have local/global scene objects stored in different places. You have to specifically ask for a local/global scene object in the script. This is related to the scene object’s unique ID number. Graal gives each NPC a unique ID. Global NPC IDs start 50,000 and go up. This creates a unique problem where you could run into issues if you have over 50,000 non-database NPCs. It is a large number, but that issue still exists.

Currently, I use Box2D for physics. I am probably not going to change that.

I am also contemplating getting rid of the gani format, or at least adding support for Spriter.

Now, I want to know things like:

  • Should there be a disconnect between levels and scene objects, like how Graal does it with levels/npcs? Basically, should I just use actual tiled levels?
  • Would a split between local/global scene objects bother anyone? Or would people prefer it be like Graal, and just make NPC IDs > 1,000,000 or so be global NPCs?
  • What features would you say are must-have required? E.g., scriptable GUI, color modification, etc?

If I can think of anything else, I’ll ask. I just want to get a feel of what people would expect and would like to work with. If you have any questions or need things clarified, feel free to engage me with your own questions.

this is sweet. i had no idea you were making this. i like the unique NPC id. i would also like to be able to overload some operators so i can compare and manipulate npc attributes based on other npc attributes.

This is pretty awesome so far. As long as we can define global library classes, things like a scriptable gui are not required as a necessity although they’d be nice tools to have for a quick to go product. What I think should be included is full control over tile layers(transparency, blocking, draw under or over the player, etc…).

Should there be a disconnect between levels and scene objects, like how Graal does it with levels/npcs? Basically, should I just use actual tiled levels?:
I think what graal does currently in terms of handling npcs in relation to the level is fine although I’m not fully sure what you’re asking.

Anyway, I can’t wait to see more and the possible online implementation. Also please ignore things like trading off performance in favour of supporting GS1 just because people are too lazy to rework scripts.

Read scripting.txt. It is a little old, but it shows how you can read/write attributes currently.

You like the idea of having both global/local NPCs accessed the same way? Currently, you find scene objects like so:

// Global object.
[email protected] global = ObjectManager.get_global_object("gas_station_5");

// Local object.
[email protected] graph = ObjectManager.get_scene_graph("mylevel.xml");
[email protected] local = graph.find_object("bartender");

Local objects are stored in the scene graph for the level. BTW, I currently have it so you can load new levels in the background.

Engine.load_level("startlevel.xml");
...
Engine.switch_level("startlevel.xml");

You can see what I mean if you look at the client’s files. Specifically devtest_folder/levels/startlevel.xml. Each of the “levels” is actually just a tiled scene object with its Z position set very far away. This makes it so it is rendered under everything else. The Z value specifies sort order. If you want to draw something over the player, make sure its Z value is less than the player. IE, draw levels at Z=5000, the player at Z=1000, and trees at Z=200.

And I am not going to support GS1. It would be a lot of work when the same amount of work could go into implementing something like Python, V8, Lua, etc.

omgwtf this is too good to be true.

lol making levels into objects is fun

Yeah. Levels would be kind of like how Braid did them:
http://www.youtube.com/watch?v=E1KGlngYJ9E

That isn’t the Braid level editor, but it does use the Braid art assets and is very similar in style to the actual level editor. Essentially, you piece together your level using scene objects. Each scene object can have its own collision polygon if you want. It is quite different than Graal’s tiled level approach, with certain tiles being “blocking”. You don’t even need to use tiles if you don’t want. This is quite different than how things are currently done which is why I was asking for your guys’ opinions on it.

I like the way you do it now in your client, seems to work great. I’m sure no one would object to the change

Time to get used to, but time well spent. I’m all for it.

I like how you made the offline part as game-packages. You should have some app-store where you can download games directly from the client

I second this.

Also;
could you implement a way to communicate with gservers so we could start building a community around your client? Or perhaps you’d prefer to build another server program entirely? I see the former to being more likely, if anything at all.

I agree with this, maybe some plugin to enable the client to speak the same language as the gserver so to say. As we have lots of things finished already and tools that we can still use until you’ve made proper replacements. I have no idea how hard that would be. Worst case scenario would be me (trying) converting the graalrelay to translate data between rha and gserver, lol.

The server program would be unique and different from the gserver. Sorry. The packet format is completely different. Same with the packets themselves. It uses a physics engine, so packets have to be a little different. I don’t know what I am going to do about tools yet, though. Ganis work. Graal levels sort of work (you can see how I do them in the game).

gmap / bigmap converter that converts to your format perhaps?

That would be really easy to do.

Support for the Graal RC on serverside? :wink:

Can you further elaborate on how you would want to communicate?

Sorry, it would have to be a unique RC program. Graal’s RC is just not compatible. You would only be able to use it as a chat client. Everything else is just too different.

Allow us to use Rha to connect to, say, Classic. And then us early adapters could make some online content to show off your client.

However you already stated

so it’s a moot point. I definitely look forward to the future of this project. Perhaps even more than Dungeons tbh.

Hiya, just checking whats new in the world of graal.in when I saw your project. So far it is looking promising :slight_smile:

What might be quite cool is instead of using some strange backpal type thing for level effects, a pixel shader could be sent from the server, compiled up and displayed on the client at runtime.

IIRC, Irrlicht lets you upload a GLSL frag and vertex pair so it should be very feasible.

Very nice. Exited to find out more of this.