Looking for iOS programmers
- Thread starter robject
- Start date
I've looked at iOS programming; have the requisite Macbook Pro, XCode. However, as we ended up hiring a real iOS dev, I just look at his code once in a while...my mac is an expensive Win7 / Win8 machine for the most part. But I can follow & figure out pretty much any coding...
If you were to design a Book 2-like starship design app, say for the iPhone, how would you do it?
Clearly a multi view app. A primary navigation controller, leading to component choice picklists?
The user picks a hull from a list: a size, a configuration, and the type of landing gear. Sounds like two or three pick lists.
Next, the user picks drive performance. Do you suppose it's better to pick performance rather than a specific drive? For example, if the user decides to use a different sized hull, it would be nice to automatically adjust the engineering section, don't you think? Ditto for fuel.
Drives sound like sliders for performance, and even for fuel, but fuel could also be auto calculated.... Since this is not a painfully comprehensive app, maybe automatic fuel would be best?
Next, the user picks the payload. Staterooms, smallcraft, what-have-you. How would this be handled? Sounds a bit more complicated, since there's a list of discrete things being picked and added to the ship.
The computer model is also chosen. Pick list!
Weapons are more varied than in Book 2, but there's no mixing of weapn types within turrets. Also, you can configure the range of a weapon, which changes its size and cost.
Does this mean a weapon has a mini-design page? A weapon type picklist, an emplacement picklist, and a range slider? Or does the user pick the ship's weapons, and some defaults are assigned, and the user can dive in and adjust the settings if desired?
Optional sensors can also be installed, in much the same way as weapons: pick the emplacement, pick the sensor type, adjust its range if desired.
Same for Defenses, I.e. Screens. Emplacement, defense, range. Yes, range, although less important than with weapons and sensors. I'm thinking the code which lets the user select and customize weapons can be re-used with sensors and defenses. Same actions, different plists, maybe?
Suggestions are welcome. Thanks!
Clearly a multi view app. A primary navigation controller, leading to component choice picklists?
The user picks a hull from a list: a size, a configuration, and the type of landing gear. Sounds like two or three pick lists.
Next, the user picks drive performance. Do you suppose it's better to pick performance rather than a specific drive? For example, if the user decides to use a different sized hull, it would be nice to automatically adjust the engineering section, don't you think? Ditto for fuel.
Drives sound like sliders for performance, and even for fuel, but fuel could also be auto calculated.... Since this is not a painfully comprehensive app, maybe automatic fuel would be best?
Next, the user picks the payload. Staterooms, smallcraft, what-have-you. How would this be handled? Sounds a bit more complicated, since there's a list of discrete things being picked and added to the ship.
The computer model is also chosen. Pick list!
Weapons are more varied than in Book 2, but there's no mixing of weapn types within turrets. Also, you can configure the range of a weapon, which changes its size and cost.
Does this mean a weapon has a mini-design page? A weapon type picklist, an emplacement picklist, and a range slider? Or does the user pick the ship's weapons, and some defaults are assigned, and the user can dive in and adjust the settings if desired?
Optional sensors can also be installed, in much the same way as weapons: pick the emplacement, pick the sensor type, adjust its range if desired.
Same for Defenses, I.e. Screens. Emplacement, defense, range. Yes, range, although less important than with weapons and sensors. I'm thinking the code which lets the user select and customize weapons can be re-used with sensors and defenses. Same actions, different plists, maybe?
Suggestions are welcome. Thanks!
Last edited:
Ask yourself if your design supports what a user (putting yourself in those shoes) would want to do - and how they would most naturally do it.
For instance, how well will it support the 'creative' balancing act of ship design - i.e. dropping J-6 or M-6 down in lieu of one over the other? During design one will often want to create 'illegal' designs - then tweak one or more parameters to succeed.
Think how you would support things like running totals (i.e. remaining dTons), percentages (relative proportion), and 'what if' scenarios that might be part of a natural design process.
For instance, how well will it support the 'creative' balancing act of ship design - i.e. dropping J-6 or M-6 down in lieu of one over the other? During design one will often want to create 'illegal' designs - then tweak one or more parameters to succeed.
Think how you would support things like running totals (i.e. remaining dTons), percentages (relative proportion), and 'what if' scenarios that might be part of a natural design process.
I've done a fair bit of IOS development, and the picker setup that you're describing could be done, but with the design you're talking about, you'd generally be doing a lot of "dive into detail" for the picklists, and then jump back to see the effects (at least on an iPhone).
If you had the additional pixels of the iPad or such, you could segment off the pick lists while updating a constantly visible summary, and it would probably be much easier to use and see what impacts your choices were having.
The calculations for fuel and such aren't too bad to do, it's just a question to the ship designer of what impact their choices are having on the overall design as they iterate and work their way through the design process.
Dont know if this helps for what you're after, but hopefully... If you have some IOS specific questions, I can probably give you a bit more detailed answer
If you had the additional pixels of the iPad or such, you could segment off the pick lists while updating a constantly visible summary, and it would probably be much easier to use and see what impacts your choices were having.
The calculations for fuel and such aren't too bad to do, it's just a question to the ship designer of what impact their choices are having on the overall design as they iterate and work their way through the design process.
Dont know if this helps for what you're after, but hopefully... If you have some IOS specific questions, I can probably give you a bit more detailed answer
@joe: yes, I can see what you're talking about, and I did something similar in Flex: the picklists are in a tabbed list on half of the screen, and the running summary sheet is on the other half. In iOS I suppose there'd not be tabs, but rather some other mechanism to manage the complexity of choices.
I'm using cocos2d for iOS. I could let the user drag graphical modules onto a deckplan. I wonder if the iPad has enough screen space for that sort of mechanic -- deckplans get big -- and if it would be friendly, or more usable than picklists. And if I can make that look professional. That's a lot of if's. Maybe paging can help manage the screen options. Left page for drives, right page for payload, page-up for sensors and weapons, page-down for hull options... eeek.
Yeah, it comes down to what the user wants to do, and how we typically design starships -- often by swapping out options, rather than drilling down to exactly what we want.
Or is that precisely true? Isn't there a logical break between payload -- the things we want to carry -- versus engineering -- the drives to move the thing around space? I know in Book 2 and High Guard there's often an upward (or downward) spiral as we add and remove drives and fuel, then pile on payload, then adjust the engineering section yet again, on we go.
It's almost, ALMOST like two loosely-coupled design systems.
I agree that an iPad would give me lots of room, but then I have to really be aware of User Experience, because I can also make lots more mistakes.
I'm using cocos2d for iOS. I could let the user drag graphical modules onto a deckplan. I wonder if the iPad has enough screen space for that sort of mechanic -- deckplans get big -- and if it would be friendly, or more usable than picklists. And if I can make that look professional. That's a lot of if's. Maybe paging can help manage the screen options. Left page for drives, right page for payload, page-up for sensors and weapons, page-down for hull options... eeek.
Yeah, it comes down to what the user wants to do, and how we typically design starships -- often by swapping out options, rather than drilling down to exactly what we want.
Or is that precisely true? Isn't there a logical break between payload -- the things we want to carry -- versus engineering -- the drives to move the thing around space? I know in Book 2 and High Guard there's often an upward (or downward) spiral as we add and remove drives and fuel, then pile on payload, then adjust the engineering section yet again, on we go.
It's almost, ALMOST like two loosely-coupled design systems.
I agree that an iPad would give me lots of room, but then I have to really be aware of User Experience, because I can also make lots more mistakes.
Unless you're already very familiar with Cocos2D and it's use as a graphics framework, that's probably overkill for a "drag a design element onto a deckplan" style of application. You can totally do it with Cocos2D, but that library excels more at the +physics and game/reactive environment than I think you may need.
In IOS - making a grid layout and dragging on like a tileset kind of mechanism and then loading in relevant images with CALayers/UIView - dragging them into place, rotating as you want, etc - would be about the simplest, and you could easily expand/load the graphics detail from PNG images, so they'd be super easy to maintain, grow, etc. If you wanted to port this to Mac as well, I'd suggest working specifically with loading, moving, and dropping CALayers, as that level translates very well back and forth between UIView and NSview mechanisms. Bonus here is that any of these views are incredibly easy to render into standard image (png, jpeg), or vector (PDF) format and export - either IOS or Mac.
I suspect this kind of drag-n-drop UI metaphor with resources to move into place could work really well at the smaller ACS end, might get a little tedious towards the high end, and would totally break down for anything larger
I was originally thinking this later kind of setup, where you can volume, price, and capability that you're trying to trade off and get to exactly what you want - the sort of "if I want to put on another layer of armor, what do I have to give up" kind of question being where lots of back and forth might go. Although to be honest, you might be able to craft a cunning excel spreadsheet (or even Google spreadsheet) that would provide you with enough to trade off, design, and nail down a final combination that you could then translate to a deckplan.
-joe
