Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Yet again, all this PR struggle would have been avoided by simply making a web based client instead of the iPad version - likely would have been easier to build as well.
A web based app would not be easier to build that a native app. We built Hero Lab back in 2006, when web apps were in their infancy. Gmail Beta had only come out 2 years before. Making a web app now would require a ground-up rewrite of nearly the whole program. That ground-up rewrite would take significantly longer than getting native apps to our users.
If we were starting from scratch today, we might make different decisions - but writing for a web app in 2006 wouldn't have made sense for something as complex as Hero Lab.
Yet again, all this PR struggle would have been avoided by simply making a web based client instead of the iPad version - likely would have been easier to build as well.
However, are you saying that you are running on an 8 year old code base? How are you able to manage your technical debt with code that old? Any project that I've worked on in the last 20 years that was that old was obscenely difficult just to add in a small feature, and invariably anything older than 5 years (in production) is typically easier to rewrite than maintain. You must have some combination of very low turn around, small staff, stringent coding standards, lean feature sets, and skilled developers, or perhaps you're all just insane!
However, are you saying that you are running on an 8 year old code base? How are you able to manage your technical debt with code that old? Any project that I've worked on in the last 20 years that was that old was obscenely difficult just to add in a small feature, and invariably anything older than 5 years (in production) is typically easier to rewrite than maintain. You must have some combination of very low turn around, small staff, stringent coding standards, lean feature sets, and skilled developers, or perhaps you're all just insane!
A web based app would not be easier to build that a native app. We built Hero Lab back in 2006, when web apps were in their infancy. Gmail Beta had only come out 2 years before. Making a web app now would require a ground-up rewrite of nearly the whole program. That ground-up rewrite would take significantly longer than getting native apps to our users.
If we were starting from scratch today, we might make different decisions - but writing for a web app in 2006 wouldn't have made sense for something as complex as Hero Lab.
Have you ever walked around a Con and looked at the gamers using their iPads (and Android tablets) at the assorted tables? Have you ever stopped to consider how many of those tablets actually have an ACTIVE internet connection over 3G (or comparable)? A web-based app would have simply traded one limitation for another. It would not have truly solved anything.
In addition, and it would NOT have been easier to build. It actually would have been significantly harder to build, since we would have had to largely rewrite the Hero Lab engine for a web-based app instead of re-using it on the iPad. So there's that consideration as well.
If the code is well-engineered, highly data-driven, and has a small, stable team working on it, you can readily get 10+ years of life out of a code base. As you surmised, we have extremely low staff turnover, a small team to begin with, a well-engineered design, and a good team. The fact that everything is substantially data-driven is a huge factor as well.
Oh, and we're insane, too! Well, at least *I* am.![]()
I, obviously, don't know how your code was written, but usually, in a data driven program, the UI rendering and interaction is separate from the data manipulation. Only the rendering and interaction would need to be written for html display/response. It's likely your existing 'panel' objects would be able to be ported to the HTML, while leaving the data side alone.
It's not that simple. It would be reasonable to port something from a c++ application written on windows to a c app for linux, assuming you weren't married to the windows api when you wrote your app. Similarly, it's not beyond reason to rewrite banking software written in Java for a totally new stack written in Python, assuming you developed good MVC, abstracted your front end and db tier, and could port over much of your same logic to the new code (hell, there are automated tasks that'll do most of it for you). But going from a stand-alone application to a web application is a complete paradigm shift.
It'd be a similar analogy to say that we've successfully built a rocket to the moon, now we just have to do it a little differently so that we can build the internet. There's no reuse, and virtually no overlap in skills, even in terms of business model and logic. As Lone Wolf isn't a huge development shop, I doubt they can just change gears and be a different kind of company. It would probably be easier (and cheaper) to form a sister company to build the application.
The PLAYER version will be part of a Web Application NOT the full version. And as someone else mentioned it will also be tied in to the cloud aspect of Realmworks too. Which Hero Lab does NOT have.Well, the real twist of the dagger, as it were, is that they ARE making a web interface for Realm Works...
The PLAYER version will be part of a Web Application NOT the full version. And as someone else mentioned it will also be tied in to the cloud aspect of Realmworks too. Which Hero Lab does NOT have.
So comparing an Apple to an Orange is a hardly a fair comparison!
Have you ever walked around a Con and looked at the gamers using their iPads (and Android tablets) at the assorted tables? Have you ever stopped to consider how many of those tablets actually have an ACTIVE internet connection over 3G (or comparable)? A web-based app would have simply traded one limitation for another. It would not have truly solved anything.
Well, bravo!
Though, it may not be a bad idea to consider a rewrite at this point, depending on how integrated your various products are. I've always been a fan of vigorous coding standards, reviews, retro-analysis, and so on. I can't shake a quote that an old manager of mine said, with regards to the idea of writing the most maintainable software possible:
"Code is cheap. Write it again if you have to."
There's some wisdom to that adage, though I scarcely want to admit it. It just feels like carte blance to write spaghetti.
Well, the real twist of the dagger, as it were, is that they ARE making a web interface for Realm Works...
The same applies to rewriting the whole thing from scratch as a web app - we could do it, if you don't mind seeing no progress on anything else for at least a year, maybe 2.![]()
Each line of code may be cheap, but together it all adds up! Hero Lab comprises many hundreds of thousands of lines of C, C++, and objective-C code - and that's just the core app behaviors, not even counting any code written for individual game systems.
Rewriting enough of it to make Hero Lab viable as a web app is certainly possible, and we could do it if we had to, but I wouldn't be surprised if it ended up taking at least a year of development time to get even the basics working well. Even if we split that over more than one developer, that means the entire Hero Lab team is doing nothing but porting Hero Lab for at least 6 months, almost certainly longer if we want to support all the features that Hero Lab on the desktop does.
Could we do it? Sure, if we had to. But if we're doing that, we're not spending that time adding more functionality to Hero Lab on the iPad, or adding cool new features like the encounter builder, or making it easier to create Hero Lab data files so that more people can use the editor or build new game systems. Unfortunately we have limited resources, and we need to spend them both on opening up Hero Lab to new audiences, and on features we feel will benefit existing users, who have already supported the company by making their purchase.
The same applies to rewriting the whole thing from scratch as a web app - we could do it, if you don't mind seeing no progress on anything else for at least a year, maybe 2.
That's significantly easier because Realm Works was designed with a server component up-front. If you sync your realm to the cloud, all the data and much of the management logic is already there on our server. While adding a web-based view of things is still a big chunk of work, the overall design of Realm Works makes it much more tractable.
With Hero Lab, everything was designed with the assumption that it's running on something similar to a desktop computer. It's still possible to rework things into a webapp, but we'd have to fundamentally redesign a number of things to make it work. That's something Realm Works doesn't have to deal with, as the server-based nature of the app was baked in to the design.