I need a 3D engine for a very specific task in Artificial Intelligence, and I'd like some input.
The first part is the trivial one - basically, all I need is a FPS engine (3rd person would be good, too), such that it allows me to navigate a room and interact with objects (if you have Java and Windows, I'm looking for something similar to the Give Challenge, but a little more up-to-date). Physics would be nice, but is not a must.
Now, the non-trivial part would be: I need to impose a virtual grid over this room, such that at any moment I can say "the player is located at B5 - now he moved to B6", and so on. I need to redirect this information to another system (namely, one which will give the player instructions about what to do) and, at the same time, send messages to the player, so I must be able to have a single point through which the game logic passes through; also, I'd love not having to write my own collision detection and such.
So far, I've tried:
the Source SDK: it seems a little overkill (since I'm not really planning to shoot anyone, at least half the code base is useless to the task), and since I'm not really a Windows developer, I'm spending too much time with the "easy" stuff (such as getting VS up and running). Plus, cross-platform would be really nice.
Blender game engine: while this worked decently, the interaction model seems a little weird, and some easy stuff (such as making sure the camera stays inside the scene or showing the mouse on screen) gets too weird too soon.
Crystalspace 3D: I've tried their demos, but it looks a little old-fashioned, and since that was one of the problems of previous engines (it's easier to get volunteers when your game looks nice) I'd like to try something else.
Now, maybe I'm asking a little too much for a single software, but I'd love some input. Can anyone suggest me an alternative? Or should I give one of the previous ones a second chance?
Try the UDK. All of the things you request are present, and it's free for personal/noncommercial projects. Here are some highlights:
Modern looking. The UDK features an intuitive-ish visual material design system, post-processing effects, Scaleform Gfx UIs from Autodesk, and more.
A visual scripting interface called Kismet that can control gameplay elements, the camera, and more.
UnrealScript, a scripting language similar in syntax to C, C++, Java, that gives you the ability to extend existing functionality or create your own.
Comprehensive documentation available on UDN.
Lots of community support outside of Epic, in places such as Polycount, Eat3d, 3dbuzz, and more.
Basically, "and more".
If what you're looking for is a professional, free (as in beer) engine that will allow you to focus primarily or solely on your differentiating gameplay features, Epic has set the bar high.
Related
I know this sounds a little bizarre, but there is a very simple application I want to write, a sort of unique image viewer, which requires some interactivity with the host system at the user level. Simplicity when developing is a must as this is a very small side project. The project does require some amount of graphical work and quite a bit of mouse based interactivity (as well as some keyboard shortcuts), but quite frankly, I don't want to dig my hands into OGL for something this small. I looked at the available options, and I think I've narrowed it down to two main choices: Webkit (through either QtWebkit or WebkitGtk), and the language Processing.
Since I haven't actually used Processing but I do have some amount of HTML5 canvas and Javascript experience, I am somewhat tempted to using a Webkit based solution. There are however, several concerns I have.
How is Webkit's support for canvas, specifically for more graphically intensive processes?
I've heard that bridging is handled better in QtWebkit than WebkitGtk. Is this still true?
To what degree can bridging actually do? Can a Webkit based application do everything that an application which interacts with the files on the system needs?
Looking at Processing, there are similarly, a couple things I'm wondering.
Processing is known for its graphical capabilities, but how capable is it for writing a general everyday desktop application?
There are many sources that link Processing to Java, both in lineage as well as in distributing applications over the web (ie: JApplets). Is the "Application Export" similarly closely integrated with Java?
As for directly comparing the two, the main concern I do have is the overhead of each. I want the application to start up as snappy as possible, and I know that Java has a bit of an overhead regarding start up because it first has to start up the interpreter. How do Processing and QtWebkit/WebkitGtk compare for start up?
Note that I am targeting the Linux platform only.
Thanks!
It's difficult to give a specific answer, because you're actually asking a few different kind of questions - and some of them you could be more precise.
Processing is a subset or child of java - it's really "just" a java framework with an free ide that hides the messy setup work of building an applet, so that a user can dive in and write something quickly without getting bogged down in widgets and ui, etc. So processing can exist by itself and the end user needs to know nothing of Java (except syntax - processing is java, so the user must learn java syntax).
But a programmer who already knows java can exploit the fun quick nature of processing and then leverage their normal java experience for whatever else is needed - everything of java is in processing, just a maybe slightly hidden (but only at first) It's also possible to import the processing.jars into an existing java program and use them there. See http://processing.org/learning/eclipse/ form more information.
"how capable is it for writing a general everyday desktop application?" - Not particularly on it's own (it's not made to be), but some things are possible and easy (i.e. file saving & loading, non-standard gui, etc.), and in some ways it's similar to old school actionscript or lingo. There is a library called controlP5 that makes gui stuff a bit easier.
Webkit is another kettle of fish, especially if you aren't making a web-based thing (it sounds like you're thinking on using the webkit libraries as part of a larger program. I'll admit I don't have the dev expertise with those specific libraries to give you the answer you really want, but I'm pretty certain that unless you have programming experience beyond html5/javascript you'll probably get going much faster with processing.
Good luck with whichever path you choose!
I was just asked to talk about Objective C to a bunch of High School student for 20 minutes. They have no experience with programming at all. What topics should I cover? Should I define vocab such as Method, Class, Variable? Or should I do something else?
Any comments are helpful!
Since you obviously cannot possibly teach them anything practical in 20 minutes, instead why not try to give them teasers into what you can do (instead of how to do it) to encourage them to learn more.
One such idea I have seen is that you could demonstrate an application that searches for all local bluetooth devices and displays them on the screen in a creative way. (ie when they turn on their phone bluetooth their phone id will appear and start floating around the screen)
Only catch is if you have any really clever students you may end up with mobile phone names changed to swear words...
20 minutes gives you almost no time to chat about programming concepts. I would simply display a "hello world" type application and give a very high-level overview of the different tools and languages needed to develop this program.
I'd recommend doing something to show how the tools work and introduce objects as the building-blocks of the app. I did a demo in about one minute, drag a webview, textfield and a few buttons in IB and make a full web browser without writing any code :-). Explain that each of those things is an object and what that means in the context of the app for the remaining 17 (then take questions). I used that demo to launch a talk on MVC but that might be too much depth for your audience. For reference my talk is on slideshare: http://www.slideshare.net/iamleeg/adopting-mvc-in-cocoa
How about telling them about Smalltalk history, the creative outburst at PARC, and the philosophy underlying this branch of OO language? Then quickly explain that ObjC is an attempt to pair this philosophy with an efficient, universally known language (C). Present NeXTstep and OSX as a further outgrowth of this, and land on the unusual features of the iPhone API (from a developer's perspective).
This will give them some history, a glimpse of the creative and technical issues faced by programmers, and a sense of the role computer languages play in the broader development of consumer computing. You can even show them some syntax comparing Smalltalk/ObjC/C/C++/Java, for example. Without going into detail, that might give them some sense of what a programmer's reality is like.
I would say no history. It's very vague as it is, let alone that AND programming together.
Do something like:
http://teachingkids.railsbridge.org/2009/08/15/teaching-ruby-to-high-school-girls.html
When doing hallway usability tests do most of you make your apps fully or near fully functional? Or do you just make sure the links or flow chain correctly? Or do you just draw on paper and go with that?
I'm would like to test early on a prototype and am trying to find a good balance. But at the same time am worried that some non functional parts might actually not give representative results.
Thanks.
Usability tests, hallway or otherwise, only need the functionality that you need to test. In most usability tests, you should go in with specific design questions to answer and develop your prototype to the point where it can answer those questions. For example, if you need to test if users understand your indication of the sort order for a table, all you need is a paper picture of the table showing the sort indication (with the table contents blurred) and ask them how the table is sorted. If you need to test the IA, all you need is a bunch of web pages, empty except for a title, that are linked through the navigation menus.
You only need the pages relevant for the tasks you give your users. If you’re just testing the IA, then you only need the pages on the normative path. If you are also testing error recovery, then you need the pages off the normative path along with the full navigation controls. If you are also testing error detection, then you need content on the pages as well.
You can also simulate functionality when that’s easier to do. For example, in testing if users can figure out how to get a desired sort order, when the user clicks on a non-functioning control for sorting the table, you can say, “Okay, doing that will get you this,” and you take the mouse and select a bookmark that shows the table in the new sort order.
In hallway testing, if users breach the fidelity envelope, you can simply say, “I haven’t made that part yet. Let’s go back to A, and continue from there.” Of course, you should note that the user made a wrong turn in the task you intended for them. I haven’t had any problems with users complaining about non-functional features when I tell them up front it’s an incomplete prototype and we’re only testing the UI for features x, y, and z at the moment.
For low fidelity prototypes, I often call them “mockups” or “drawings” to users rather than “prototypes” to indicate the low functionality. You can put obvious placeholders in for missing content (e.g., “Blah, blah, blah…”, “TODO: Picture of product about here.”). If a user comments on something outside the fidelity envelope (e.g., “This symbol should be red to stand out more”), simply note it, and say that topic is under development (e.g., “Thanks. We haven’t started work on the colors yet. We’re just trying to figure out how to organize the site right now.”).
Usability testing with limited-fidelity prototypes is really necessary for iterative design to be feasible for most projects. Otherwise, you waste too much work developing things that have to be redone.
A couple things to remember:
Test early and often.
The goal of usability testing is to find problems with the UI, not Q/A your code.
Therefore, if users can see the parts of your UI you are interested in testing and interact with them in a realistic way (e.g., click on buttons and links), you should be able to collect useful data. If some links are dead-ends, that's okay, as long as there's some way for users to recover and continue on. Basically, with prototypes, the "correct" path should work, but it's okay if incorrect paths don't (as long as there's a reasonably quick way to get back on the correct path). Even static storyboards (non-functioning drawings of a UI) can provide you with some information if you ask the right questions, e.g., "What would you do on this screen if you wanted to view your shopping cart?").
I would suggest a couple rounds of usability testing. First on paper, perhaps later on screen, generally throughout the application lifecycle (take an Agile approach to it).
There is a good argument to be made for paper prototypes. When users see a screen, even limited functionality, they may be hesitant to suggest changes since it looks "done."
Make no mistake, it's not trivial to get it all down on paper, but that's where I would start. Probably start with just a section or two of the application. And make sure somebody with good people skills and/or explaining skills is there to walk the user through it. Have a second person on-hand to take notes. Try to ask open-ended questions, etc.
For a hallway test, I would test with NONE of the functionality implemented.
Test against designs done on a whiteboard or on paper. You'll be surprised at how much you find out in these minimal mockups. And they are very inexpensive to make!
Functional prototypes are for later. If you give your usability subject a functional interface, they are much less likely to question whether you've implemented the right set of features in the first place.
I would make the UI functional, so that the user can really play with it, it will be much better than a static image. People can tell you whether they feel comfortable on the UI.
I would make sure everything in the UI works, or at least takes you to a clear, unambiguous message pointing out that the feature isn't implemented yet.
Showing prototypes to clients with a disclaimer up front about how feature X doesn't work yet will usually be ignored. They'll try out the prototype, click on featuree X and indignantly reply "Feature X doesn't work! This really needs to work in the final version! Why doesn't it work?". The client is confused and unhappy about the product, and it's frustrating for yourself because it overshadows the positive feedback. Besides, you told them it didn't work, why can't they use their imagination to envision how it would work in the final version?
Make it work, be it with a rough version, dummy data, or even a simple message saying "would show results sorted alphabetically now".
This is not 100% programming related. But I think this is somewhat useful because it is addressing a minority in the SO community.
Microcontroller programming is one of the interesting areas in programming. I saw some topic here requesting the Resources for starting / learning / discussing about PICs.
Example topic
Since I have plenty of knowledge and experiences in this area I am thinking of publishing some resources that helps a novice to learn them from the basics. It will be not just a theoretical publication and will be based on example projects. I hope to start this over a new blog + forum so the users can dynamically interact with each other. I came in to this decision because I found very small amount of Sites that a novice can start learning and work collaboratively.
What do you guys think about this? Have you ever experienced such difficulty? Do you think you can get some use of that? What are the things you like to see on the site?
I would be thankful If you are not going to close this as NPR. I just want to do some service to other microcontroller lovers :)
There are already a few such tutorials on the net (e.g. this one from SparkFun), another one might be a valuable addition, but only if it is better or different in some way.
What will you offer that is a real improvement?
Some suggestions:
Don't assume I have windows
Have some side discussion of difference between various MCU and/or supporting electronics. Discuss some of the trade offs
You'll need a pretty general tutorial to suck people in, but the real value added might be in a specialized focus after the start
Build up to something useful and/or geeky cool
A unit on component integration (i.e. I can buy a Polar style heart rate receiver, and a MCU and a USB interface. How do I get them talking to each other so I can build an exercise data logger?)
What every you do, I'm looking forward to it (just learning embedded stuff in my spare time...).
There are the excellent tutorials at www.mikrocontroller.net, but they are in German.
If you could create something similar for an English speaking community, that would be great.
Yes! The more resources out there for helping with embedded software (microcontroller programming) the better.
It can be quite daunting to start with, especially if you've only written software for PCs or similar in the past. There are lot more constraints (e.g. on RAM and code space), and a whole load of things you need to know that don't apply to non-embedded software.
As others have mentioned here, there a number of websites that cover different aspects of this; some others are OnARM, for ARM processors, the related STM32 Circle, and Jack Ganssle's articles on his website and on Embedded.com.
Though embedded systems are an enormous market (just think how many such devices there are in your house, or in your car), my impression is that there is a lot less coverage of the subject on the web - and on Stack Overflow - than for non-embedded.
So, I look forward to seeing the fruits of your labour!
Something else that's worth to take into account when targeting beginners, is to directly provide pointers to useful resources, such as suitable simulators/emulators, or even addresses/webpages where you can easily order a starter kit or even free samples of some chips.
For example, most semiconductor manufacturers provide free samples of their products, e.g. see microchip.com or atmel.com.
Ideally, an introductory course would be based on working with such a hardware simulator or emulator in the beginning, so that the project and all relevant experience may directly map onto a real device once the beginner is interested in moving his work onto a real chip, providing pointers to freely available resources, or very affordable starter kits can be very useful.
This would ensure that beginners can get started as easily and cheaply as possible.
Maybe for the different ARM7 and CortexM3...?
Here everyone asumes there is a lot of information, but it is spread all over the net and without any red line what so ever...
But if you take AVR there is quite a lot of stuff over at http://www.avrfreaks.net, and I guess that PIC has quite a lot as well.
I have written many such examples myself but they are scattered and not organised and probably rarely read (one time the folks at avrfreaks borrowed something). StackOverflow might curb this but SO could in theory be used. Ask a question about boot code for an arm whatsit, then answer your own question with example code and text on how and why it works. The SO tags would be nice in that you could do a search on "boot" "arm" "embedded" and then one on "boot" "avr" "embedded", etc and get similar example programs for different platforms.
Personally I would go more in the direction of creating an example archive of complete programs for specific microcontroller versions (in typical uses), instead of making yet another "general" tutorial. E.g. one of microcontroller x/y that enables a serial port, one that configures a few digital outputs (setting TRIS and friends), how to set up common frequency/oscillator options etc.
When I started with PIC, (very short PIC16, then PIC18 then 24F and now dspic), one of the main problems is that all the examples are either only fragments or describing very general principles.
A tutorial is no good, if it takes more skills to get the examples actually working than the tutorial teaches.
I usually couldn't find one single complete program for exactly my controller, or even for the slightly wider group (that only vary in number of pins and memory/flash).
The initial program was always the problem, but sometimes later I had the same problem (initializing a certain peripheral) all over again (e.g. the encoder) It is specially frustrating if is the first run of a new micro controller line, and you might not be 100% sure of your hardware.
Unfortunately that takes some coordination, from a forum, an user group or so, since nobody has all devices, and all variants to wire them up (e.g. different oscillator options).
I'm programming this game in OpenGL, mostly working inside an single EAGLView (I'm not that familiar with Views and other Cocoa concepts, my work to this point only involved using OpenGL to draw my game and calculating the logic myself).
I'm being told for adding a ton of features:
Send mails to Your friends when You achieve certain objectives in the game.
Interact with facebook ( I'm being told that I will provided with all the libraries I need).
Interaction with store kit !, buy weapons, Items, etc..
I would like to know, how effort and time will take to add those features... It's complicated to use GameKit ..StoreKit..MediaPlayer and other frameworks ?, considering that I only have worked with OpenGL to this point ?
Short answer: no, it's not hard to add those features.
Longer answer: depending on your background, if object-oriented concepts are new to you, it may take you longer to learn how to use the objects and frameworks. The only thing you can really do is read over the documentation and look at tutorials and decide how complicated it looks. Really, though, it's all well designed and thought out and if you have a programming background, a couple of the examples should give you plenty to start with and you'll get it all soon. And then come on back with your specific questions and smarter devs than I will answer them.
The hard part is all the details: weapons, items, etc.