hyperPad: Overhaul

[Thecheater887]

Hello.

As most of you probably haven't noticed, I haven't been too active as of late. Along with varying excuses, the biggest one is the fact that it doesn't even come close to competing with other traditional text coding languages in game making necessities, but it more than aces it in user friendliness.

I have a massive read happening about my opinion on what can, and should be added and changed to help it compete.

Basic, Indie, Developer - Most of my suggested changes revolve around these. For starters, rename them to "Creator", "Developer", and "Enterprise", unless there is a better version of it. It may just be me, but I don't think I would like being called 'Basic'. Additionally, these names don't describe the featureset included well at all.
In my opinion, but with discression, Creator, the default out-the-box package, will no longer include things like Move By, Skew, Torque, Advanced mathematics (Sin, Cosine, Arc, etc), hub upload, Tilt, Attach, Effect Creator, Get color, and other more 'Advanced' behaviors. Additionally, they will only have the must-have options. It's basically a free-trial of a paid service, it gives you a taste of what you're getting, but if you want to make anything of it, you have to upgrade.
Developer will include things like weld attach, get color, get and set velocity, socket^, code block^, Sandbox^, themes, and open-source hub upload plus basic customization. Additionally, this package will include everything in "Creator", plus the particle editor, open-sourced hub upload and basic customization, priority email support, open-sourced code block upload plus full download^, saving, and more behavior customizability, at the cost of another $10, raising the price to $15 from $5.
As for enterprise? Here's where it gets fun! This package will include everything in Developer, plus the sound editor, full hub customizability, closed source hub upload, closed source code block upload^, all attaches, forces, mathematics, export functionality, iAP Placeholders^, full behavior customizability, tweet, post, rate^ , encryption^, priority chat support, and everything else currently included in the Developer package. This will raise the price monthy from $10 to $10, and lifetime from $150 to $250.
^Will be discussed later on in the post.
This is, of course, at the developers discression, since I don't own hyperPad's code.

Socket - I feel this wasn't the best thing that could be implemented. I propose that they change to raw sockets, with behavior 'Connect' options being 'Connect To Host Entry{Secure{String}}'. 'Connect to Port: Entry{int}', 'Protocol: Dropdown{TCP, Enterprise{UDP}}', 'Send{Data}', 'Receive: Entry{Int}', 'Close', and 'Get Socket Status'.

Encryption - There would need to be two types of encryption. Stream, and Block. Stream would use, for example, ARC4, while block would use say AES. The associated behaviors would be 'Encryption Object: Dropdown{Block, Stream}, Entry{Secure{String}}', 'Encrypt: Dropdown{EncryptionObjectSelector}, Entry{String}', 'Decrypt: Dropdown{EncryptionObjectSelector}, Entry{String}'.

Sandbox - We currently don't, and never have had a proper method of object management in the way of spawning and maintenance. This would essentially be a 'Developer Seen Only' layer of a project, where the 'Spawn' behaviors can select an object from to spawn, eliminating missing and reacting objects, for instance, if an object should only be spawned once every 30 seconds, and moves towards the player, the original will immediately move towards the player, regardless of if it is in the playable area bounds or not.

Code Blocks - The hyperPaddian way of 'plugins'. It's essentially a special type of project that isn't a game. but still uses all available behaviors, plus the starting block being 'Code Block', where you can add required information, for instance, strings and objects. The exit would be, well, 'Exit', which functions similarly to 'Code Block', but instead allows the added values to be output. Example: If I want to create a code block that destroys all objects in a tag, it would look like;

Code block{Tag}
Destroy Object{Tag}
Exit

And if I wanted a Code Block that told a server information about an object;

Code Block{Object, String}
Box Container{Success, 0}
if String equals Position
GetPositionX{Object}
GetPositionY{Object}
Combine Text{GetPositionX + GetPositionY}
Send{CombineText}

if Send equals Fail
Change Value{Box Containter, 1}

else if String equals Destroy
Combine Text{Destroy + Object:Name}
Send{CombineText}

if Send equals Fail
Change Value{Box Containter, 1}

Exit{Box Container}

This would require and allow no text coding (Apple standards), and allow for common and shared libraries by using the behavior system and hub, replacing the Functions request.
Code blocks placed in a project's Global tab would be created using a behavior 'Code Block', and be unable to be accessed outside of the project, whereas code blocks created outside of a game project could be shared freely via the hub.

