Discontinued… A new system will be made in the future.
17 Likes
I have quite a few points of criticism.
- This is not scalable at all. You may have 3 “apps”, but not only most games cant use it, games cannot add their own views, restricting the possibility for this.
- The UI is inaccessible and in my opinion, ugly. Phone UIs are generally poor when on a desktop computer, however you take it to the next step by making critical navigation confusing and unintuitive. The dragging is also poor as well, as usually only the border is draggable. The animations are not smooth, along with most animations are not necessary to the experience.
- You cannot call this an “OS”. This is a few functions. I have not yet looked at the code to review this quality, and I am trying not to make biased decisions about the code quality, however I’m pretty sure it is not good enough to make this “phone” appealing enough by itself.
9 Likes
Thank you for your feedback. As we are working on updating the phone we will keep these points of criticism in mind.
5 Likes
Mole Hitters
9 Likes
Mole Hitters.
8 Likes
That was for another person on the forum lol
5 Likes
it still redirects to mole hitters
Mole Hitters
5 Likes
Ah yes, Mole Hitters! My favorite type of phone.
11 Likes
The model posted above should now work. I didn’t even realize that it was linked to it, I thought that you just found it 
5 Likes
It has been fixed now. Thank you so much for letting me know lol
2 Likes
The model link in the video is still mole hitters.
4 Likes
Just fixed it. Thank you again. I forgot lol
3 Likes
Heyo, just a reminder that we’re on the same team here. While criticism is a necessary part for helping everyone elevate their level, it’s still worth keeping in mind that if 100% of your post is bashing on someone else’s work - regardless of your intentions - that criticism might not be doing anyone any favors. Furthermore, this seems to be some particularly pointy criticism (especially given that you haven’t actually reviewed the source code).
@ OP
Heyo, nice creation. It’s obviously in an early stage, so I’m sure there’s a lot of polish and ideas that you have planned for it, but I bet there’s plenty of city games (especially those looking to augment their experience with a few cool mechanics) that might put this to good use.
With that said, a few questions that I don’t think the thread does a clear job of answering.
- Yes, the phone is open source in the sense that the code is public, but are you expecting other developers to readily be able to add their own apps to it? Put more clearly - how sustainable is your framework as is and are there any current plans to change it? Asking because if the answer to the first question is “Yes, you are expecting other developers to be able to add their own apps” and the answer to the second question is also “Yes, the framework might change”, then that should be put out there, since that might render impact either someone’s timing or desire to add onto this (for their own personal use or as a public release).
- Does the phone come with its events to drive other mechanics? Scrolling through the code, I don’t think so, but I might have missed this. It would be great (and I think a missed opportunity) if developers could listen to something like
COS.JobChangedand then really easily integrate things into their game. Ex:
local COS = require(PathTo)
local JobChanged = COS.JobChanged
JobChanged:Connect(function(Player: Player, NewJob: string)
--// Code goes here, easy integration
end)
I would also suggest saving settings. Any easy way to do this is recording your setting defaults and only saving a player’s override. That keeps the amount of data you are saving very low and also future proofs it, since you customize defaults, configuration options, etc. and you only have to then worry about players who might have saved an unsupported override (which can be sanitized for when the player joins).
9 Likes
it’s you, why you make the Mole Hitters model?
2 Likes
Hello, we appreciate your response.
To answer some of your questions/assumptions and clarify:
- Yes the model is in a VERY EARLY stage of development
- The framework is currently being 90% rewritten, with the exception of some core parts of our COS. Apps will be much easier to add with the new framework as well.
- I don’t believe that there has been integration with event listening, although I am unsure what you are asking entirely. If the question is about actively listening for an event to fire, then no, there is no easy integration. We will plan to add this with the next update.
- When you say that we should incorporate “saving settings”, what do you mean by that? I see it as we should add a feature that players are able to enable and disable different saving features, but I am not sure what you mean exactly.
Thanks again for the response and we will keep this in mind while we are working on the next update.
Coming out this month… 
2 Likes
I made the model for another person on the forum to help with their game. There was a part of their game that had minigames in it and one of them was “Mole Hitters”. It’s kind of like “Whack-a-mole”
2 Likes
Hey! Thank you for your response, although we would like to add more of your features for the big 0.2.0 launch and we need a little bit of clarification. We think we added your COS.JobChanged function, however, we aren’t entirely sure what you meant. Also, the framework is now pretty much set in stone. What developers add won’t be affected by new updates at this point. We think we know what you mean by saving, however, we aren’t entirely sure. (It also hasn’t been added but will likely be a part of 0.2.0)
Thanks!
Here’s what I mean (with an example settings menu from my project): https://i.vgy.me/rnomOT.jpg
For players it’s annoying if they have to customize their settings every time they play the game. Instead, they want to be able to change their settings, play the game, rejoin at a later point, and have their settings saved in the position they left them in. Since your resource incorporates a settings menu, it would be a good idea to think down the line about saving user settings, both as quality of life update but also as a quite necessary one.
The simplest (and most efficient way, I’ve found) is to set up your code somewhat like this:
Written in Notepad++ so may not be 1000% functional out of the box c:
--// Assume this is all on the client (server sanity checks can be somewhere else)
local AllPossibleSettings = {
["SettingName1"] = {--// Template
["Default"] = "Normal",
["Options"] = {
"Below normal",
"Normal",
"Above normal",
}
},
["Animation Speed"] = {
["Default"] = "Snappy",
["Options"] = {
"Slow",
"Snappy",
"Lightning",
}
}
}
local CurrentSettings = {} --// The actual settings that the player will be running - which can be referenced easily
local SavedData = {} --// Assume this is just saved as a super simple dictionary where the indexes are the SettingName that is changed and the value is the override. Ex: {["Animation Speed"] = "Lightning", ...}
local PlayerRequestedSettingChange: RemoteEvent = PathToRemote
local SomeDataReplicationModule = require(PathToThisHandyModule) --// This would essentially retrieve the player's saved data
local function SaveSettingChange(SettingName: string, NewSettingValue: string)
PlayerRequestedSettingChange:Fire(SettingName, NewSettingValue) --// Handle the server logic somewhere else
end
local function LoadPlayerSettings()
SavedData = SomeDataReplicationModule:GetPlayerSavedSettings()
--// Fill the player's current settings
for SettingName: string, SettingData: table in pairs (AllPossibleSettings) do
local OverwrittenSettingValue = SavedData[SettingName]
if not OverwrittenSettingValue then --// If there is nothing saved, just load the default
CurrentSettings[SettingName] = SettingData["Default"]
continue
end
--// If something is saved, we can just load it in. We can even easily future proof settings by sanity checking it (although this should really be done on the server)
local SavedValueIsAValidOption = table.find(SettingData["Options"], OverwrittenSettingValue)
if not SavedValueIsAValidOption then --// If it's not a valid option (maybe something was saved incorrectly, maybe the setting was removed, we can just load the default)
CurrentSettings[SettingName] = SettingData["Default"]
SaveSettingChange:Fire(SettingName, nil) --// By firing a nil value we'd basically just be saying "remove the overwrite - so that the default can be loaded next time"
continue
end
CurrentSettings[SettingName] = OverwrittenSettingValue --// Otherwise, if it's all good, load in the overwritten value!
end
end
local function GetPlayerSetting(SettingName: string) --// An easy handy function you could add, and boom a super simple set up for handling saving settings
return CurrentSettings[SettingName]
end
--// Some start up code
LoadPlayerSettings()
It’s one of those little things that can makes a big difference, because players enjoy utilizing the tool much more because it “it just works”. They don’t have to do any extra work. More importantly though, if players have to change their settings every time they join the game, eventually they are just going to stop changing the settings altogether. If this is the case, ironically people are going to use the settings less as you add more of them, just because it will become more work to change their configurations every time.
Let me know if that clears things up.
2 Likes
Got it. Thank you again. People who respond have been a big part of the creation process as it allows us to see what other people want from us.
Get ready for 0.2.0 - It will be packed full of new stuff.
Maybe there will be a build mode