![]() |
Curious if this is feasible as a Playerworld
Hi,
I've been looking for an engine/hosting/scripting solution for bringing my 2D MMO vision to fruition in my off-hours, and Graal looks promising. I have a few questions about Graal's playerworlds capabilities; if you all could give me quick-and-dirty answers, I'd very much appreciate it. :) 1. Is there a limit to the number of NPCs a Graal world can contain, and the number of variables they can manipulate? My plan for a 2D MMO involves a high amount of NPC interaction -- is it feasible to have a Graal playerworld with hundreds or thousands of NPCs, where each NPC tracks whether you're (for example) friendly or hostile towards them based on your past actions? 2. I understand that the tileset can be edited freely (my current plan is to use a pure ASCII tileset, early 90s adventure game style, so that I can rapidly prototype and develop content without being focused on art) -- is the same true of the User interface? I find the interfaces in the Graal worlds I've tried to be incredibly cluttered and unintuitive... ideally I'd be swapping out the interface fonts, the way that NPC names and text are displayed, that sort of thing. Is this easy to do, or are some aspects of the interface "hard-coded"? Does the life bar have to look like a yin-yang symbol, for example? 3. How difficult is it to move NPCs into different 'states' where they react differently to players? For example: If player A comes along, has a dialogue with my NPC, and chooses options that make the NPC angry -- can the NPC still be angry when Player B comes along, and act accordingly? If an NPC hands out a task to Player A, who then completes it, can I have that NPC offer a different task to Player B? Is there any way to save all this 'state of the world' data so that it wouldn't be lost if the server resets, if a map is exited and then reloaded, etc.? 4. Are there significant limits on world size or complexity? 5. Is there a way for me to play around with the editor prior to renting a playerworld? The sort of world I'm aiming to develop is somewhat idiosyncratic... with less of an emphasis on traditional combat and cluttered features, and more of an emphasis on interacting with the world, the NPCs within it, and the other players. How feasible is a project like this, using the Graal system? Are there any playerworlds currently running where people have modified the UI to be sleeker and more intuitive? The playerworlds I've tried out so far all felt like their UIs were constructed on the fly by teenagers, rather than with a particular aesthetic sense. Any help you can offer is much appreciated! |
I don't see any reason you'd run into problems with your described setup as long as you script it right. Some of the things, such as NPCs having different 'states' for each player, are not necessarily built into the language, but are trivial to write yourself. You can do almost anything you want to with the interface.
There are limits on the number of NPCs you can create, but the limit is quite large (I don't have the exact numbers) and generally won't be a problem. There are lots of people in the scripting forums who will be able (and willing) to provide specific details on best practices for implementing these ideas in Graal. At the moment, the only way to try Graal server development is with the offline level editor (or Gonstruct), but you won't be able to script with it. You can probably find somebody willing to let you play with NC on their server if you ask nicely enough. |
Interesting!
This NPC limit you speak of... where could I learn more about this? |
Quote:
You generally won't hit the limit unless you're doing something wrong. |
Quote:
Also, I'm assuming I would need a fair number of 'invisible' NPCs for various reasons that might only be visible when certain events trigger. For example! I have two villages, Village A and Village B. I have a player event where monsters attack Village B, and the players can either succeed or fail at repulsing the monster attacks. If they fail, I want Village B's NPCs to flee their destroyed village and take up residence in Village A. If Village B has 10 NPCs normally, I'm guessing I need 10 'invisible' NPCs on every level between Village B and Village A. That way, when the event triggers -- the players fail, and the NPCs flee -- on each level in between, those invisible NPCs get the 'Village B has been destroyed' flag flipped from 0 to 1, and they become visible and start fleeing for their lives toward Village A. Multiply that by many possible events, and I start to worry. So long as we're just talking an NPC limit per level, though, that's not a problem at all! Worst comes to worst, levels can be split into smaller levels, creative NPC economizing can be done (if I know the 'monster attack on Village B' event and the 'alien invasion' event will never occur at the same time, I can have one invisible NPC that pulls double duty in both events, altering its appearance and actions according to the situation, rather than two separate ones), and things like that. But a global NPC limit for the entire playerworld would be dicey. Even if I don't hit it at first, it limits the potential for later expansion. (The game I'm planning doesn't have levels, XP, or hunting for loot in the traditional sense. Adding new NPC interactions, and new NPC dynamics, is very key to the game's planned long-term growth.) |
Nope, NPCs can move and be warped to the different level.
You can create NPCs dynamically by using putnpc2, join a class to them to inherit your generic NPC functionality and so on. |
Quote:
|
Also note that NPCs are unloaded after around 10 minutes of inactivity in the level, so when a player re-enters onCreated will be called.
You also have access to SQL for storing and retrieving data. |
Quote:
(Also, I'm eagerly eagerly awaiting new episodes of Community) |
Quote:
It really just depends how complicated your data is though. What you're wanting to do is very possible though. I.e: PHP Code:
|
I'd really hope you'd join us, and I look forward to your work. :D
|
Quote:
Time to start learning GScript(2?). I worry about using the Wiki to learn, though, since it seems to have a hodgepodge of info from various periods in Graal's development (graal v3, v4, v5... v6?). Basically, my plan is this: 1. Somehow convince someone with space to let me set up a test space within their space, nothing their players will interact with (that's feasible, right? Using part of someone's playerworld space to build your own test creations, without it being visible to their players?). 2. Build/script my 'newbie experience'. My plan is that when you arrive in the world, you're in a somewhat secluded enclave community, and you can't venture out to the broader world until you "gain the trust" of the NPCs there (i.e., until you complete the newbie experience). All of the major game mechanics I've been designing the game around will be 'there', just in very simplified, limited form. The idea would be to complete this to a 'basic proof of concept' level. Graphics, shmaphics... when I do rapid prototyping, I just use ASCII tiles (perhaps the result of my starting up in game design using ZZT a decade-and-a-half ago.) 3. Once I've finished my proof-of-concept, take the plunge and buy a year of Playerworlds hosting for myself. |
You seem so confident and your plan is so thoroughly thought out. I really do feel that anything you produce for your server will be fantastic and I can't wait to see what you have in store for us!
|
Quote:
Quote:
|
Quote:
Along the way, I narrowed things down quite a bit: 1. Any game concept that would largely replicate existing gaming options went out the window. If I'm going to sink in a large portion of my leisure hours into game design, it had better be to create something novel... I've got a wife, a career (where my video game design background weirdly comes in handy), my life is stable, and generally speaking, I have a consistent yet limited amount of free time. 2. At the same time, although I wanted to try something new with structure/world design, I wanted the underlying core gameplay to be tried-and-true. I ended up basing my game concept around 16-bit Zelda-style gameplay, because it's comparatively easy to implement in a variety of contexts and quite naturally fun. 3. I knew the game had to be 2D, rather than 3D. My taking on a 3D project just isn't feasible... 2D is easier to work with for coding/scripting/implementation, there are infinitely more high-quality free art assets available, a narrower range of skill-sets required to bring a project to completion, etc. 4. I knew I'd consider anything upwards of 50 regular players to be a success. I knew I'd need to be able to provide game hosting for those players at a cost of less than $1,000 a year. 5. I knew that I needed to be using a system with a well-established scripting language, rather than something that required me to directly touch the code every time I wanted to add something new. This way, there's an established base of players who could potentially contribute to my project in small ways when I needed them without needing to immerse themselves in my project. Let's say I want to add a Zelda:LttP-style Hookshot to my game... with a strong scripting community, someone with no knowledge of my project but a strong knowledge of Graal can possibly contribute that sort of code. If it's just straight coding, I either need to code it myself, have a coder on my project's permanent staff, or pay a freelance coder a substantial sum of money to first understand my code and then understand how to construct a hookshot object within it. All of this has led me to Playerworlds/Xtremeworlds... though from what I hear, Xtremeworlds is more limited than Playerworlds? Is that correct? |
| All times are GMT +2. The time now is 05:54 AM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.