Rate - This is a simple behavior that if used in hyperPad, exits the project and open the game on the hub if it exists, and if the project is in an App, instead opens the app store. This is only available to Enterprise users, as it would require Xcode to modify outside of hyperPad.

iAP Placeholder - This one may be tricky, and is a long shoot, so I don't plan on this one getting far. It's intended purpose would to be, when exported to Xcode, have the basic code for an iAP, with sensitive and changeable information left 'null'. I didn't do research on this one, so I don't even know if it's possible.

These suggestions would require the removal of the behavior tabs 'Basic' and 'Advanced', as the package you are in possession of will change what you see.

I apologize for the long read, but at least I forgot half of what I was going to suggest to writers block, or it would be longer! :face_palm:

I am willing to provide sample concept code for most of my suggestions, and will do my best to improve and respond upon replies.

I also apologize for any typos and my horrendous English, I can't figure out why I can't figure it out.

[Murtaza]

Thanks for taking the time to give such detailed feedback. As you know, we take all user feedback and try to apply it as much as possible.

Regarding tier naming, while not perfect it does seem to be working and causing less confusion. We also done focus group testing with this.
Basic, may not the the best term I agree. I do like the name "Creator" though 🤔. But I think Indie works quite well, we could maybe change it to "Hobbyist" , but it's hard to type and spell (making search harder). Developer.. Well if you remember correctly it used be called Pro, and we changed it to Developer based on your suggestion :). The reason I feel enterprise doesn't work is because it's misleading. In general, enterprise software implies more seats (users), rather than more features. So this means, they get the max tier that's already offered, but instead of paying $9.99 /mo for each user they get a slight discount since they have more employees.
Since our target user is not enterprise businesses, this doesn't really make much sense. That being said we do offer a similar pricing model for education institutions. (see https://www.hyperpad.com/education)

As for pricing and feature sets.
The basic version is to be more of a trial. It's there so users get a taste of what they can do. We didn't want to limit the functionality here by taking key features away. Instead we wanted to get users hooked. If they need more behaviours, need more scenes, etc. They basically reached the point where they are hooked on hyperPad and need more. This will result in them upgrading.
There is a lot of psychology involved with freemium. And we obviously haven't cracked it and there is room to adjust. But I don't think the approach is to take away key behaviours or other functionality.

The indie tier, is there to basically unlock full access to all the tools most people need to make a game, and targeted towards people who don't plan on exporting to the App Store, don't have the resources to launch a server or take their projects to the next level. They're doing it for fun. They get everything they need to pursue their hobby.

The Developer Tier, is there for those who want to take their projects to the next level. These are people who are taking things more seriously, and have the resources needed to buy Apple Developer accounts, extra hardware (additional devices to test on, macs for deploying to App Store), have resources and the knowhow to launch a server, or connect to a 3rd party API. These are people who are thinking about things like data analytics, and how people play.

Your suggestions of separating the tiers down further by limiting certain features will cause two problems. It alienates users more since there is key functionality missing, and you're limited their creation abilities. And it makes it harder for us to manage. By creating so many small differences in what behaviours there are available and what editors they have, this just introduces a lot of room for error and potential for huge bugs.

As for pricing, this is something we're always looking at, and something we look to constantly be changing. Both in favour of our users and for us. After all, we are a business and do need money to continue to develop, pay for marketing, pay for servers. Apps are not cheap, especially one like hyperPad.

Now for your feature suggestions/changes:

• Socket: Why? What's the point? The majority of our users don't know this stuff. It's not our target user. Socket.io is a fantastic solution, that offers all the capabilities you need. Many popular games are powered by it. So whats wrong? It's easy to get started, it's expandable, and able to throw every thing you throw at it.
  Now truth be told, this isn't the multiplayer I wanted. But it is a compromise we took as a first "beta" release. What I wanted was an easier solution where we handle the server, and all the hard parts. You just focus on making the game. But we had to be realistic with the resources and time we had.

• Encryption: I don't think this is needed. You're building mobile games, not banking software. But you already know my feelings on this, we've discussed it before. Now that being said, doesn't mean something like this will never be added. Like most things we add, we need to make sure the community is ready for it. Right now, users are still learning and testing the http requests and socket behaviours. No point in adding another really complicated function that is only left be unused. Our very limited development resources and be applied in better ways.

