Re: openLR project thread - 0.0.5 release April 29th

[[senpai] kevans]

Neat little animation tool for development progress.

https://www.youtube.com/watch?v=8B8I5h8BxJY

[[senpai] kevans]

Ten simultaneous riders

https://www.youtube.com/watch?v=fbCOfAimPsw


Worked right out of the box a lot better than I expected

[Sheldon]

Thats pretty cool dude

[[senpai] kevans]

So I'm going to try to do this thing where every 100 - 200 commits I'll give a quick rundown of what's going on.

---

To start this off, the toolbar got a massive visual overhaul. One of the cool things openFL allows me to do is import native flash assets without needing flash player. The benefits of this include the ability to use assets as close to their native original sources, and provide infinite scaling without loss of detail. Why is this important, other than making things just look crisp? This video here will explain it: https://youtu.be/Toft6fMvByA?t=737

For those of you who can not watch, the basic idea is that as resolutions get bigger, assets get smaller. So to aid this ailment, I went through the process of completely overhauling the assets involved with the toolbar, and tossed in a really nifty scaling setting, which IMO, is a lot better than an automatic scale.



So rejoice! OpenLR can work on 4K and above monitors without having to click on smaller and smaller icons.

---

Next up is something that's being a bit overhauled on the engine internally. You have somewhat already seen it here, my track showcasing off 10 riders. In the thread I explain that I am adding support for infinite riders, and this is a promise I intend to keep. But there is a larger picture going on here. Since commit 5de650e, a lot of rework has been done to make the engine far more agnostic to it's inputs. What this means is I'm reducing how hard coded things are, and allowing a lot more customization for how we create our tracks in terms of the riders we can use. Here's a summary of what's planned that this can allow for:

• Different rider types, Beta 1, 2, 3, unbound, and even custom defined ones.
  
• Custom gravity
  
• Custom start speed
  
• Custom start angle
  
• Control when the rider spawns and despawns
  
• And whatever else you think we can change
  

The overall focus of this isn't just putting more power into track creators, but also providing more power to anyone who wants to take the source code and modify it by providing far easier to modify engine code. Or at least I believe I made this code far easier to modify.

---

Another set of things I have mentioned in the skype chat is easy to modify settings through JSON, and one of the more important additions is the inclusion of language support that can easily be modified and shared with the community. While the jsons found within the source are going to be embedded into the executable (so going back to defaults is easier) it will be read through the language.json file, which can be modified by the user. In the future, once I have everything adapted to the new language system, I'll be asking for help from anyone here who can speak a language besides english.

Thanks for reading, I'd appreciate your thoughts if you have any.

[[senpai] kevans]

https://www.youtube.com/watch?v=pKKo7Bscsrk

https://www.youtube.com/watch?v=2NDf0u6OP1Q


The default start velocity is (0.4, 0) and this I have it at a max cap of (5, 5) and min cap of (-5, -5). Will test to see where the comfortable range is.

[[senpai] kevans]

Hey, I need some testing. Nothing specific, feel free to report back with whatever. I have builds for Windows, Linux, and OSX: https://www.dropbox.com/sh/423mvu01bncd7v5/AADk6wx2sR5RS2UMZEmGvCa4a?dl=0

EDIT: Arbitrary start angle and velocities are in this. - and + will rotate the start, and the number pad will adjust velocities. 8/2 being up and down, 4 and 6 being left and right.

[[senpai] kevans]

Bit of a quick but important update I want to talk about.

One of the big goals of openLR was ease of access. One of the things that moving away from the flash platform has taken away from us is our ability to "just play". This can easily range from being on a platform that simply doesn't support the latest version, being on a machine that can't handle the power needed, or even making a decent recovery should Murphy's law happen to your hard drive. At the moment, I can't provide any solutions to that third issue, but the first two are definite ones I can solve and have added to the road map of future openLR development.

Haxe has the incredible ability of writing code once, deploy to nearly any platform, with little to no alterations to your main source. This was an aspect I thought was perfect for the sort of goal I wanted to achieve and provide for the community. In regards to the first two problem I've illustrated, I've recently began work on adapting openLR's source to be deployed to not just native C++, but javascript/html and flash.

https://kevansevans.github.io/openLR-JS/
https://kevansevans.github.io/flash/openLR.swf

Neither of these platforms are currently stable, but they may end up being the primary ways to play in the future, as currently their performance outpaces the C++ builds. I sincerely believe that this will help open the doors to how people can contribute to the community through providing accessibility options, and providing the tools to modify the game as they see fit.

I know my recent discussions have been all over the place, I am sorry, I'm just one man and I am trying my best, but I do appreciate the support! Thank you!

[[senpai] kevans]

Updated the OP to be a bit more clear. How to compile instructions have been linked offsite to the github readme, and have added links to the flash and HTML5 versions (which are still unstable)

In other news, I am still looking for people to bring aboard this project. Contact me anyway you can and I can walk you through the tools we'll be using.

[Hanuman]

I'm not particularly familiar with coding, programming etc but have you considered adding in programs to replicate lines or shapes, like maybe you highlight a few lines you have drawn and copy them so you can paste them? Or a way to paste them in the same position in next frame? This would make stuff like animation way more viable.

[[senpai] kevans]

Yes, this is something I want to add in the future. I don't know when it will happen, as the primary focus right now is stability and modularity for when the "razzle dazzle" really starts coming. There's also the issue trying to figure out how to approach this feature. I have thought of a few methods, ranging from displaying a translucent image of the previous frame, to completely overhauling the way we do scenery through a separate editor in the game.

