设置逐帧菜单导航与所有代码
当涉及到包括闪存在内的任何事情时,我都是程序员。我不久前开始制作游戏,有些人使用框架从主菜单导航到游戏屏幕等(我不知道该怎么做)。有些人将游戏封装在一个类中,并从文档类中调用它,并在需要时添加和删除它。
我只是好奇这方面的最佳实践是什么以及最有益的是什么。专业人士做什么。
I am All Programmer when it comes to anything including flash. I got into making games not to long ago and some people use frames to navigate from the main menu to the game screen and so on (which I have no idea how to do). and some people encapsulate the game inside of a class and call it from the document class and add and remove it when please.
I am just curious of what is the best practices when it comes to this and what is most beneficial. What do the pros do.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
使用时间线通常被认为不是最佳实践。您往往会发现开始编程的设计师往往会大量使用时间线,因为这就是他们所习惯的。此外,从 AS1 或 AS2 开始的程序员往往有坏习惯。如果某件事值得做,那么就值得正确地做。
使用时间线的问题是管理变量状态。如果您随后移动到另一个帧(第一帧除外),则在一个帧中声明的任何变量都将丢失。为了演示这个基本示例:
在第一个框架上有一个选项按钮,单击该按钮后会转到另一个框架“选项”。该选项框架有一个复选按钮,并且还声明了另一个对象。它还具有返回主菜单的按钮。这就是编译器将其生成代码时的样子:
现在这就是问题所在。如果您要导航到选项页面然后返回主菜单,那么您最终会重置变量状态,因为您现在创建了我的世界的新实例(并且内存使用量会上升,因为垃圾收集器不会立即进行)。您现在在选项页面中也丢失了实例。
我的菜单编码风格是将每个屏幕创建为影片剪辑。然后将每个影片剪辑放置在第一帧上但位于不同的图层上。然后我隐藏/显示我想要的图层。它也很容易从外部类进行控制,并且设计速度同样快,并且避免了我提到的任何陷阱:)
Using the timeline is generally regarded as not best practise. You will tend to find designers who start programming tend to use the timeline a lot as thats what they are used to. Also programmers who started off with AS1 or AS2 tend to have bad habbits. If something is worth doing its worth doing properly.
The problem with using the timeline is managing your variable states. Any variables that are declared in a frame will be lost if you then move to another frame (except for the first frame). To demonstrate imagine this basic example:
On the first frame there is an options button that when clicked goes to another frame "options". This options frame has a check button and also declares another object. It also has a button to return to the main menu. This is what it looks like when the compiler has generated it into code:
Now this is where the problem lies. If you were to navigate to the options page then return to the main menu you would end up resetting your variable state as you now create a new instance of my world (and memory usuage goes up as the garbage collector won't be instant). You have now also lost your instance in your options page.
My coding style for menus is to create each screen as a movieclip. Then place each movieclip on the first frame but on different layers. I then hide/show the layer I want. Its also easy to control from external classes and just as quick to design and avoids any of the pitfalls that I mentioned :)
如果您从 Flash 开始,只是 IDE,然后学习如何编码,那么浏览框架就很有意义,因为它非常容易理解/实现。
我能想到的唯一优点是对象始终存在,因此当您从一帧转到另一帧时,一旦对象被实例化,它们就会在那里为您服务,因此无需删除所有内容,然后再次添加所有内容。
我猜像 Keith Peters 这样的专业人士在视图和菜单中编写代码 100% 。一旦您制作了漂亮的小游戏引擎(带有菜单和屏幕)即可重复使用( Asobu),时间线对于切换视图来说似乎有点毫无意义。从这个角度来看,PushButtonEngine 看起来很棒。
如果您正在与设计师合作,并且他/她正在设计屏幕,并且时间轴导航对他/她在原型制作时更有意义,我猜有一个中间立场。只要每个屏幕都是一个独立的 MovieClip,在主时间线内,您就可以为每个屏幕 MovieClip 设置一个类并从那里继续。如果您需要为您声明阶段实例,我写了
我的猜测是,对于快速添加按钮攻击的短独立游戏,时间线会做得很好。如果您计划重用基本引擎并制作更复杂的游戏,从长远来看,actionscript 将证明是正确的决定。基本经验法则:不要无缘无故地将事情复杂化。
If you start with Flash, just the IDE and then learn how to code, navigating through frames makes sense as it's dead easy to understand/implement.
The only advantage I can think of is that objects are always there, so when you're going from one frame to another, once the objects are instantiated, they'll be there for you, so no need to remove everything, add everything again.
I'm guessing pros like Keith Peters code there views and menus 100%. Once you make your nice little game engine ( with menus and screens) ready to be reused (Asobu), the timeline seems a bit pointless for switching views. The PushButtonEngine looks great from this perspective.
If you're working with a designer, and he/she is designing the screens and the timeline navigation makes more sense for him/her while prototyping, I'm guessing there is a middle ground. As long as each screen is a MovieClip on it's own, inside the main timeline, you can set a Class for each screen MovieClip and carry on from there. If you need something to declare stage instances for you, I wrote a tiny extension that could give hand with that. Then you can carry on with the logic in your preffered IDE.
My guess is for quick additive button bashing short indy games the timeline will do just fine. If you're planning to reuse a basic engine and make more complex games, on the long run, actionscript will prove the right decision. Basic rule of thumb: Don't over complicate things without reason.
我认为使用时间线被认为不是最佳实践真是太遗憾了。我觉得这主要是 Adobe 的错,因为在 AS3/CS3 推出时没有提供如何根据良好开发实践使用时间线的文档。
如果您使用时间轴,您有更多选择,例如加载嵌入对象时,这意味着您不必在电影开始之前下载那么多代码 - 所以您没有那么长的预加载器为了宣传您是一位编码忍者,您在第 1 帧之前嵌入了所有内容。当然,当用户知道他们正在查看由编码忍者创建的内容时,他们会更高兴,因此他们愿意等待特权。
您可能会发现这种替代观点很有趣 http://www. developria.com/2010/04/combining-the-timeline-with-oo.html
I think it's a real shame that using the timeline is regarded as not best practice. I feel this is largely Adobe's fault, for not providing documentation of how to use the timeline in accordence with good development practice when AS3/CS3 came out.
If you use the timeline you have a lot more choices about things like when your embedded objects get loaded, which means that you don't have to download so much code before the movie will start--so you don't have that long preloader to advertise that you're such a coding ninja you embed everything before frame 1. Because of course users are much happier when they know that they are viewing something created by a coding ninja, so they're willing to wait for the privelege.
You might find this alternative perspective interesting http://www.developria.com/2010/04/combining-the-timeline-with-oo.html
就我个人而言,我倾向于仅使用 Flash IDE 来创建资源 SWC 文件。我所有的逻辑和编译都是使用 FDT 完成的。编译时间要快得多,并且调试器可以正常工作。
主要的例外是横幅,因为大多数广告服务公司使用 Flash 扩展与其后端进行通信,因此需要在 IDE 中工作。此外,对于横幅,设计师完成了大部分工作,而我只有在需要结合无法在时间线上完成的更复杂的交互时才真正参与其中。
底线:尽可能以你觉得舒服的方式工作,但要有能力以你需要的方式工作。
Personally I tend towards only using the Flash IDE for creating asset SWC files. All my logic and compilation is done using FDT. Compilation time is much faster and the debugger works.
The main exception to this is banners, because most ad serving companies use Flash extensions to communicate with their back end, and so working in the IDE is required. Also, with banners a designer does most of the work, and I only really get involved when it comes time to tie in more complex interactions that cannot be done on the timeline.
Bottom line: work however you're comfortable when you can, but be capable of working however you are required to.