I am just getting into object oriented programming, and I was wondering, is it okay to put some code on the timeline, like stop(); and mouseclick events for moving frames, or should all this be on separate files also? If they do belong in other files, how would I go about doing that?
MPO is that you should learn the tool as the tool. I think that the timeline is the very best part of Flash, and if you throw that away, you are making your life harder for no good reason. I think all tools have a "code way" and "some other" way to accomplish what they do, and the default of most developers is to assume that the code way demonstrates your skillz and that "the other way" is so obviously easy that it's not worth your time to learn it.
IME, nothing could be further from the truth. I have learned these "other ways" in several tools/language, and you pretty much always get more power and productivity out of knowing both, at the risk of having a significant fraction of your fellow developers looking down their noses at you because they assume that if you're really good at "the other way" that you are doing it because you can't code. For this reason, there are very few developers who truly understand the full depth and subtlety of the timeline, and there are almost none who will talk about how to do this well.
I actually develop scalable enterprise-level Flash applications using the timeline for clients whose stores you've almost certainly been in within the past couple of days, so I do have a fair amount of experience in this area. My rule of thumb is that stop() is ok if it is unimportant to the overall functioning of the program (it's a visual thing only). However, it gets tedious after a while to keep adding it, so when you get to where you're not under deadline pressure, you'll probably replace that at some point with a Class that uses addFrameScript to do the stop().
The best use for timeline code is when you need to synchronize things (for example, with a streaming sound, which has absolutely zero Actionscript handles to get hold of it). Generate a bubbling event at the precise point where the narrator is saying "click the thingamajig" and you've animated the cursor over the thingamajig. Then, in the AS code that controls the parent of the timeline with the streaming sound (or grandparent, or whatever--somewhere positioned to catch the event), you'd put the thingamjig into the toggled state (for example by changing the data model the thingamajig is responsible for displaying).
Very, very occasionally, I will use timeline code to do something more significant. One example is that a swf compiled by Flash Builder knows what color its stage is, but one compiled by Flash Pro does not, without reading the bytes of the swf. I have a Class that fades a graphic in that can only get the real stage color sometimes, depending on how it was compiled (I'm not goint through the mess of reading the bytes--that's frankly ridiculous). So, I just assume we're fading in from white or something close to it (which we are most of the time). For the rare case where it's not, I've noted in the ASDOCs for the Class that it's ok to just populate the color variable from the timeline rather than worry about how to get it in there through dependency injection. I view this as kind of a poor man's version of the Flash Components properties panel.
Hope that points you in the right direction :).
I think it depends on what you mean by is it okay. (no I am not Bill Clinton)
You'll be hard pressed to get a positive response on this as most of the community on SO are developers and generally are not huge fans of using the Flash IDE/Timeline coding.
That being said, I try to always remain open minded and do realize there's a place for the Flash IDE in creating motion graphics quickly, etc. There's nothing that says you should not code in the timeline, if you absolutely shouldn't do it, they wouldn't have made it possible.
The problem I think arises when you start working with other developers and have to figure out where they buried some code on the timeline within some movieclip that is affecting things. For small projects this isn't really an issue, getting into larger teams (3-5 devs at a time, maybe more) then being able to work independently and collaboratively becomes a challenge.
One last point since you say you're just learning OOP. AS3 is a great language, tons of fun, lots of features provided by the run-time so you can just jump past some of the nitty gritty in C/C++ etc. But the concept of the Timeline is unique to AS3. So if you learn to do everything based on the Timeline, then moving to say C++ or Java or C# or any other OOP will likely be that much more difficult. For now I wouldn't stress about this since you're just getting rolling, but just something to keep in your mind as you move forward.
Edit (response to Ms. Blankenship's good answer and comments from Mr. Mear)
I think there is some arrogance on the side of developers. I can speak for myself in saying I've generally not been a fan of WYSIWYG editors (except when I try to build them, then they're okay :).
A couple of reasons:
They have in my past experience been terrible (take Word or DreamWeaver's code output as examples, try to work on a site some mom and pop threw together in one of those apps and you'll start to hate it too).
If someone was able to get this completely right it would invalidate a lot of knowledge I've built up (so it gets me into a defensive stance, not an objectively valid reason, I know).
Working with bigger teams finding code is key + the code editor is bad (compared with any of the alternatives, Flash Builder [my tool of choice], FDT, FlashDevelop, IntelliJ [my friends' tool of choice]).
Coming from a OOP background that doesn't include anything similar to the Timeline and potentially moving back to those technologies. You have the choice to be great at 1 thing or good at 5 things what do you choose? (I'm vastly over simplifying but hopefully you get the gist). I learned to use Eclipse writing Java, I can use the same tool to write C++, C, PHP, etc. This isn't to say I actually always use Eclipse for everything (lately been using SublimeText a fair amount), but I like that it's always an option. As an aside I'm not an Eclipse "Pure Blood", I started off early on playing with Flash IDE and HTML/JS in Notepad, used Visual Studio for a bit, eventually got pushed into Eclipse but have taken a liking to it for the all in oneness.
Ultimately there are too many factors in this open ended situation to say that one solution is the end all be all. To explain with an analogy, if you were to build a birdhouse a hammer, some nails, and some wood are probably all you need. If instead you want to build your own human house you're going to need some different tools (probably including a hammer, some nails and wood).
Also a related SO post (re-hashes many of the same points):
Why not use Interface Builder
Related
I am planning to create a game with the help of Flash CS3/AS3. This game will feature too many functions and lots of code. A 30-seconds demo alone I've been making here already has 5,000 lines of code, and will only get bigger and bigger as I make progress.
I'm planning on separating snippets of this code into separate as files, so I can embed them on the timeline using the include function, but before I proceed, I need to know: Is this considered a bad practice?
I mean, there will be a point in development where the code will become so huge, it might threaten the game's stability, or am I just paranoid and this is a perfectly normal way to address this issue. Pasting all the important functionality on the timeline and being done with it?
Your ActionScript code isn't going to affect your load time nearly as much as your assets. Any audio assets have to be embedded in your actionscript compile frame, which you can pick from your document properties.
If you're using library assets that are connected to AS Classes, the only place you can really practically defer loading is visual assets that are placed on stage later in the timeline, by not checking "compile on frame X" (whatever frame you selected as your compile frame). Timeline scripts are, as a rule, bad practice, so I assume that you're not using them.
include is also bad practice. I suspect it won't work like you want, but it also breaks compile-time error checking pretty hard.
I can't imagine needing 5000 lines of code for a demo that size, so you may want to revisit your design. Look for places you can reuse code (literally reuse the same code, not copy and paste it).
That's depend a lot if you are using OOP to develop or if you type your whole code in a procedural way. Having some codes drop on separate movieclip/sprite is not a bad thing, I even feel it's good! but that's true if each of them manage themself without depending. For example in a video game if you want to manage with script the animation of a specific monster, that's a great way to write the code inside his movieclip and make sure that his own script doesn't depend on others script.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I'm planning on making a little game. And I'm looking for an engine. Basically what I want is Unity, but then 2D. It's a very interface heavy game, stylized, so what I need is an engine (or similar) in which it's easy to draw lines, primitives and text (and bitmaps, though that's less important.) The game will have a game world, though you'll never directly see it. All you'll get is a bunch of information about it (text, lines, graphs, ...)
I know you could use Unity to make 2D games, though for what I have in mind it's not optimal and the way objects work in Unity isn't really how I want to structure my game. (I've worked a lot in Unity and absolutely love it, though I don't think it's the right tool for this game.)
What I love about Unity is that you can just build for any platform, with a single click, and it just works. It also already has it's own way of building your gameobjects, and since I'm making something very different, I don't want this. I need more control over the objects and actually only want the engine to draw stuff.
I was thinking about using Flash, ActionScript3. It should be very good at drawing lines and text. And hopefully just as easy to build.
I also checked out HTML5 and javascript, using KineticJS, which can draw lines and primites very easily (pretty much exactly like I want it), though I hate javascript and want more structured code. Maybe it's just me that I can't get javascript to be clean enough for my taste, but well, that's something we'll have to live with then :P
My question now is, since I never used flash. What are your thoughts on this. Is it perfect for this kind of stylized text-based games? Is it easy to build (I'm using FlashDevelop since that's a free way to make flash stuff)? On top of that, can I use a single code base for Windows and Mac (maybe even iOS, Android or other, though that's less important)?
Or maybe you have another suggestion I could check out? (I already checked out a bunch of other question here, though none were really helpful. So yea it's another 'I'm looking for an engine' question, so don't kill me for that. I already did quite a bit of looking around, though would love some more input from others.)
Edit1: I've been looking around some more and found Haxe (http://haxe.org/) seems promising, can anyone recommend this or?
I think Flash/AC3 would fit perfectly, especially if you're using FlashDevelop.
To comment on Daniel MesSer:
This means that a programmer "never" has to worry about positioning objects and the visual appearance of the game. The programmer only have to provide the functionality for what should happen when stuff happens (buttons are clicked, animations are complete etc).
This just is not true. If you're work at a company that solely uses Flash CS this might be the case. But with FlashDevelop you've got a fully functional IDE. If you look up some third party libraries like Flixel, Citrus Engine or FlashPunk, you'd find something that could fit perfectly to your needs.
I think that for what you want to do, flash would not be an optimal tool. The beauty of flash and what it was designed to do is to separate and combine what a graphical artist does and what a programmer does.
You see, you have Flash as the tool where you align, position and import/draw graphics and do complex animations. And then you export those as assets and work with the graphical resources from ActionScript. This means that a programmer "never" has to worry about positioning objects and the visual appearance of the game. The programmer only have to provide the functionality for what should happen when stuff happens (buttons are clicked, animations are complete etc).
It sounds as if your game are more in the "techy" family, where you will be working alone, and you want to draw primitives yourself and there will be a lot of text on the screen.
Flash was never intended to be a tool to work with loads of text and doing stuff the techy way, it was created to make it easy to work with loads of graphical resources in a structured way where the programmer doesn't have to worry that much about the graphical content.
If my assumptions of what you want to do is correct, you would be better off working with JS. It would be better suited since you are working with few complex graphical assets, are interested in cross platform support and basically wants to work with loads of text.
I also checked out HTML5 and javascript, using KineticJS, which can draw lines and primites very easily (pretty much exactly like I want it), though I hate javascript and want more structured code.
Write objectoriented javascript :-) I'm a oop-maniac, but I'm starting to find the beauty of js too. It IS possible to write beautiful code even there! ;-)
Regarding flash and AS3, It would be possible, and probably pretty "easy" to use. I started programming using AS2 (well some other stuff before that as well). But personally I dont think flash is the right way to go. Flash have reached it's expiery-date a long time ago.
There are several games coded in HTML5 and KineticJS. You can find some examples on www.kineticjs.com. With HTML5 and kinetic, you'll also be able to make it work for multiple platforms at once.
Hope this helps :-)
I'm new to AS3 and have been putting my code on the timeline and everything seems to be working fine (apart from the usual issues learning a language).
What I'm wondering is why so many threads say don't put code on the timeline? Can someone recommend some resources for me to get a good birdseye view of best practice programming in AS3 and why?
writing code in timeline can be quicker to start. writing proper code might take longer to setup but later when you want to make any changes or additions it is much easier and sensible. timeline code is hard to track down when the project gets complex.
A long time ago (Netscape 4-era), I wrote Javascript-based games: Pong, Minesweeper, and John Conway's Life among them. I'm getting back into it, and want to get my hands even dirtier.
I have a few games in mind:
Axis & Allies clone, with rugged maps and complex rules.
Tetris clone, possibly with real-time player-vs-player or player-vs-computer mode
Breakout clone, with a couple weapons and particle velocities
In all of these, I have only a few objectives:
Use JavaScript and HTML 5 - it should run on Chrome, Safari, or maybe an iPad.
Start small and simple, then build-up features.
Learn something new about game design and implementation.
So my questions are:
How would you implement these games?
Do you have any technology recommendations?
If you've written these games, what was the hardest part?
N.B.
I also want to start from first-principles - if you recommend a framework/library, I would appreciate some theory or implementation details behind it. These games are different enough that I should learn something new from each one.
Depends how much you want to start from scratch. To answer your direct questions:
1) How would you implement these games?
A: JavaScript + Canvas. Canvas is the 2D drawing surface from HTML5. Performance is pretty good on desktop machines, not so great on iOS and Android devices (as of the date of this post). If mobile is your utmost concern, you need to use the DOM and CSS3 3D transforms which trigger the GPU on those devices.
2) Do you have any technology recommendations?
A: This is sort of answered by the first question. JavaScript is a must, but I would ignore jQuery. You are targeting HTML5 devices, so no need to compensate for legacy browsers. As you are probably using Canvas, no need to smooth over the DOM interaction, either. There are some higher level libraries which make interacting with Canvas easier, such as Easel.js. WebSockets are useful for bi-directional streaming communication. And Box2D is useful for a physics engine. Local Storage is simple key/value string data for things like level progress, but for anything complex, you'll want WebSQL DB. For large binary assets you'll want to look at the File System API. Finally, don't be afraid of WebGL, as it is extremely fast and useful for 2D games.
3) What is the hardest part?
A: Almost certainly the hardest part is the debugging. WebKit's Developer Tools can make this easier, so don't leave home without them.
Put simply use Canvas for moving lots of stuff around the screen and SVG for prettier, slower, vector graphics.
One of the first things you should do is write a speed test program to see what can be done with Canvas and then play with it.
I wrote a blog post about Canvas & writing HTML5 games
edit 2019-02: processing.js is old and not well supported. Instead, try p5.js, which is equivalent and up to date.
Don't forget processing.js, which is a pretty well tested full-stack graphics and interactivity javascript framework, which has substantial (if not comprehensive) support for most I/O, sounds, graphics, and even WebGL. If you write vanilla Processing code, which is basically Java syntax compiled to JavaScript, you can use many open-source debuggers out there, including the native Processing environment. Other than that, you can integrate any other JavaScript code you have a mind to include.
Here is a guide for the JavaScript developer, explaining much of what you might want to know.
Check it out. Good stuff.
The hardest part, for me, was that there were no tools to help make the graphics, as there is no Maya export to canvas, for example, so, everything is done manually, with primitives, unless you want to take bitmaps that you will modify as though they are sprites.
At the time there was no real support for text in canvas, so my solution didn't work using excanvas, but worked fine on Safari and Firefox.
So, you may want to look at what HTML5 features you want to support, such as a built-in database, and then decide which browsers you are willing to work on.
How to implement these will largely depend on how you want to create the graphics, and if you want to do 3D graphics, as then the bitmapped sprites would not work.
Tom here from Scirra (Construct 2 game maker). We make an HTML5 games engine called Construct 2, it exports purely to HTML5 no Flash in sight!
Construct 2 uses an event based system to add logic to your games and does tons of the repetitive/difficult legwork for you. For example adding polygon collision to objects without some visual editor is a difficult task to undertake sometimes.
Anyway we think it's worth a look and you can get results very quickly from it as well. It's an alternative to coding the entire game you might want to take into consideration when developing HTML5 games.
Take a look at ChromeExperiments The examples are from around the world using the latest open standards, including HTML5, Canvas, SVG, and javascript.
Maybe this is not what you wanted to hear, but have you thought of starting with a good book?
http://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=html5%20game
A good book will save you a lot of time, and start you off right at the basics.
A good question when I also started to learn HTML5 I also came across this question, finally after lot of research I found best way to do is by using some engine or framework. I learned canvas and made my own game but that took hours of logic and 100+ lines of code.
Better go with scirra, it might reduce your work.
I'm currently working on a series of blog posts explaining how to build a Javascript game using EaselJS and Box2D for physics. Here's Part 1.
I have a horrible habit, actually something I'm wrestling with right this moment, when I think of a better way to do something - either a refactor, or something that would just be SO MUCH COOLER LOOKING, or such a better UX, I just HAVE to do it. Even when it would cost me time and I'm in a time crunch. I never know when to say, "no, there isn't time for this I can do it later."
Is there a line you draw?
Like right now I need a way to display magazine articles that are in the database. The easy way would be to create a new .aspx page and just pass the article id. the AWESOME way would be a jquery fade in modal that would display the article. At least that's what I think. Not being a guru it would take me longer to write. We are launching next week no time for extra crap. However, I just can't bring myself to do it the easy way.
Does anyone else run into this problem? Wondering if more experienced programmers have some wisdom to share.
I'd go the quick route first.
Write an ASPX page that is showing an article based on ID, or even cooler and more SEO-friendly, a slug. You'll be able to meet your deadline. Then, I'd start on the awesome jQuery way.
The bonus to this is that you'll have a fallback option, in case that a user has JavaScript disabled.
You're talking about "gold plating". It's a very common and well-known issue for software developers.
From the glorious founder of StackOverflow himself:
30: Developer gold-plating. Developers are fascinated by new
technology and are sometimes anxious
to try out new features of their
language or environment or to create
their own implementation of a slick
feature they saw in another
product--whether or not it's required
in their product. The effort required
to design, implement, test, document,
and support features that are not
required lengthens the schedule.
The proper way to cure this problem is to volunteer for so much work that you don't have time to do it right, let alone add on extra bells and whistles. :)
Edit: Other "classic mistakes" link here.
I think it's just a matter of setting priorities. Also, if your client, or boss doesn't want you to do things the flashy way, and you don't really have time to do it the flashy way, just do it the simple way, and come back and upgrade to flashy if you have time later. Clients and bosses are usually happier when you finish the work they gave you before moving on to making things better.
I look at how much time I have left, and if I feel I am pressed, I don't venture outside of my area of expertise. I am all for doing it correctly and elegantly, but the reality is that the majority of the time the deadline takes precedence, and I know if I stay within my comfortzone when pressed, I will most likely make fewer errors which means I save the QA people time in testing things.
That all being said, I have been known on more than one occasion to push the limits of how much can be done. If you aren't working an immense amount of overtime already, you can always make extra the time necessary for going the harder route. Yeah doing this can cause a little more work for extra people but sometimes that's the difference between having the best application or having the first loser.
My other advice is don't try and do both options. If you create a basic version stick with it and move on. If you try and do both, you're really wasting time in the end.
The right way is to have it functioning so that users can get to the information they seek. The designer way is to have it kind of working but also have javascript light things up and move around.
The best way is to get it working correctly then revise it. There shouldn't be much refactoring involved if you know where to place things. Obviously retrieving the article is going to be business/app logic and the actual fancy design (like fades/animation) will be part of the design/view aspect of the setup. These portions should be able to sit and be somewhat ignorant of what the other is doing - they shouldn't be tightly coupled.
Sounds like typical feature creep. Convince yourself that tabling a feature idea now to meet a deadline is quite different from simply dropping the feature altogether. You can come back to it months after release and put in new features.
I think you've pretty much answered your own question there. You said that adding this feature would take too much time, and you're in a time crunch and are launching next week. I think it's fairly obvious you need to go the "easy" route.
You're basically describing feature creep. http://en.wikipedia.org/wiki/Featuritis
You need to discipline yourself, what I would do in your position is document the new feature I want to add, and implement it after your out of crunch mode when you have time to work on it. You're obviously aware that adding this feature is going to cost you time and may very well set back the launch of this product, you just need to have the discipline to prioritize and stick with it.
I think every developer has this problem if he is interested in programming and isn't coding just as a way to make money in a 9 to 5 office job.
Here is my advice:
Make a list of every cool thing you think of as you're writing the code. After you have a working basic version, commit it to your source repository.
Now if you have time left go back and do as many cool things as you have time for. Use branch tags if you're going to have to seriously rework the code.
Once you run out of time, if you're doing Agile, write the leftovers up as stories and give them to your project manager or client.
I think when you say you are doing something the "right way" that implies a balance of quality with the speed you can write it in.
If you make something as high quality as possible, but never release it, it's not the "right way". On the other hand, if you write crap but get it out super fast, that's also not the "right way." To do something the "right way", you must balance these two.
An economic phrase that comes to mind is "Quality, Price, or Production Speed, pick two."
Things like this used to absolutely kill me!
Here's my advice:
Do it the easy way (the aspx with the
id parameter)
Write a small proof of
concept to show the client
Show the client the working page and the proof of concept later along with an estimate on how long it will take. The experience of designing the prototype will give you a better idea of what is involved, how to do it, and how long it will really take. The proof of concept can also inform maintainence developers what's what (fading vs logic), and allow them to issolate if the fading mechanism or logic is broken.
Personally, I would stay away from the fading thing. In my experience the client will see no added value in the fading functionality and IMHO seperating it to another page will be easier to maintain. I believe it will be less prone to bugs later since code for the 2 pages will not be intermixed onto one page (if I understood you correctly).
In test driven development approach, when you implement a feature by writing a test for it and implementing it the easiest possible way, you will be able to go back and do it "right" only when you find really need to do so. Knowing this allows you to avoid overdesign. And often, you find you won't need to after all.