New Engine Possibilities?

Honestly I kind of hope you guys keep Renpy. It's far from perfect but it is familiar and you're pretty damn effective with it. That said I know next to nothing about coding so I might be completely off base.

The Doddler has more or less managed to perfect the art of making Unity ports of VNs (he's making it work for Grisaia right now, and even posting technical bits on his twitter), so I thought you planned to do something similar for Sunrider: "porting" the VN parts (that aren't that complicated from the beginning) and making use of Unity's to make a good turn based system.

Ren'py's main problem is that it's so commonplace and easy to use that now is commonly associated with poorly done shovelware (specially if you use its default U.I.). One of its greatest features, the rollback (that substitutes a normal log) already worked kinda wonky before 2.0 due to having the R&D part crammed in, and it has always worked not too well with voices.

And really, we're in 2016 to have a VN with full voice acting but lacking a proper log and voice repeat features... That's the VN equivalent of limiting to only one save archive in an JRPG, really.

So I honestly think even the VN part is a little bit lacking in Ren'py in my eyes. Maybe putting some work could improve things, but honestly that work could also be put on a new engine.

Game Maker's more or less out because the license says no 18+ games can be made on it and GM's owners can effectively bar any game from being released on it based on what they feel like. So it's not a viable solution.

Unity will only make our problems worse because we'd have to start from scratch on an engine multiple orders of magnitude more complex than renpy.

The engine's not really the biggest issue anyways. Maybe the TRPG segments took about half of the development time of the game. It's not really the engine which causes the huge development hours. Balancing, creating assets, and debugging a TRPG takes months of work on pretty much any game engine. Basically, we spent I think about 5 months making TRPG segments which a substantial portion of the player base chose to skip. I think the VN segments could easily have been 4 to 8 times longer had those 5 months not been used to make the battles. But I guess I don't really know for sure, it's just all guess work.

If its performance you're worried about, this thread made a world of difference for me. Completed a play through with the framerate, cache, and free_memory code added. Much more smooth and no crashes that I recall.

I just played on ultra easy. Combat lag with OP God Kayto powers. No need to worry about lag if all the enemies are dead before the first attack, lol.

Yea, new engine would be nice, however, even if you continue to use the current game, it won't stop me from buying the game, and enjoying the hell out of it, lag and all.

Every time someone brings up lag I have to ask the same question:





This is a quick and easy fix that alleviates most of the problem for... well... everyone whose gotten back to me on it at least.

yeah, the map size is easily adapted to whatever isometric background is preferred. I'm treating the tilesizes as constants too, but those could be dynamic too of course. animation works via sprite sheets.
I also got my feet wet with proper pathfinding, so all around it's been an interesting project.

something I'm especially stoked about it the ability for the player to give commands to a unit while the previous unit is still carrying its orders out. few (turn based) games allow that but it results in some real nicely flowing gameplay and really wish I could make all this work for Sunrider someday.

Corr it would be great if we could see a tech demo somewhere down the line especially if you get the thumbs up to implement it into Sunrider.

(Hype, hype hype).


The fact optimising options like this exists gives people the option to use it if they want to experiment the effects on their system - which is always a bonus.

Thanks for the suggestion, but it ended up being a problem with me forgetting a return statement under a 'after_load' label like a complete boob.
renpy uses cpickle btw, and seems to work well enough. switching out such an ingrained part of renpy on my own though seems unrealistic and uneconomical. I'd sooner change my data structures to support it better than the other way around.

Huh. I am glad to hear that the majority of performance issues are all just self imposed from inexperience.

I can imagine that in Starnova, there will not be nearly as many coding hurdles for you to go through compared to a more game-play heavy experience such as Sunrider. Does this mean that perhaps in slower points in Starnova's development, where Samu will be doing more work on non-coding parts, you would be able to go back and work on Sunrider's combat coding?

And if you do, would you rather simply clean up the current code you have in place, or try to rewrite large portions of it from scratch? From the way you've described it, it seems like much of it is rubbish, and based on the new things you might want to implement; it would be easier to rewrite the code to accommodate what you want rather than forcing the older code to do such.

Commanding while other units are simultaneously following orders sounds like a really awesome idea, definitely keep the battle flowing.

I'll send you a PM rather than spam the board with technical stuff few care about 

allright. laymans terms. as much as is possible

In Sunrider, the battle map and all units and events on it are all shown through ren'py "screens". this is a ren'py built-in mechanic that is intended to allow non-programmers to easily create menus and other UI elements. This system is very flexible, but never really intended for more than showing an in-game store, or an inventory or at the very most a dress-up game. forcing it to show countless elements within a large scrollable viewport was insanity in hindsight, and god-awful slow.

What I've made since then is a system that doesn't use ren'py screens at all and instead is pretty close to pure python, or rather pygame (the library ren'py is based on). renpy offers a spritemanager framework that supports this, and actually is intended for more advanced gameplay. Doing this is of course a lot more complicated as far as coding is concerned, and I really didn't feel up to the task when I first started out.

At the core I make a large background image into a sprite and create an update function that every frame (about every 0.02 seconds) checks whether the player is holding down the mouse button and if this is true, whether and how much the mouse has moved. this information is then used to change the location of the background sprite. 
Then, any other sprites (like units or doodads) get their screen position changed as well so they stick to the background.

This per-frame approach allows for much finer control over what is happening on-screen. When a unit is clicked on I generate new sprites which show its movement range and I then record what tile the player wants to move to. I create a path in memory and set a flag that tells the game this unit is currently moving. each frame the unit's location then gets updated. since I'm also using custom displayables (another very powerful advanced ren'py feature) as a basis for the unit sprites I can animate them based on a filmstrip, kind of making my own .gif support. since the unit is pretty much moving on its own at this point and I don't have to care about renpy 'interactions' anymore it's perfectly possible to give a different unit another order.

I made a stress test based on this where about each second (every 50 frames or so) a new unit is spawned in a random free location and also gives a random move order to any unit that currently isn't moving. eventually this creates a mess of ants walking around through a maze of doodads (which you can also place wherever). even with hundreds of animated moving units the framerate is still pretty decent.

Did you use Transform inside the UDDs so that they change position and size?  After your PM, I attempted the sprite manager approach with Sunrider.  Since there were so many different calculations for position and size, I ended up abusing lambdas(anonymous functions).  For transform written in ATL I used At.  Everything I tested works works but I'm wondering if there is a more efficient approach.