--- Log opened Fri Dec 07 00:00:27 2012
20121207 00:19:46-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-lobbydev
20121207 00:20:02< crimson_penguin> noy: done
20121207 00:20:06< noy> This is now going to be our Iphone port channel
20121207 00:20:26< noy> What's the relative advantages over #2 in that email crimson_penguin ?
20121207 00:20:52< noy> Would we not require more of a rewrite of all the optimizations that he created?
20121207 00:21:31< noy> http://nasawatch.com/archives/2009/07/augustines-laws---and-ares-1.html
20121207 00:21:36< noy> for some fun reading
20121207 00:21:42< crimson_penguin> Yes, but it seems like that would be a good thing anyway (from what I hear the code is rather messy), and given the goals of this project, it seems like future upgradability is very important
20121207 00:22:08< crimson_penguin> And I'm not sure how easy it would be to do #1 anyway
20121207 00:23:23< noy> so basically it might be the better of the two options?
20121207 00:23:31< noy> err the better of two bad options?
20121207 00:23:46< crimson_penguin> yeah, I mean either way it's gonna be a bunch of work (is my impression)
20121207 00:24:35< crimson_penguin> (maybe you should just prepend everything I say with "my impression based on what little I know of the code is that ")
20121207 00:25:20< noy> See the way I see it is whether a big bang or iterative approach might be better
20121207 00:25:47< noy> #2's advantage is that we can section out the blocks and release them incrementally
20121207 00:26:08< crimson_penguin> Well, I see #1 as a better beginning for an iterative approach; we don't have to do all the optimizations at once
20121207 00:26:19< noy> so that we can continue to generate sales, and we don't starve financially overtime
20121207 00:26:43< crimson_penguin> errr, #2
20121207 00:26:47< noy> In the long term or short ter...
20121207 00:26:48< noy> ah
20121207 00:26:55< noy> Okay, I was like... how does that work?!?
20121207 00:28:19< noy> Correct me of I'm wrong but #1 requires less total work, but more of it up front
20121207 00:28:34< noy> #2 requires more work, but it can be undertaken iteratively.
20121207 00:28:57< noy> and therefore extended longer
20121207 00:29:12< crimson_penguin> Yes, except that in the long run #1 will require more work, because it'll be harder to update in the future
20121207 00:29:24< noy> you mean #2 again?
20121207 00:29:33< crimson_penguin> no
20121207 00:29:40< noy> really?
20121207 00:30:10< noy> So #2's real issue is that its just a messy codebase?
20121207 00:30:18< noy> and we're spending money to upgrade?
20121207 00:31:34< crimson_penguin> wait... I have been so confuuused
20121207 00:31:36< crimson_penguin> I meant #1
20121207 00:31:53< crimson_penguin> I've had it reversed for a bunch of what I said :-/
20121207 00:32:05< crimson_penguin> I favor approach #1
20121207 00:33:09< crimson_penguin> I DID mean #1 when I said "err #2"
20121207 00:33:31< crimson_penguin> and #2 will require more work in the long term, because it'll be harder to keep updating over time
20121207 00:37:38< noy> See the problem I have with #2 is that from a business standpoint it causes problems
20121207 00:37:46< noy> ERR
20121207 00:37:47< noy> #1
20121207 00:38:27< crimson_penguin> Well, how are sales now?
20121207 00:38:41< noy> First, basically we're going to have to build an entirely new program. Obviously its not from scratch, but its pretty much like that
20121207 00:38:47< noy> steadily declining
20121207 00:38:58< noy> and we won't receive anyy more cash from kyle
20121207 00:39:14< noy> so 40K in revenue we should have received is gone
20121207 00:39:20< crimson_penguin> The nice thing about #1 is that long-term, the code will be integrated into the main codebase, and so it'll be testable by anyone who wants to test it, and then the main developers can fix stuff proactively for iOS, etc.
20121207 00:39:20< noy> or 20K I can't remember
20121207 00:39:44< noy> Can you give me some idea of how much work that will require?
20121207 00:39:49< crimson_penguin> Wow, why is that? Is that just part of the deal with him handing over future profits?
20121207 00:40:01< noy> yes
20121207 00:40:20< noy> I think we have something like 30K in the bank.
20121207 00:40:38< noy> taxes will eat into that though
20121207 00:41:19< crimson_penguin> Well, I imagine it would be similar to how much work he had to put in, but hopefully significantly less, because we don't have to include all optimizations up front (he had to do more because devices were worse), and because his codebase is there for reference
20121207 00:41:38< noy> See, that's the issue
20121207 00:42:19< crimson_penguin> It should really be a lot less work though, I think... I mean I guess we could ask that person who did port it more recently and didn't do as much, how long it took them?
20121207 00:42:20< noy> We're goingto have to pay for this
20121207 00:42:27< noy> True
20121207 00:42:33< noy> though its "much inferior"
20121207 00:42:41< noy> accoring to Kyle
20121207 00:42:51< crimson_penguin> Yes, but thinking long term, #1 will be superior
20121207 00:43:05< crimson_penguin> Personally I didn't think Kyle's port was that great in the first place :P
20121207 00:43:08< noy> Is there any way to combine the two approaches?
20121207 00:43:16< crimson_penguin> Which may make me a bit biased...
20121207 00:43:38< noy> Work on #2 then overhaul it later significantly?
20121207 00:44:05< crimson_penguin> Yeah, could do, and it would probably work best to do that if it was the same person (or people) working on both of those
20121207 00:44:22< crimson_penguin> They would get familiar with the code doing #2, which would help a lot doing #1
20121207 00:45:27< noy> the other issue is how does this look to customers
20121207 00:45:38< noy> We have two options here
20121207 00:46:01< noy> Honor how kyle offered wesnoth: basically you paid once and received free upgrades
20121207 00:46:16< noy> or say we're a new company, and you must pay again
20121207 00:48:28< crimson_penguin> Ideally we allow free upgrades for existing customers, but if we can't transfer the game, then we can't do that
20121207 00:55:49< noy> right
20121207 00:56:05< noy> Apple won't allow it?
20121207 00:57:24< crimson_penguin> It's been done, you just have to have enough clout for Apple to bother doing it for you, as far as I can tell
20121207 00:57:40< crimson_penguin> There's no interface to do it, but they've done it for Zynga at least, when they bought up other companies
20121207 00:58:59< noy> right
20121207 01:03:18-!- Sirp [~justme@wesnoth/developer/dave] has joined #wesnoth-lobbydev
20121207 01:04:02< noy> The other problem with #2 is that we might not be able to offer an iterative solution to the main issue, multiplayer lobby
20121207 01:04:18< noy> that it requires us to resolve everything else so that we can get it to the current version
20121207 01:05:13< crimson_penguin> I wonder if the UI for the MP lobby should be done entirely natively anyway; might be easier and a better experience
20121207 01:07:42< noy> rather than porting it over?
20121207 01:08:08< noy> would they get to interact with "regular" players
20121207 01:08:16< noy> or  a dedicated MP server
20121207 01:09:20< Sirp> crimson_penguin: that would certainly be *ideal*
20121207 01:09:40< Sirp> however there are lots of things that would be ideal. If possible I would love to have a port of Wesnoth which extensively recustomizes things to make them ideal for a touch interface.
20121207 01:09:43< crimson_penguin> noy: just the UI would be native, so yes, the backend would be the same
20121207 01:09:46< Sirp> do we have developers interested and willing to do it though?
20121207 01:10:01< noy> nope
20121207 01:10:08< noy> well we haven't started looking
20121207 01:10:18< crimson_penguin> Sirp: well, if we DO have someone who knows what they're doing on iOS, it might be actually easier than trying to port the existing UI... I don't know for sure though
20121207 01:10:46< crimson_penguin> the UI for a chat interface wouldn't be that hard to make on iOS, I think
20121207 01:13:47< noy> to recap, my personal perspective is that we should follow path #2 that kyle suggests
20121207 01:14:14< noy> basically employ an iterative approach that allows us to maintain some income over the next few years
20121207 01:14:29< noy> and upgrade the program as we go along
20121207 01:17:08< noy> the alternative is to basically go with a "clean sheet" that will take time to build
20121207 01:17:31< noy> which we may or may not get released
20121207 01:17:47< noy> #1 requires a significant upfront investment of time (ie money)
20121207 01:18:27< noy> #2 is more flexible
20121207 01:18:35< noy> and requires less money
20121207 01:18:39< noy> upfront that is
20121207 01:25:41< Sirp> yeah I think #2 is best
20121207 01:25:51< Sirp> I mean I think we have to go to that immediately to get our port up
20121207 01:25:57< Sirp> if then we want to later try to go for #1 that's fine
20121207 01:26:01< Sirp> but let's get something up asap
20121207 01:29:56< crimson_penguin> I guess if we don't have any good iOS developer who wants to work on it then that makes sense
20121207 01:30:06< Sirp> it makes sense in any case
20121207 01:30:14< crimson_penguin> I suppose
20121207 01:30:28< Sirp> because it plain makes business sense -- we need a revenue stream asap if we are comfortable with paying people do to this.
20121207 01:30:35< crimson_penguin> I would be interested myself, but I've already got a job, and I tend to have a lot to do when I'm not at work too
20121207 01:30:41 * Sirp nods
20121207 01:30:50< crimson_penguin> yeah, you're right
20121207 01:31:31< Sirp> and the effort to get Kyle's existing code up and working should be very small, I'd think/hope
20121207 01:32:09< crimson_penguin> yeah, I hope so, do you know what exactly it entails?
20121207 01:35:58< noy> Well doesn't that depend what we want to do as spirals?
20121207 01:36:30< noy> there are the bugs that he didn't fix
20121207 01:36:37< noy> I don't know what they are or how serious they are
20121207 01:36:45< noy> So that's an open ended question
20121207 01:37:01< noy> Getting it up to our current functionality requires a lot of work
20121207 01:37:32< Sirp> well I think we should just take what Kyle has and put it up as-is directly
20121207 01:37:40< noy> sure
20121207 01:37:45< Sirp> make it exactly the same as what he has, but with our account
20121207 01:37:50< Sirp> after that we can talk about making improvements.
20121207 01:38:01< noy> the other question is that how do we deal with previous customers
20121207 01:38:17< noy> because we might not be able to transfer their accounts
20121207 01:42:02< crimson_penguin> from a business perspective I think it's kind of a non-issue, because if we can't transfer them, we have a good reason to say "we want to give you a free copy but can't", and in the end we probably get more money
20121207 01:42:39< crimson_penguin> if we can then we should, I think, because that's generally how it works, and how it has worked in this particular case
20121207 01:48:11< Sirp> yeah I don't think we can
20121207 01:48:19< Sirp> we should put in an 'effort' by asking Apple
20121207 01:48:21< Sirp> but I don't think we can
20121207 01:48:36< Sirp> I think it's unfortunate but I think our customers will have to understand our hands are tied
20121207 01:55:12-!- Sirp [~justme@wesnoth/developer/dave] has quit [Disconnected by services]
20121207 02:05:52< noy> crimson_penguin: okay... well that should be the outline of our plan
20121207 02:06:09< noy> So now we need to figure out what we want to do with the version
20121207 02:43:16< crimson_penguin> noy: so if this is our plan, I guess if I could get the source asap I could see how hard it is to compile it
20121207 02:45:20< crimson_penguin> (and I gotta go now)
20121207 03:25:29-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20121207 06:20:17-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-lobbydev
20121207 13:54:26-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20121207 14:46:39 * Soliton wonders what email is being talked about and what approach #1 and #2 in it is.
20121207 18:19:57-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-lobbydev
20121207 19:18:53< crimson_penguin> Soliton: the email is from Kyle Poole, and the approaches he suggests: "1. Branch the mainline and retroactively apply my improvements, being careful to use compile directives so that it can be merged back." "2. Use my code and update it for multiplayer compatibility with the latest version."
20121207 21:31:22< Soliton> 2 sounds difficult if there should be any kind of certainty about that comptibility.
20121207 21:34:55< Soliton> you could update the data files and do some tests whether it seems to work... but then the updated data files surely will depend on new features/bug fixes so even that is possibly not very easy.
20121207 21:35:33< Soliton> 1.6 was a long time ago.
20121207 21:37:01< Soliton> what's the idea anyway? if we do either approach Kyle will allow us to 'take over' the wesnoth app?
20121207 22:52:09< crimson_penguin> yeah, I'm not sure how straightforward 2 really is; I don't know what's changed
20121207 23:07:54< noy> the problem is that we don't have the resources to do #1
20121207 23:08:14< noy> frankly a clean sheet build might leave us with no money and a no program
20121207 23:08:20< crimson_penguin> well I think really we want to do neither, we just want to release what already works
20121207 23:08:52< crimson_penguin> we could just put up the old MP server instead of updating the game to work with a new one
20121207 23:10:58< Ivanovic> this s*** always happens when you basically do a fork of something and hardcode your changes instead of nicely fitting them in into the existing stuff
20121207 23:11:13< Ivanovic> sorry, but neither #1 nor #2 are likely to work
20121207 23:11:24< Ivanovic> though the only thing possible at all is #1
20121207 23:12:18< Ivanovic> in fact i would more or less say #3 is the only option: try to abstract some off the stuff kyle has done and then merge it into mainline
20121207 23:12:53< crimson_penguin> well what I figured was yeah, basically redo everything, an use Kyle's code as reference
20121207 23:13:11< crimson_penguin> but FOR NOW, to have an income, just release his code with no changes at all
20121207 23:13:45< Ivanovic> what about the stuff the other guy has done?
20121207 23:14:02< Ivanovic> would that possibly be a better target for merging into mainline and from there trying to incorporate what kyle has done?
20121207 23:14:10< crimson_penguin> we could also start with that instead, maybe we need someone to try both and decide which is better
20121207 23:14:18< crimson_penguin> yeah, could be
20121207 23:14:34< Ivanovic> my guess is that the latter is better since it already runs on iOS and is based on the latest wesnoth
20121207 23:15:02< crimson_penguin> well the first step is to release an unmodified copy of either Kyle's code or that other guy's
20121207 23:15:04< Ivanovic> the next step would be UI improvements and speedups (where appropriate since it should be done in a non hardcoded way)
20121207 23:15:18< Ivanovic> my guess is: best would be to release *both* in our repos
20121207 23:15:29< Ivanovic> this way nobody can say "you are not following the GPL"
20121207 23:15:34< crimson_penguin> eh?
20121207 23:15:44< crimson_penguin> I mean put up for sale on the app store
20121207 23:15:48< Ivanovic> ah, okay
20121207 23:16:38< crimson_penguin> maybe the other guy's is a better idea, but I'd have to try them both to be sure
20121207 23:18:50 * crimson_penguin downloads them both on his iPhone 5
20121207 23:49:29-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
--- Log closed Sat Dec 08 00:00:54 2012