DaFool wrote:Regarding Construct2 integration, since the action stages will be in separate layouts from the VN stages, perhaps the save system in the VN portion can already take care of the save system of the whole game?
For example, while playing an action stage there is no need to save, but once an endpoint trigger is reach it goes to a VN layout that asks "Would you like to save your game?" and it only needs to remember the variables pertaining to the particular story branch while ignoring the variables used in the action gameplay sequences.
Perhaps it's straightforward to call up a VN window even within the action stage but then that goes into inventory and all that... much more complicated.
Yes you could do that. EVEN (or I guess I should call it EVNE now? since according to merak I'm "evil")'s scenes can be built as GUI with event handlers. You could program those event handlers to write save data (and I will include template code that shows how to do that).
The most logical kind of save data that I would write would serialize information using JSON. It's simple, easy for JavaScript to read/serialize, human-readable, self-describing, and universally portable. Of course, if you want do inventory it gets a bit more complicated, but not so much so. First ways that come to mind are: serialized arrays of objects describing each item/weapon or serialized arrays of item IDs referencing some sort of pre-established item dictionary. The latter makes much more sense. Or a combination of both, depending on how sophisticated items are.
Finally, as for Inventory GUI in EVNE, I've yet to thoroughly investigate it, but theoretically it wouldn't be too difficult. After I'm done with my NaNoRenO entry I'll get to work on researching these things.
Please tell me more about how you'd like to use EVNE into a hybrid action/VN game. It's a fascinating exercise in design to see how those two can be implemented together. Plus, I bet there are a lot of people wanting to do something similar.
wulfae wrote:While the GUI interface was pretty cool, I also really like being able to just read through my script easily. What would be helpful, and perhaps an easier first step, is a 'live feed' of just what you're programming, or something that you could update in the corner of your screen. I admit I haven't got very far in the actual art process of my game, but I am worried about keeping everything straight. It would be wonderful if I could set up a scene, type stuff up, and reload my render to see how it looks and plays in the particular screen I'm looking at. Maybe ren'py can do that, but it more seems like it makes a game for you to play through, which could take a little while to get to the exact screen I want.
I guess the solution is to make a chapter list a the beginning, haha. Why didn't I do that earlier?
My goal is to have an editor that can change the game in real-time. So you won't have to constantly reload the entire game or keep skipping until you reach a particular scene. You'll just edit it on the spot.
merak wrote:It's great that you are motivated to make a new game engine. I'm going to give some response to your question but more to things you didn't ask but which I think shall be useful to you.
An essential feature is to not use WebGL because it has been and still might be a security hole which allows your screen to be viewed remotely -- not only what you are viewing in the browser, but your entire screen. This is because implementations hook it as directly into OpenGL as possible for ease of implementation probably, but also without protection it is faster.
To anyone who would serve this to users, you should deliver anything with active content, such as JavaScript, over a secure connection. It is sensible to only permit your browser to run JavaScript for pages retrieved over a secure connection.
As far as "Very high performance (thanks to WebGL and JIT-compiled JavaScript)", your application would be the first 'very high performance' JavaScript application I have ever seen. I doubt any very high performance large JavaScript application exists. Typically, there is little need for VN engines to be fast.
If you want something which
- can be run by starting from a WWW browser, without installation of the game
- is faster than JavaScript
- more robust than a WWW browser application
then use Java Web Start, which requires no plug, or there are other languages which require a plug. If you program with Java Swing, then the application can run in a securely contained virtual machine (VM) which can not escape the VM to access the user's computer and over the network can only make connections back to the server from which it was loaded.
Pretending EVEN is an acronym when it is not is evil. It is better to use an initialism than to do that. Otherwise, come up with something which is an acronym rather than initialism.
Thanks for taking the time to write this out. Admittedly, I don't really agree with a lot of your advice.
For WebGL security: every graphics technology has had that kind of exploit at some point or another. Virtually all the information regarding the particular exploit I think you're talking about dates back to mid-2011, regarding the tech community's response to the ContextIS Reports. Since then, every major browser vendor has actively encouraged the use of WebGL, including Microsoft, once WebGL's biggest opponent on the basis of security.
For JavaScript security: I can't recall the last time I heard of a scare involving JavaScript malware. Modern JavaScript engines go through great pains to isolate every JavaScript thread into their own little virtual machine-ish kinds of settings, preventing JavaScript from messing with the system. Every major browser comes with JavaScript enabled by default. Every major website uses client-side JavaScript heavily. Still, I'm sure anyone who chooses to distribute EVNE over the web will take the same server-side precautions as anyone else.
For high performance: depends on your definition of high performance. If you're comparing JavaScript to native C/C++, then of course it's slower. EVNE can animate thousands of sprites simultaneously, all with their own hardware accelerated image filters and transforms at 60+ FPS. If that's not high performance then I really don't know what is.
You say there's no need for VN engines to be fast. But that doesn't mean they have to be slow either.
For Java Web Start: this I really don't get. Can Java Web Start run in any major smartphone other than, say, Blackberry? (iOS/Android/Windows Phone)? Can it be embedded into other browser based games? Or even other games in general? Does it have support for touch facilities on all modern devices? If not, then it doesn't fit the requirements for this project. Also, saying it doesn't require plugins is pretty misleading, considering it runs OUTSIDE the browser, requiring a separate runtime to be installed. Finally, it's not commonly used for 2d games, and it's proprietary software, making it a non-starter for the target programming audience.
For the EVEN acronym: I guess I'm evil then.
But in all seriousness though I kinda agree. I've going back and forth on this issue for some time. I'll probably just change it to EVNE, and phonetically refer to it as 'even'.
Again, thanks for taking the time to write. Also, if you happen to want to continue this conversation further (I don't, to be honest), please PM me, as I don't want to derail this topic.
Now I'm more excited to see the engine in action ^^ Btw, since this is WebGL, will EVEN allow full 3D?
Yes, a solid 2D engine is really important. It's just there's been interest with integrating 3D with VN for gameplay/navigation, like 999 and 3d dungeon crawlers.