I am entirely new to learning programming, and my father recommended this site to me. I wanted to learn Actionscript 3.0 to possibly make my own flash game. There is alot of things I need help on because I am completely clueless. What kind of things should I download, do I have to pay for any of this?(I don't have money to spend, sadly.) Where can I find some good tutorials? Do I need any kind of client to play around with actionscript 3.0 and learn the language? Sorry if some of these questions don't really make sense, like I said, entirely new to the programming world, but I really want to make my own MMORPG,(completely unrealistic dream), and I want to start small, try making money off flash games, get some programming experience, any help anyone can provide would be great. All I ask is please do not tell me how unrealistic my dream of making an MMORPG is, just mentioned it to give a little insight as to why I wanted to learn programming. I know it's crazy, but that's why it's a dream, a goal I'm hoping to achieve one day.
I highly recommend downloading Flash Develop (requires windows) for development, its a free, and also IMO the best, AS3 editor. It'll get you up and running. If you are on a mac you might want to start with free trials of the Adobe code editors.
For resources & tutorials, the web is full of free stuff to get you started. A couple are 8bitrocket & gamedev.stackexchange The first thing to do is just pick a simple game (perhaps a true/false trivia game) And just build it. For getting started with general AS3 programming look here for a variety of docs & tutorials.
Good luck, and have fun!
Flex is a free product made by Adobe itself, and uses ActionScript 3.
Here's a link to a game dev site with tutorials on how to make a game for free using flex:
http://www.dreamincode.net/forums/topic/92205-making-flash-games-for-the-non-flash-developer-part-i/
http://www.dreamincode.net/forums/topic/92293-making-flash-games-for-the-non-flash-developer-part-ii/
http://www.dreamincode.net/forums/topic/92746-making-flash-games-for-the-non-flash-developer-part-iii/
http://www.dreamincode.net/forums/topic/92893-making-flash-games-for-the-non-flash-developer-part-iv/
If you read through the link article carefully, you can use eclipse (free) with a flex plugin, instead of having to use the flex builder.
I plan to start web app development. (Html, Css and Php) I want to make a mafia wars style game for the web. Static graphics game is played using buttons.
Its would really just be a database to store stats and a bunch of buttons.
Would this be too hard for a complete beginner to web development to take on? Would javascript even be necessary for this?
Yes. It would be too hard for a COMPLETE beginner to take on. Where complete beginner = just learning to program. If you have some other background (General CS knowledge, Database experience) then you could probably do it.
JavaScript doesn't sound necessary for what you are describing.
I would suggest going through a couple tutorials on web application development so that you understand the basic concepts, and then decide whether you know enough to start building your game app. Here are a couple tutorials for various development environments:
http://webproject.scottgu.com/CSharp/HelloWorld/HelloWorld.aspx
http://www.eclipse.org/webtools/community/tutorials/BuildJ2EEWebApp/BuildJ2EEWebApp.html
http://download-llnw.oracle.com/javaee/1.4/tutorial/doc/WebApp.html
You should probably at least read through some of those to get an idea of what you should know.
Would this be too hard for a complete
beginner to take on?
I don't think so. The game hasn't been developed by a single developer, there is a team of developers behind it. That shouldn't be an issue anyway, however, it won't be that easy for a beginner to take on such website initially unless you have good understanding of various concepts including strong knowledge of the main language, javascript, html, etc.
Would java script even be necessary
for this?
Possibly. Facebook has its own implementation of javascript named FBJS (Facebook JavaScript), it is more or less similar to vanilla javascript. At some stage or the other, javascript is needed to build some dynamic pages and there are certain facebook-related stuff you will need to use javascript (FBJS) for.
JavaScript. Yes. However, it can be done without but it may hurt the game in the long run.
A project for a beginning? It depends how focus the programmer is. If you are using this project to learn, certainly a good place to start. However, if it is for long run serious project, I would reconsider after learning some of the basic of programming.
If you love the idea you have and want to run with it, you will learn a ton in the process. Just don't expect to have a working product in a week. Don't let feature-creep hit too hard either. Odds are you'll end up re-writing it once you have an idea of how the process goes over all. I did something similar a few years back over the course of a month and I was pretty pleased with everything I learned.
You can do it, with patience.
I'm about to start building new start-up so i need some guidelines from you.
What's the best way to plan a website? I don't think like "first design, then the database relations, then start development", but "how to plan the way application is going to work"?
Are there some proven methods, like THE best way to do website 'blueprints', like with some tool or something?
I need as much feedback as you people can give me, this is really important to me.
Links, experiences, everything is welcome =)
I'd like some tool to be able to draw the process like
page
- if logged in - do that
- if not logged in - do that 2
Write it down. On a piece of paper. Draw lines between the related parts.
Rinse and repeat as necessarily.
I'm serious. Tools, fancy diagrams, flowcharts, all look pretty for management, but they get in the way of actually understanding how your app is going to work. If it's so complex you can't get it all on a couple sheets of paper, do a big picture view and then do each sub-section.
If you can get a HUGE whiteboard or piece of butcher paper, it's even better. For some reason, having a large space to work on is fantastic for working things out.
I used to do huge specifications in word...hundred pages or more. I no longer believe in that since as soon as you write it down it is likely to change (your ideas, features, etc.). Instead I suggest that you look at an MS product called SketchFlow (which comes with Blend). This allows you to quickly and without writing any code snap together a working wireframe, sitemap, and mock up. While you can create a high fidelity (it functions and looks very close to the real thing) I suggest that you instead focus on creating a low fidelity mock up. There are sketch styles which looks like hand drawn UI elements. This way you can focus purely on how your product works and no so much about how it looks. If there is too much 'finish' put on your mock up you will get hung up on the "big blue button" syndrome where people are more concerned with how a button looks and less concerned with what it does.
I wrote four articles on wireframes, mock ups, and the like and suggest various tools and why I chose SketchFlow. Then I go into building a mock up in SketchFlow.
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Sitemap-and-wireframes-with-Expression-Blend-3-and-SketchFlow-part-1.aspx
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Sitemap-and-wireframes-with-Expression-Blend-3-and-SketchFlow-part-2.aspx
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Sitemap-and-wireframes-with-Expression-Blend-3-and-SketchFlow-part-3.aspx
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Sitemap-and-wireframes-with-Expression-Blend-3-and-SketchFlow-part-4.aspx
Hope this helps you!
This is a pretty big question. My best advice is to start by thinking hard about your user, what their goals are etc and then draw up some personas. Personas are descriptions of the typical people who will use your site. Once you have your personas you can start to plan your site.
http://en.wikipedia.org/wiki/Personas
Once you have your personas you can work out user journeys - these are essentially flow diagrams detailing how users will achieve the tasks you want to help them with.
http://www.boxesandarrows.com/view/an_introduction_to_user_journeys
From user journeys you can work out the pages you'll need to create in the form of a site map.
http://en.wikipedia.org/wiki/Site_map
Then finally you can work out the content of the pages as wireframes.
http://en.wikipedia.org/wiki/Website_wireframe
There are loads of tools out there: Visio (http://office.microsoft.com/en-us/visio/FX100487861033.aspx) for the PC and Omnigraffle (http://www.omnigroup.com/applications/OmniGraffle/) for the Mac. Both these tools have web design stencils available for free download on the web. There's also a great online tool call Balsamiq (http://www.balsamiq.com/products/mockups) that allows you to lay out pages without having to use a design tool. In the first instance though a pen and paper are the only tools you need.
Once you have these details sorted you can start to think about data models, graphic design etc etc. However this whole process is iterative and you might say will never be finished :)
Good luck!
Develop your data model first. Even if you don't go whole-hog with UML, get a sense of how your data will be represented.
Come up with some use cases to validate your data model. It doesn't have to be perfect, but it should be 99% there to avoid pain in the future.
Once you have a data model and use cases, your interface needs (in your case, your website) will become a great deal clearer. Of course, I'm coming at this from a purely back-end perspective.
Once you have an interface that's workable, hire a good UX specialist to round out the details for you (both workflow and actual interface).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Soon I will need to give a presentation on my honours project for the engineering faculty and a large group of engineering and technology students at my university. While all the the people attending will be technical-minded, not all of them will be programmers and most will be from other engineering disciplines.
I have given presentations before, and I am confident speaking to a crowd, but I realize now all the presentations I have given before have been to fellow CS/SE majors and teaching staff. I wonder if my presentation style assumes that I am presenting to other software geeks, so they will know what I am talking about and I can put on a more interactive demo involving the audience.
My honours project isn't terribly complex or theoretical, I have a prototype C# Winforms app but it is designed to be extensible and operate with different data sources (ODBC or WS) in the future, and some research to how it could be extended with a rule engine and DSL and turned into a marketable product. The organization that is testing my prototype is saving tens of thousands of dollars a year by automating a critical business function.
I had planned to show off how extensible it was by some live coding and UML-style diagrams. I really enjoy doing demos and live coding but I don't know if that kind of presentation will be as accessible to non-programmers, and I am worried if I get too geeky and technical I may alienate the audience and judges.
What are the effective techniques you have found to present software projects in a way that is also interesting to non-programmers
When I was working on my doctorate, the faculty gave us this rule for seminars - and it has proved very useful since:
Tell 'em what you're gonna tell 'em. (E.g., brief introductory problem
description and results abstract)
Tell 'em. (E.g. technical details comprising the bulk of the time)
Tell 'em what you told 'em. (E.g. brief summary and conclusions)
Open the floor for questions.
In your position, I would take about 10-20% of your allotted time to do #1 in a largely non-technical way. So you might describe the business function your code automates, why that's important, what things were like before and after applying your solution, how it's saving money, that kind of thing.
Then I'd launch into a highly technical discussion aimed at the CS/SE crowd. Even if the rest of the folks don't understand it and their eyes glaze over, your introduction at least will have given them a sense of what it's all about, and they might recognize a bit here or there.
For the third part, I'd briefly recap the problem and describe how you solved it in non-technical language, and then do your live-coding extensibility whiz-bang demo. Even if the non-CS/SE folks don't understand the demo, they'll see eye candy flying by and your professional peers and faculty all nodding and smiling, so they'll think it's cool.
I once attended a seminar by a guy who won the Nobel Prize for applying chaos theory to chemical systems. He applied this approach, so even though all the non-theoreticians like my fellow organic chemists and I were all completely out of our depth, the fact that the theoreticians were all excited left us feeling like it was a great seminar even though we didn't have a clue about what he'd said.
To appeal to both audiences, I sometimes give the technical explanation and then follow it up with my "in English, please" explanation. CSI and other dramas with science in them do this all the time, to good effect.
In other words, [insert plain english explanation here].
Lets attack this as a refactoring problem.
ie Instead of adding more to your presentation, Is there a way in which you can take stuff out?
For example I don't think showing off that your demo App can use multiple data sources is essential, much less grants for you to program right there during the presentation.
I know it took care in the design of your app to reach that point, but still most people are more interested in the OUTPUTS not the INPUTS of an app. And even more in the BENEFITS of said app.
Some guiding points:
Make the presentation about them. If the audience has felt the pain that your program solves, remind them of that pain. If they are other researches like yourself then ask them to put themselves in the shoes of the organization you helped.
Compare the old way vs the new way of doing things. Why is the new way more efficient? Will it lead to more sales? will it reduce inventory? or save money? Will someone lose his/her job because your solution makes his task irrelevant. Note: When making technological presentations I've observed is important to address what happens to the people that was doing the task previously. Fortunately most of the time people don't lose their jobs, in most cases the same people can manage a much larger volume of work thanks to
Technology.
Show results. What are the real results your demo company has observed?
Use meaningful visuals. If you could make some animations that explain your algorithm even better.
Tell your point at the beginning and the end. Most people will forget what happened in the middle so make sure to tell the most important thing at the beginning and the of your talk.
Practice, Practice. Yeah it sounds ridiculous but do your whole presentation in front of a mirror or video recorded at least twice. The more the better.
Don't give one of the most important presentations of your life without a rehearsal.
Breath and be positive you will do fine :-D
PS: My suggestions are derived from this webpage. It has guided me several times:
6 Stimuli to reach the old brain
You're already working on knowing your audience, which I think is awesome, you just need to take it a step further, and ask yourself, if I were x person in the audience, what would I get out of this presentation.
I'd question the validity and how much effort should go into the technical/coding demo, if the group you're presenting to is never likely to use your specific implementation. It may be more important to portray how you approached the extensibility, so that you garner ideas within the peers on how they can approach it in the future, as well as hit on points throughout that are important to all of your audience members, and maybe shortcut the demo a bit to just show that, yes, indeed it does work.
I don't know about you, but personally I've always got more value out of these types of presentations based around how the project appeals to everyone, how you are managing to save tens of thousands of dollars per year for this company, theoretically why other companies might want to use it as well, what is the market and other factors, what were the giant technological hurtles you had to overcome, even if it's a simple project, there were things you must have thought about ahead of time to avoid and prevent you from getting backed into a corner.
I think if you're a really good presenter, and the purpose of the presentation is to be broad and appealing to the entire group, and not a talk on the chaos theory and application to chemical systems, which has that stated purpose, you should appeal to the lowest common denominator of the audience, and the entire audience can be entertained and appreciate what you have achieved at every step along the way, and to do this, they don't necessarily have to understand every step taken either.
I've been in the same situation
(presenting a software engineering/image processing/recognition project in an EE faculty competition).
Start with the issue (the problem)
Then the background (a BIT of technical background)
The solution:
Start with block-charts (all engineers read those)
Then explain the technologies and how briefly - how complicated the implementation was
(don't underestimate the complicated part - otherwise you may make your work seem to simple to engineers from other fields - they won't appreciate your effort)
Results:
Show short visual examples (try to make them intriguing)
(short code examples can go here)
Short user interface demo
Show impressive graphs
Bibliography, thanks, possible future improvements/research
Questions (if the forum is large, tell them in advance that the time for questions will be at the end)
General advice:
Practice presenting (over and over)
Leave 45-60 seconds per slide
No more than 5 points per slide
1 line per point
Add jokes
No animations except for demonstrating complicated issues faster
Use clear fonts (Ariel or Calibri for regular text, 1 different font for titles)
Use high contrast colors
(bright on black or dark on white if you must - no dark on dark or bright or bright)
Well first of all, I would suggest talking to your faculty advisers about what they expect from your presentation. If there's any question about how you should balance technical details understandable to only CS people versus more general concepts understandable to the larger audience, I think it would really help to get input from those who will be evaluating you.
One thing I really like to see from a presentation is a "take home message". What is the one thing you want everyone in that audience to remember long after they've left the room? Tell them the take-home message at the very beginning. Tell them you will spend the rest of the presentation explaining why they should care and why they should believe you. Even if people get lost in some of the technicalities, if you at least drive home that one message, you've delivered one thing to a lot of people.
Another suggestion: don't forget about format. Presentation slides should be readable from anywhere in the auditorium/lecture hall. Don't overwhelm people with too much text on one slide. Keep bullets short and easy to scan. Do you want people spend their time reading your slides or do you want them to listen to what you have to say? Don't use acronyms, but if you must, explain what they mean--and put the definitions on your slides--unless you are sure they are common knowledge. If people are sitting there wondering what the heck that acronym means, they aren't listening.
As to whether you should show actual code or do live coding, my gut feeling is that you shouldn't unless it's absolutely critical to the point you're making. If your project were actually about some coding construct (e.g., if you had invented the concept of an "extension method"), okay, it would make sense to get into some actual code. But it sounds like the significance of what you've done is definitely up a level from that. You might want to show how little code it takes to, say, hook up a different data source, but I wouldn't actually get into walking through the code itself unless you feel you can't make your point otherwise. One thing I probably would like to see if I were in the audience is a demo of your code in action. Show me what is does, and tell me why that's cool.
I hope it goes well!
Here is my advice:
Be clear who your audience is and what your message is - Are you trying to impress six faculty members who are marking your project, or proving you can entertain the whole audience.
Have a Contents page early on - that way the audience know what to expect.
Put the geek stuff in an appendix to your main presentation. That way you can dip into it ,for questions, but you will not loose the main point of your talk.
Make sure your presentation flows and tells a story - limit slide numbers and don't clutter them e.g. project goals,possible uses, design challenges, software choice, what you did (limit techie), results (demo), results and limitations, next steps, questions.
Have a Conclusions page at the end -- make sure you circle back and cross refer to your original contents page.
Leave 15-20% of your time for questions. This will reveal what the audience is interested in, and allow you to display a deeper understanding of the topic i.e. only do live coding if they ask for it.
Rehearse out loud even if you feel stupid doing it.
Good luck.
A few tips
Use a common technical language. only use terms that the hearing will recognize.
It links what you expose yourself, with examples recognizable by the audience.
you can also read these great articles.
11 Top Tips for a Successful Technical Presentation
Tips for a Successful Technical Presentation
Bye.
Mix and match some topic everybody know. It has helped me to theme slides with images ranging from the Divine Comedy to the Simpsons I don't know how formal is your presentation but it's a common constructivist technique to hook on something your audiente already know to show your point.
I once attended a presentation of Larry Wall where he explained Perl 6 features using examples from golf mixed with the Lord of the Ring.
What I do is to talk analogies, try to convert to real world the terms you are explaining.
BTW, Why are you talking about software tech aspects to non tech people?? You have to target the content to your audience first. Who is your main audience?? The techies or non techies, choose one.
Regards,
I'd be inclined to not use code (unless you actually have to), and use some form of generic (and straightforward) pseudocode.
Also, if you are doing the talk with prompt cards, put 'Breathe!' at the top of the cards. It helped me...
Focus on the user interface (aka how it makes their lives easier) and how it is different from similar products (why they should listen.)
I think Simon Peyton Jones gives excellent talks. See the How to give a good research talk section on this page. In particular, check out the video of his talk about the subject linked to in that section. You can find other videos out there of his talks on Haskell, functional programming, etc. to see how he practices what he preaches.
Please listen to the following podcast : Manager Tools - Presentation basic
It will cover all the basics you need to do effective presentations.
Now when doing project presentations do the following:
Create a High Level Architecture model ... see this model you can probably do better (note: the model image is from my blog.).
Create a High level requirement list
Create a application workflow process diagram (once again pretty colors, arrows and blocks). This model will show how a user is expected to work with the application in order to solve its main task.
In order the present the application first show them the requirement list and talk about them, then the high level architecture and finally the application workflow process diagram which can be followed by a live demo.
The most important rule is to present at a fairly high level with lots of diagrams and models to show what you are talking about.