Bright wrote:I found the vector thing quite interesting.
=> Thank you very much!
Savagen wrote:Spoiler: show
=> That's very nice of you to say! I try my best to add the features one could need to make a game as easy to understand as possible, both with a clear interface and making sure what the interface does is just as clear. And... the dragon is indeed very adorable *,=,*
I think it's better to only make updates when there is actual visible progress, instead of spamming the forum over and over.
Midir wrote:It looks interesting! The Engine is going to be entirely standalone, right?~
Is there a possibility to add animations and sprites in there? I am irrelevant about them, but I know some people love games with sprites, instead of pure text adventures. I would assume this is a pure text-adventure editor, but the DrawIt part seems to suggest it will be possible to add sprites too?
How complicated the AI is gonna be? I remember some game engine with a restruction on manipulating NPCs only when the player is in the same room. It was a bit unfortunate... on the other hand, if I need something too complicated maybe I simply should write it from scratch?
What language are you writing it in?
PS. The Dragon is awesome!
=> The engine is definitely going to be entirely standalone. The only thing required for the editor is the .net Framework 4.0 Client, which any version of Windows should have anyway, if not the installer of the editor installs it too. For the game itself, as long as you have everything that is in the game folder, it will work. I have no idea if it works on Linux or MacOS (the editor doesn't) but it should. I've tested the editor and the game on any versions of windows, from XP to Windows 10 Preview, and for all of them it works just fine. [tested on XP, Vista, 7, 8, 8.1, 10 Preview]
Regarding the sprites, I'd say yes, and no. Why yes? Because since you have access to the scripts of the entire game, there is basically nothing you cannot do as long as you know basic RUBY. Why no? Because the editor doesn't support them at the moment. I've been thinking about adding the possibility to make other kinds of games than just text games, but this will come later, once the editor will be ready for TextGames. You can import any kind of images in the editor, sprites or others, but there is no way to attach them to a player, unless using the scripts themselves (Yay for a working RubySense to help you doing just that!) DrawIt is just a vector editor. What it does is putting points here and there and giving some information on how to link them, it doesn't actually make .png files or whatever. The game then recreates an image out of those points, and modifies them according to some rules (for example, increase Y coordinate of that point when fullness increases...)
In other words, it's not paint, you don't have brushes, you don't have a pencil. At least for now.
The AI of NPCs for now remains to be done. The only thing that is for sure, is that you can access any NPC at any moment during the game, no matter where they are or if you're in the same room or not. NPCs can be either global or local, meaning that they are important for the game as a whole, or that they are only relevant in a single place. (For example, you'd set an important character, or a team member, or the great villains as global NPCs, and an innkeeper or a store as local NPCs, unless you want all your NPCs to be Elder Scrolls Like, and just put them all in global NPCs.) No matter which kind they are, you can still access their attributes directly during the game at any time. global NPCs are just easier to call ($npcs[:npcname]) compared to local NPCs ($game_places[:placeName].npcs[:npcname])
For the editor, I'm using VisualBasic.NET, or C#.NET which is roughly the same thing. The game runs on IronRuby, which is nothing more than Ruby with the .NET framework. Basically the editor and the game use the same framework (.NET), so you could recreate the editor in the game. No point in doing that, but just to give you an idea of what you can do. Why using the same framework? Because that way if I start making something complicated like Vectors in the editor, instead of trying to recreate it from scratch, I can just use the exact same tools I've used in the editor to display it in the game. That makes everything much easier.
Then why using VB for the editor, and Ruby in the game? For two reasons:
VB is fast and awesome, yet it's not that simple to understand for beginners. It also has an incredible IDE, which is Visual Studio.
Ruby is awesome and simple to understand. A game made with it is easy to mod (look at RPG Maker, it's super easy to make scripts once you understand Ruby).
I've been trying to turn the game into VB, before abandonning it when I found out that I'm lacking the method that I need more than anything in the game: eval(). Basically that method in Ruby allows you to give it a string as an argument, and it will turn it into a code and run it. Let's say you have "puts \"Hello World\"" this is a string. When you use eval("puts \"Hello World\"") the string is turned into a code, and it is run. Here, it would run the method puts, with "Hello World" as an argument, meaning it would print Hello World in the console. For security reasons, as far as I've understood, you can't do that in VB, yet I need it to actually read all the files that are created in the editor, more specifically the places files, which contain all messages, stories and events the player will get.
So... I'm forced to stick to Ruby because of the eval() method, and I'm forced to use IronRuby if I don't want to remake everything from scratch, and use the awesome .NET framework.
I hope I've answered you with enough details. Hopefully it was still understandable and answered your questions.
