Bigbuddha zei:
Zelfs de tweens worden gescript
persoonlijk vind ik dah wa 'over the top'.. zag in't begin ook even het grote licht - 'whoah gekunt bijna alles scripten', en het is zo je kan daar héél ver in gaan // maar vaak valt het buiten budget (intensiever) en is het helemaal niet "makkelijker te onderhouden" ofzo.
stoem voorbeeld, wil je'n bal van links naar rechts laten bewegen kan je dat volledig gaan scripten met posities die veranderen en weet ik veel -- maar je kan'm ook op positie1 zetten > positie2 zetten en tween instellen. welk van de twee gaat het snelst aanpasbaar zijn als de klant ineens van mening verandert (en dah's niet nieuw dat men dah doet).. nugoed je kan er meer geld aan verdienen misschien // maar als dat onnuttig wordt is het ook nimeer plezant gewoon.
dah wouw'k toch even kwijt.. kvind dus dat je'n mooie gulden middenweg kan kiezen tussen de twee -- dingen die je 'hergebruikt' (menu items) dynamisch on stage plaatsen, allemaal mee akkoord maar je kan evengoed één item dan nog steeds met frames gedaan hebben om het 'snel aanpasbaar' te houden (in je library, wat dan als instance-template fungeert) dan dat je ALLES tot in de kleinste details in code hebt beschreven.. want die laatste methode is naar mijn inzien 'niet altijd even snel aanpasbaar'. (en in de wereld van deadlines kan je maar beter op tijd iets afhebben)
om dan ff persoonlijk te worden: ik zou liever 10u/dag bezigzijn met zaken aan te passen die nog wat zichtbaar zijn (en dus meer "nieuwe dingen' op die dag gezien hebben) dan 10u/dag bezigzijn aan het aanpassen van foutjes in (iemands) code omdat de opdrachtgever van mening is verandert.. want dah's heel de tijd in code redeneren en je ziet minder afwisselend werk.
__
misschien even een héle vérre vergelijking waar jullie hoop ik nog kunnen volgen; maar XML laat ons toe eigen tags te maken DUS zou je in principe alles dat je maar wil kunnen beschrijven in een xml-file.. zo bijvoorbeeld de beweging die iemand maakt: (puur fictief)
Code:
<beweging>
<linkerbeen>
<xChange>
<xPosVan>214.6</xPosVan>
<xPosNaar>138.5</xPosNaar>
</xChange>
<yChange>
<yPosVan>12.4</yPosVan>
<yPosNaar>224.5</yPosNaar>
</yChange>
</linkerbeen>
<rechterbeen>
<xChange>
<xPosVan>28.3</xPosVan>
<xPosNaar>96.4</xPosNaar>
</xChange>
<yChange>
<yPosVan>356.6</yPosVan>
<yPosNaar>22.9</yPosNaar>
</yChange>
</rechterbeen>
</beweging>
en ga zo maar door met paar honderd(/duizend) regels voor een enkele beweging.. zou het niet handiger zijn gewoon een visuele opname te hebben van de beweging.. wel de flash tijdslijn stelt je daartoe overzichtelijk (met keyframes) in staat, en dat voordeel kan je maar best benutten wanneer het nodig is. voor een computer zou het absoluut niet uitmaken.. keyframes of deze data-sturing, maar voor ons 'mensen' is het vaak handiger iets te kunnen zien // hope we can agree on that bigbuddha
ONTOPIC dan nog even;
hangt van hetgeen je wil bereiken af.. ikzelf begin altijd visueel in photoshop - en ga dan alle elementen omzetten naar flash // dan de datasturing etc tot het geheel 'werkt' zoals het zou moeten werken.. dah's een mogelijke aanpak, je kan ook rechtstreeks in flash ontwerpen maar ik merk daar een beperkte vrijheid voor mezelf -- een lijntje, een kadertje > kheb werkelijk pixels nodig om iets te maken, en zal die pixels nadien wel omzetten naar vectorsquares. (als't een gepixeled ontwerp betreft)
dus "hoe begin je", wel alles begint bij een idee.. en nog een raad:
stop je zoektocht naar een StepByStep guide naar flash websites -- je leert flash / je leert wat een website omvat -- je combineert > en voor je't weet ben je'r al.
good luck.
