-
Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.
If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.
- The Lone Wolf Development Team
Hero Lab on Android
- Thread starter alexdevus
- Start date
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.
I totally agree that a web app and native app are totally not the same thing (unless you're using something like phonegap, which is its own nightmare to work with). Especially considering that a web app means that you're dealing with a distributed hosting of authentication in terms of user data and access, plus it would be mandatory that the user would have internet access in order to use the application... which would be a huge minus for me.
Although it would make it much easier (in theory) to distribute updates and validate licenses.
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!
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.
We're not just working with an 8 year old code base - we have a number of files in source control with creation dates in the late '90s! Some of the code Hero Lab is based on is 15-20 years old at this point, and first saw the light of day many years ago in our first product, Army Builder.
The iPad app wasn't written in 2006 either. I'm not talking about HL being web based from the start, I'm saying offering effectively a web based UI for HL, one that could be pulled up on either an iPad, Android, windows mobile, or a PC.
I guess that's the major disagreement then. MOST gaming does not happen at a Con. Is that use once or twice a year really the target audience of this program?
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.
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.
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.
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.
sometimes rewriting from scratch is actually easier, though. We had to do that at our current company, take a 10+ year old codebase and make it a responsive web application (using a restful framework), and we shocked ourselves. it was nonstop work, but we did more in 4 months than we thought possible. That being said - i dont think HeroLab would be a good web application. I much prefer it as a standalone. There are a lot of other issues to consider. For a web application to be responsive, you dont want it to be file based, and thats one of the real strengths of HeroLab, in my opinion. Then of course there are servers to consider, services, etc. now while i can imagine that given their druthers, they might redo some architecting, (no developer is EVER happy with their product, not really *grin*), i dont think just assuming "web app", is the way to go.
There are always plusses and minuses for every type of application, and in the case of HeroLab, I think standalone makes a lot more sense than web app.
Last edited:
From what I understand from the kickstarter, it was either always in the plan, or at least very early on from the time when they decided to do cloud syncing. and from what i understand stripped down version. But thats not the key point. and this is obviously only for people who have their data synced to the cloud. So not really a fair comparison.
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!
My point was the contradiction between deciding to forgo a web interface for HL because:
and then limiting the player view in Realm Works to the cloud service, and not even a local web server in the Realm Works program itself.
ummm.... the Player Version is not limiting players to active internet access. That would only be if they wanted to sync data. So, it doesnt go against Rob's statement about Cons.
What you're referring to is the FREE website player access, which is going to come later. Players who sync their data on their paid version will be able to use their data without connecting to the internet.
Again, apples and oranges. the model of the application of HeroLab is very different from the model of RealmsWorks. Forgetting even that its a major difference between databases and flat files, the licensing, everything is different. But even RealmsWorks isnt a web app. IT doesnt require internet.
I commute to work for a few hours a day. I sometimes take my laptop. During that time, I work on both RealmsWorks and HeroLab. If I was required to have an internet access, I wouldnt be able to do so. Same thing for when I run my games. (sometimes I run games in a store that doesnt provide WiFi).
Then of course there's the reality of a web app with non-database. Reading and writing to files is slow. And of course the file would have to be stored somewhere. You'd have to run a server. Local web service? Maybe. But then its just local. In some ways, it would be even slower, and use more memory. The list goes on. There are a lot of pros to doing web app. There are a lot of cons too. Its never a simple thing.
What you're referring to is the FREE website player access, which is going to come later. Players who sync their data on their paid version will be able to use their data without connecting to the internet.
Again, apples and oranges. the model of the application of HeroLab is very different from the model of RealmsWorks. Forgetting even that its a major difference between databases and flat files, the licensing, everything is different. But even RealmsWorks isnt a web app. IT doesnt require internet.
I commute to work for a few hours a day. I sometimes take my laptop. During that time, I work on both RealmsWorks and HeroLab. If I was required to have an internet access, I wouldnt be able to do so. Same thing for when I run my games. (sometimes I run games in a store that doesnt provide WiFi).
Then of course there's the reality of a web app with non-database. Reading and writing to files is slow. And of course the file would have to be stored somewhere. You'd have to run a server. Local web service? Maybe. But then its just local. In some ways, it would be even slower, and use more memory. The list goes on. There are a lot of pros to doing web app. There are a lot of cons too. Its never a simple thing.
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.
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.
At least 2! And frankly, that would assume you had a separate development team that you trusted enough with your product not to create some sort of mess (which kind of rules out consultants). Plus, this effectively doubles your labor costs while providing nothing to your consumer base, which in two years time would all but certainly kill your bottom line. Even if you had unlimited capital, you'd still have to manage it all with everything you have, and the mythical man month would certainly play into everything.
Creating a java port of the stand alone app probably wouldn't be as monolithic, but it's certainly a massive stretch in resources, plus a tremendous added cost in support (I can just hear Sesame Street's Count singing "3... 3 codebases ah ah ah"). One thing I easily overlook as a consumer is that hero lab is not just a pathfinder module. There are dozens of other systems that I don't have a personal care for which are included in this package. Even if they were all separate versions of hero lab (e.g. download the pathfinder .exe versus the 4e .exe), that'd still be separate code to maintain. Just supporting iPad is a pretty substantial investment, especially given how much of a pain objective-c is in my opinion.
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.
I was in no way trying to get Hero Lab to sync to the cloud, I see no point in that. My intentions were to have the ability to view and manipulate profiles via a web server running within hero lab on a PC. As described, this is not porting anything over to anything else, it is effectively rendering the same data to a different target. Then, you could have a single PC/laptop running HL, with profiles for all party members, and each member could use their portable device, regardless of OS, to connect to it and not just display the data, but manipulate it as well (at least the ability to add/set adjustments and conditions).