But for now, I need to make the engine in a way I don't have to hack things in to get working.

[[senpai] kevans]

[Helios Pavonine]

Yesss

[[senpai] kevans]

What's everyone's thoughts on bringing back the beta 2 mouse cursors for the tools?

[Jam]

I'll rise back from years-long inactivity to say that you're doing an awesome job with this, man. Let me ask you, though. Any specific reason for going with Haxe?

Also, about the cursors, YES.

[[senpai] kevans]

Thanks man, really appreciate it. There's a few reasons I went with Haxe.

I know the majority of this community aren't very much into programming, but I know a lot of people here have wanted to experiment with their own tools, and I've been really wanting to give that to people, as I've always been very progressive with builds. I had to settle on a language that was easy to use, and one of the selling factors was it's syntax was similar to the language used in the flash builds, good old ActionScript 2. Except it's not flash, and it's not terrible. I hope that this makes it easy for anyone willing to dip their toes in to work on their own wacky and innovative builds.

Another huge reason I went with Haxe was Haxe's design goal. Instead of being a language that just gets converted directly to machine code, it goes through an interpreter, which converts it into actual native code, and then compiles it to the specified target. In a nutshell, I write code in Haxescript, Haxe turns it into C++, and then your machine compiles it. I can target a large amount of platforms without changing barely any code, and get the exact same app as you see on any other version. I can currently deploy to these targets: iOS, Android, HTML5, Windows, macOS, Linux, WebAssembly, and Flash. I really like this, as if one of these platforms doesn't perform correctly for you, there are alternative options. I know there's a few people here that still use the flash builds, and I can understand why, so I'll be able to provide updated versions of LR without having to make them compromise the environment they're used to, or have to bother with converting all their tracks to any new formats. (Once I have the HTML5 build up to par, I'll start working on Flash and Air builds) (Yes I tried iOS and Android and they haven't been anything successful, will try again in the future).

Haxe also has a library that emulated how Flash behaved in terms of writing code, so it made things much easier to port, and made making the graphics much easier to look the same.

[theacp127]

I prefer something smaller and easier to pinpoint than a regular mouse pointer. The crosshairs like in LRA work well for me.

[[senpai] kevans]

I tried. Don't get your hopes up though, app crashes immediately on launch, and I have no way to debug it quickly.

[[senpai] kevans]

Right clicking with the eraser will swap line types.
Holding Z will swap direction of any direction based line.
Holding shift will flip the collision side.
holding control will toggle the line type to scenery and back. If line started as scenery, it defaults to blue lines when toggled.

Added benefits:

Just requires a click instead of clicking and dragging like 3.4.X.
Line order is not affected in any way unless you are swapping scenery.

EDIT: The JS version has been updated if you'd like to try this feature out now. https://kevansevans.github.io/openLR-JS/

[[senpai] kevans]

700th commit update

Releasing some sprite sheets from openLR

PNG: https://i.imgur.com/dfDxGDz.png
Raw FLA: https://www.dropbox.com/s/yde56m46oesb4wn/olr_assets.fla?dl=0
SVG: https://www.dropbox.com/s/ki3wkc9uw66f78j/olr_assets.svg?dl=0

In other news, 0.0.5 will be released when I have the flash version ready, and the saving is fixed. Right now I want to work on a better saving/loading system for the Desktop and JS/HTML5 builds. The Json format is fine, but I need to prepare it better for the things I need it to store, so eventually I'll be adopting a modular lump system that doesn't need to be converted in order to be used across different builds. The flash version (for now) will not have a fancy save format, but I will make it backwards compatible with .sol's as I don't need to program in a converter. So for anyone here who still uses flash, I promise you will be getting an upgrade. That's not to say I won't add .sol support for the desktop and HTML5 versions, they're just not as high of a priority right now.

After 0.0.5 is out, and I squash some bugs, mobile support will be a priority. I will want people who own Android and iOS devices to help me out here. As a heads up, iOS people who don't own a mac, you will need to jailbreak your device, as I won't be putting it on the app store at all (unless I get approval from Inxile, I've been trying to reach out to them). Same goes with Android Marketplace or whatever that's called, I don't own an android device.

For any other features I've been teasing here, I have no ETA on when those will be released. The point of me even putting them in was to make sure my code revisions allowed them to be possible to begin with. I can't speak for others, so take this with a salt shaker, but most of the engines we've been using have a lot of it's aspects hard coded into the system, which made those sorts of things much more difficult to add. In a nutshell, I'm building a game engine, not just a Line Rider engine.

"Kev, when's 0.1.0 even coming out, are you ever leaving alpha?"

Alpha stage will be left when I have something stable and no longer have to play catch up with other builds (relatively). This also means it has to be at a point where I no longer have to keep rebuilding parts of my code to future proof any features. Beta will be in a weird phase and I'm not sure what I'll be doing there to be honest.

[[senpai] kevans]

[[senpai] kevans]

Streaming development https://www.twitch.tv/kbeevans

[[senpai] kevans]

Flash version has caught up to the indev build and shall be updated in tandem with the HTML5 version. There are still bugs to squash, but it's in a relatively playable state.

https://kevansevans.github.io/flash/openLR.swf

0.0.5 update soonTM

[[senpai] kevans]

[gaoyubao]

I'm guessing that this is a consequence of a smarter collision-testing algorithm?

[[senpai] kevans]

Kinda. Wanted to attempt a "gwell-less" line and more or less got this result. I'll have to tweak it around more so it would behave as expected.

[Sponsored content]