• Sandbox: I think your name for it doesn't really fit. But eventually, we'd like the ability to reference an object by its name. This way you can do things with a spawned object before it even exists. Now that being said, you can do a lot of stuff with the attributes system. There have been users who have been able to track spawned objects by creating an attribute and using the attribute to reference it.
  Additionally, we'll be adding a "Hierarchy" system, where objects can have children objects and this makes it have proper groups and greater control over the objects in your scene.

• Code Blocks: We're working/planning on something like this. We want our "Functions" to work this way. Where you can share predefined blocks of behaviours.

• Rate: Cool idea. We'll look into something like this down the road.

• iAP: already planned. We want to roll out a simple in-app purchase system. There are just a few things we need to do first. For example, we want this to also work with hub projects. So we'd need to create some sort of community point system where it can be used to substitute money.

Any ways, we're working on it. You're right hyperPad still has a long way to go. But we're committed to the product, and more so committed to the community.

[Thecheater887]

I appreciate the in-depth response, and it greatly helped answer many of my questions, but some still remain.

The pricing and splitting was intended to split the users that aren't serious from the ones that are. Now, I'm no business leader and Fortune 500 holder, but in my mind, even though this drastically reduces the user count, it greatly increases the value of the feedback you receicve, also reducing the 'garbage' user from upgraded teirs, excuse the harshness. By that, I mean your everyday underbridge-dwelling troll, users that only stay for the "Oooohhh Shiney!" effect, and similar hazardous users, possibly in the future allowing for the service to rival against traditional text coding languages for mobile development. Again, though, I've never had the chance to test it, but on paper it pans out :D

The socket issue is one I will have for all of eternity; I have honestly never heard of socket.io in my life until you guys implemented it. As such, it was difficult for me to even try to begin to find where to learn it from. It doesn't invalidate your point, but it's a double edged sword based on the userbase you are targeting.

Let me bring up a gaming console. Usually, when a new version releases, it has a ton of never seen before features, and isn't pushed past its' limit for years after initial release. But that's hardware, I'm sure the logic and math behind software isn't the same, but again, on paper it pans out.
I guess as long as we may get more options for networking in the future when you aren't so resource tied, I'll survive!

For it's current state, you are correct, encryption won't be required or even necessary, but if the app progresses enough, let's just say I appreciate you being open to future ideas!

No, 'Sandbox' doesn't fit, but I couldn't think of any other name unfortunately. I do believe you may be missing the point of this, but I don't know what it's going to look like when it's finished, either, or if you already have a fix in the works even. Only one way to find out!

Again, I greatly appreciate the feedback and willingness to adapt you have, not many out there do!

[Jack8680]

@Thecheater887 A lot of interesting things here. The one thing I don't really agree with is separating tiers more, I think the current way is fine. That being said, I don't know about marketing or sales, but I feel like there is enough incentive to upgrade from free user to indie, the upgrade to developer is more for people who want to eventually publish/monetise something in my opinion.

Encryption could be useful for some things but I don't think it's really an important feature right now since barely anyone would use it.

Code blocks/functions would be cool, also for sharing solutions through the forums without them having to copy every behaviour over manually.

The iAP system sounds cool, since not everyone likes ads.

I still have to learn socket.io, I tried to get it working in plain PHP but that didn't work out. HTTP requests are great so far though, for turn based games.

One suggestion I have that I doubt would ever happen but would be really cool is to run JavaScript. It's already run with the open URL behaviour, and it can be run serverside, but it'd be really cool to run some heavy calculations directly in JavaScript rather than behaviours. The wolfram alpha API does a good job of heavy and complex calculations but it's serverside so if doesn't do them fast enough.

[Greg Smith]

From the standpoint of any kind of paying user - I think allowing the "Night Time" dark interface theme is quite important.

If you look at the way Unity has restricted a Dark Theme to Pro users - and the resulting uproar among users - it may save you from this kind of flack if you give people a break, now. For many it is a health issue, not a luxury feature or an advanced feature.

I think the tier price points are really reasonable - for nearly every conceivable user - so no change is needed there.

But, the name "Indie" for every platform I can think of implies "making games for money". Perhaps you could consider naming the $4.99 tier to "Enthusiast". I would avoid the name "Hobbyist" like the plague - or even "Amateur". Nobody likes a label that puts them in an inferior category.

This is why, in serious forum circles, the term "Newbie" should be utterly abandoned.

Greg Smith