How did you get that?! 
Get what exactly?
The 3-tone shade? It just looks really cool!
O ROBLOX has Color3 value man.
Somebody please make a “Future is Bright Photos Megathread” thread because there’s so many images posted here.
Looking at jailbreaks simple UI I don’t believe fancy UI is all that important anymore.
(No offense to the jailbreak devs of course the game is amazing)
1 Like
Jailbreak’s gameplay doesn’t have anything to do with UI so it doesn’t really matter. Other games are different.
1 Like
I suppose that’s true. But regardless of the game unless it’s entirely centered around UI, blocky flat shapes with a catching aesthetic usually seems to suffice for the most part . Especially for just building a skeleton
Finally doing something (and streaming it), yeuy! I’m finally not a lurker of this thread anymore! for now…
https://www.twitch.tv/videos/161580609
More info
Basically working on “Part Networking”, which would allow me to create some things that are common in (modded) minecraft, namely redstone (SignalFlow, although mine doesn’t have signal strength as my networks don’t know about path length yet, and I don’t work with a grid, even though my setup looks that way) and energy conduits / fluid pipes.
- It’s tick based, with my loader code currently just doing
while wait() do API:Tick() end. - In minecraft everything is Block/TileEntity based, while my implementation is Port-based.
- Every “block” is a device (which could be just a part/port, but also a (big) model with a lot of ports)
- Ports implement Signal/Power interfaces (e.g. .Provider, .Acceptor, .Transfer, .Storage, …)
- Devices could implement them, or not, doesn’t really change much
- It’s (supposed to be) common to add a proxy interface, which basically say:
“Use these methods/fields from the Device, the Port(s) just proxy them”
- The rainbow flashing thing is the generator, which produces a constant signal and 100 power per tick.
- Signal and Power use the same base stuff, but are separate from each other
(Lamps only implement Signal.Acceptor, while the Generator does both Signal.Provider/Power.Provider)
They both use a lot of common code, which is put in its own class.
As a side effect, my Signal/Power modules are only 100 lines or so.
(30 or so for saying “Providers have these methods/fields, etc” and 40 for the actual transport logic)
- Signal and Power use the same base stuff, but are separate from each other
- Black cables are… cables… they just transport the signal/power, nothing special.
- The black/red/green box is a battery, which can accept and provide its stored power.
- When it’s empty, it’s completely red, when full, it’s completely green.
- It does a Hue gradient between red/green based on StoredPower/MaxStoredPower
(aka it’s fancy).
- The orange things are lamps, which (currently) only react to signals. When it has a signal, it’s on (light yellow), otherwise it’s off (deep orange).
- The thing with a button is a switch. It has a plug on the 4 sides, which are connected if the switch is green.
- When the switch gets toggled, it’ll mark its connected networks as dirty, which queues recalculations 'n stuff.
I’m currently (well, taking a break for the rest of the day) working on rewriting the logic of how networks are created, so a lot of my demo is currently broken in studio, but oh well. I have git and I tagged the working revision
quite proud. this stuff sounds easier than it is, I underestimated it in the beginning and rewrote a lot of code several times
4 Likes
Yeah I design most all of my UI with minimal details. I think it’s best when things are simple for kids to click and easily interact. 
I’ve just been modeling a lot of assets for a project I can’t talk about, thats all.
Oh and texturing too…
Thinking about making another furry model, just not sure what species and how I’ll be… porting it to roblox for an R15 rig.
Escape the robokill factory wasn’t the only game I made at rdc 
also, I got around to getting a 4k monitor/tv with my devex
sooo much screen space 
2 Likes
