As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've been trying for a couple of days now to learn UDK, but I seem to be stuck at making that leap to understanding how everything works together. I understand the syntax, that's all well and good, and I pretty much get how classes and .ini files interact. As for the API, I have the entire reference as pretty decent Doxygen-style HTML output.
What I'm looking for is a sort of intermediate tutorial on game creation from scratch (as opposed to modding UT3 itself), more advanced than just learning language syntax, but not yet to the level of going through the API step by step. I'm looking for some guide to the structure of the internals - how GameInfo and PlayerController interact, where Pawn comes in, etc. - a way to visualize the big picture.
Does anyone have a particular favorite intermediate-level tutorials (or set of tutorials) that they used when first learning UDK?
Check out these these were (maybe still are?) the best when I first started. I have then since stopped using UDK due to lack of time but these are really good.
http://forecourse.com/unreal-tutorials/
Strangely, I never found tutorials on that topic.
In the way things come together, there is no big difference between modding UT3 and creating a new game -- it's just easier to play around on top of UT3 code because there's content to work with.
Development/Src contains uncompiled source code. Each of the folders in there gets compiled into a .u script package for use by the editor and the game. They end up in UDKGame\Script
UDKGame has all the packages, including assets, maps, and compiled scripts.
GameInfo (or your class derived from it) is used for things central in your game. A standalone game would derive from this. The derived class does not have to be big, it's probably not a good idea to put a lot of logic here. You can and should use this class to store central properties for your game -- like, what HUD class your game uses, what player controller class, etc. For example, a racing game could track the time of the race here, and notify players when race started or ended, and would also have a property like HUDType=class'Racer.RacerHUD'.
Controllers, such as PlayerController and AIController (which UTBot is derived from), are used to send instructions to Pawns. Pawns don't do anything on their own, they're more like empty shells that the controller can manipulate.
Things handled in the controllers are AI and input. Things handled in pawns are all kinds of animations for movement, taking damage, etc, anything visual.
Sorry, I don't have time for a longer answer, but I hope this helps a little bit.
PS -- What helped me A LOT was getting the game Whizzle and reading each class in that code. It does not derive from UT3 code, and it's very very small.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Im thinking about starting a website project with a framework that will be also a study project for me. To be more exact a biologist kinda site with quite some filters and there is the question also if I should use separate database or flat file for 8 translations for the different species names (the site also has to be international, but just with 3-4 languages). Im thinking hard about which road to take... so I am asking for some constructive inputs please!
Im thinking of yii because of its simplicity, I tried it and it seems to be working smoothly.
Im thinking of symfony2 because it seems to be more advanced and some great websites were built with it, also drupal8 was constructed with it if Im not mistaken... and even if its harder to get going with it if its worth the effort I would do it.
Im thinking of spark, a java mini framework or Eclipse Link as later I plan to make an offline version of this webpage and I hope its not that hard to port it as a standalone java app. But I'm novice in java and hate the java documentations filled with acronyms all the time and supposing that I know those essential steps that are considered to be self evident by experienced java programmers.
I think there is no correct answer to your question. Chosing a framework is a matter of philosophy, and personal preferences. Some people will think that Yii is easier to use and some other will be amazed by symfony capabilities.
If you know a framework, I'll advise you to stick to this one and if you don't check out the basis of each ones and choose the one that seems to fit your need the most.
But at the end if you choose a popular framework (Yii, Symfony, Laravel, ...) you'll be able to achieve your goal.
Personally I like Yii, having never used the others :) For this exact reason I've flagged to close this as not constructive. There is no correct answer to this question.
I would start up a project in each, try and accomplish some common tasks, then decide. Ultimately you'll be able to acheive everything in all those frameworks. The deciding factor will be how fast and how comfortably you can use the frameworks, not how everyone else uses them.
Yii supports multiple databases very easy; Think about this;
All you have to do is create the database and the rest is, easy ...
Just create a simple blog app, and see wich one is the easyest and fastest when developing.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
After investigating a little bit scrum and kanban, I finally read this answer and decided to start using kanban, picking something from scrum (note that I'm working mostly by myself, and I do have read this question and its answers).
Now, my question is: which tool would be best to get started?
whiteboard and postit
agilezen.com
JIRA with greenhopper
a spreadsheet (possibly on Google Docs)
brightgreenprojects.com
Agilo
Target Process
something else (please specify)
Notes about each:
I would lean towards the whiteboard, but there are several drawbacks (e.g. cannot make automatic charts, time measurements, metrics, and sometimes I work from home - where I need it most - and it's not convenient to carry :-)
I don't want to remember another username/password (I promised to myself to signup only to OpenID-enabled services)
My employer has JIRA but my group doesn't use it - I might ask for an account (it shouldn't require another password) and maybe later involve the rest of the group. But I don't know if they are using greenhopper and if it's a big deal installing it.
I generally hate spreadsheets
maybe overkill?
I'd be happy to have a localhost instance, but it could be problematic to give access to the whole group (per network/firewalls) - not a deal-breaker but surely a concern
What I'd like to get from this?
being more productive
tracking how much time I spend in any given task, possibly discussing the issue with my supervisor
tracking what "blocks" me most often
immediately see where I am compared to my schedule
manage in a better way my long todo list (e.g. answering faster to the "what I should do next?" question)
Do you have any suggestion?
Note on the scrumish tag: read the Henrik Kniberg's PDF. He first introduced the definition of scrumish on page 9.
If I may, I think that you are on the wrong path. Anything else than 1. or 4. is overkill and pretty much useless for a non distributed team. So for a team of one person...
Seriously, if you can avoid using a web based application, just do it. First, unless you are already mastering Scrum/Kaban, you need to learn the process, not a tool. Don't let a tool dictate the process. Then most web based tools are just too much click intensive, less easy and fast to update, less transparent/visible than a spreadsheet and a physical board. They are really 2nd category options.
So, I'd go for a spreadsheet and a physical board combo. If you need some charts (I'm still wondering what kind of chart/metrics you want to generate and what value they provide), a spreadsheet is the ideal tool (but honestly, you don't need any tool to draw a burndown). If you need to work from home, take the spreadsheet (or use google docs) and post its with you. Let's be objective, the impediments you mentioned are actually not real.
Last thing, if you had chosen the simplest thing that can possibly work, you would already be doing Scrum, Scrumban or whatever. So, instead of looking for a tool, my advice would be to just start doing it.
agilezen.com seems like the ideal solution for you. I have used it in the past solo for myself and it is convenient. I would not let a prejudice against non-OpenID sites get in the way of making a good choice.
pick the tool you already have, and start using it; don't let the absence of the "perfect tool" become an excuse not to start
EDIT: pick the simplest thing that can possibly work. In your case that would be whiteboard and postit notes. These have almost no setup overhead and will provide a constant visual reminder of what you're supposed to be doing.
And I suggest that you get used to making decisions on your own, as you're going to have to be your own Scrum Master ;-)
In the interests of diversity ;-) www.kanbantool.com has just launched too. It's open beta and seems at first glance even more "lightweight" than agilezen.
Target process is good too
We've been using JIRA with Greenhopper for a few months, in an effort to go agile. I use it for both Scrum for development, as well as for my personal kanban. The software is pretty flexible, and I'm going to keep with it. The story/subtask management is really handy, and it's fairly easy to use. One thing I like is that you can add stories/cards quickly, and can customize the data. This allowed me to add definition of done fields, work order numbers, etc.
In short, we're happy with it.
Bright Green have just launched a free version of their tool. It looks good .. the free version is fully functional too: https://signup.brightgreenprojects.com/plan/Free
I've tried out another kanban product for personal use and am absolutely loving this one. Feels lightweight and simple but actually packs in a fair amount of functionality at the same time.
www.kanbanery.com (free for personal use)
A novel tool not mentioned before is getsmartQ (out of beta since Dec 2010)
Key characteristics: very intuitive, supports LWP, customizable forms, and task discussions
Pros
configurable workflow, mark overdue stories, mail notifications (e.g., for upcoming story deadlines), multiple story owners
Stories form completely customizable, per project workflow and story forms, different roles (people only creating stories)
very responsive GUI with partial updates
Apparently good support: I've asked a question and got a good answer within a few hours
Cons
no easy way to declare something as blocked or to distinguish type (feature/bug/..)
no API
no subtasks or story dependencies
In comparison to Agilezen it has a more sophisticated notification system, but apart from that still lacks important features (see cons above).
Note, getsmartQ is under active development and hence missing features mentioned above may have been implemented in the meantime.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Drupal seems to have lots to offer to the non-programmer. Tons of modules and easy installation. But at what point would you say you need to be a programmer? Where does it fall down and require more hands-on attention?
Also, even though they aren't "meant" to be done, I'm interested in any custom tweaks you've had to do to the code base.
I strongly disagree with the idea that you need programming skills when you want to do something different than the 'out of the box' functionality, unless "out of the box" includes the myriad of ways one can mix and match the thousands of third-party plugins.
The biggest challenge is this: Drupal's community is moving more and more towards building small, reusable blocks that can be combined in novel ways via configuration, rather than coding. This means that the number of things you can accomplish by combining small pieces via administrative screens is impressive. However, it means that the tools you put together this way lack a lot of the 'smooth edges' that would be there with a single built-to-spec plugin.
It's those places -- the rough edges -- where custom code is most frequently needed. Writing a short hook_form_alter() function to hide some unneeded form fields or change the location a form redirects to when it's completed, building a simple custom sidebar block to give the use some useful links to the different pieces you've assembled, things like that. Custom theming also takes up a lot of that 'smoothing' work.
This is to say that you can do insane amounts of stuff with zero code, but you will reach a point of diminishing returns, especially when trying to build complex rule-based logic ("Under certain circumstances, I want X to appear, otherwise the user should be prompted for Y..."). Knowing at least some PHP, not being afraid to peek at what's going on under the hood, and the willingness to write a (small!) custom module to accomplish certain tweaky goals will definitely serve you well on more complex sites.
Also, it's easy to find plugins that do interesting things but are still in beta/development. Knowing some PHP will help you keep your head above water if you decide to work with 'not quite finished' code.
The only time you'd need a programmer would be if there was some functionality that you wanted and current plugins just did not provide what you were looking for. Most Drupal-powered sites can be run by non-programming types. In short, I'd say you would need to be a programmer if you need to develop custom functionality not found in any of the available plugins out for Drupal now.
Slightly off topic, but addressing one point you made:
Also, even though they aren't "meant"
to be done, I'm interested in any
custom tweaks you've had to do to the
code base.
It's open source software. You get to decide what's "meant to be done," based on your needs and desires.
Some of the best features start out as someone changing or using something in a way no one else had anticipated, thereby producing something new, interesting, and useful. Finding out what customizations others have made like this is a great way to broaden your understanding, and nothing to be furtive about.
I've used drupal without ever need to do any "programming", and if you don't have programming skills you could always use a cheap contractor (e.g. rent-a-coder or similar) to quickly/cheaply modify/create a plug-in for you.
There are a lot of modules available, but as soon as you want to do something slightly different than the out-of-the-box functionality, you need to be a programmer.
Personally, I have never altered the core codebase. It is really not recommended. I have taken existing modules and either taken parts of them to use in my own modules, or renamed them and modified them as my own.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would like to know How to create a fps-game with SDL lib?
Are there any books that explain with examples?
this wins for most open ended question. You could literally write a book. But lets settle for pointing in the right direction...
Step one, you will need good debugging skills for a project like this. Pick up Code Complete by Steve McConnell. Read the whole thing. The time invested will pay for itself more than anything else you could read/experiment with.
Get your hands on some source code of some game. ANY game. Make sure you see something simple before you see something big and complex, and keep in mind when you look at any game code that they may have had a combined team put WAY more time into it than you will ever have. The point in this is to see code structure.
Get a reference for 3D math, doesn't have to be THAT in depth, but you will need to know stuff like dot products backwards and forwards, be able to figure out how to create the matrix for your camera in the world etc. (even if your writing 0% of the rendering code)
(edit) Here's a great book on 3D mathMathematics for 3D Game Programming and Computer Graphics, Second Edition (Game Development Series) This isn't the kind you learn in college, it's more like a cross between trig and more advanced practical concepts: How to create a toolbox for yourself of simple physics, efficient collision detection, etc.
You will need to know something about rendering, and pipelines. SDL gives you a leg up, but make sure you understand the concepts of what it's doing.
Read up about practical system design. Your various systems will have to interlock. Think it out well. Your system can be just a good in C or in C++, it's the THOUGHT that is put into how your data/control will flow that will count, NOT how perfectly you emulate design patterns (though these are very useful as well of coarse)
Fundamentals of AI, not "real" AI, but functional AI; there is a big difference. State machines are great to start with, and sufficient for a simple FPS.
Learn a little about estimation and planning. You will not have time to do everything you would want to do to properly make an FPS. You will have to both triage AND learn how to triage; they are 2 separate things, the latter being mroe difficult. Experience is the best teacher here of coarse. (though the legendary McConnell has book on this as well)
Have a system to insert your gameplay into your level. If it is JUST you as a programmer, then your best bet is to write a plug in for an already existing editing program such as 3DS Max. I would highly recommend Max over Maya for a programmer. Maya script is nice, but it is more geared toward clever non-programmers. I find 3DS Max to think more along the lines of how a programmer would about creating and editing your world.
You can spend YEARS making tools to let you do this right, so you want to do things in such a way that you can edit fast and accurately
If you making your own editor, incorporate it into your game world.
If your world is not TRULY 3D and you want to make lots of level fast you can save your level data as something like this, which will save you a lot of time
Where X is a wall, the other letters are game objects which a dirt simple parser can translate into game objects and world coordinates
xxxxxxxxxxxxxxxxxxxxxxxx
xx..........P..........x
xxxxxxx...........I....x
xR....xxx...........E..x
xx.................0xxxx
xxxxxxxxxxxxxxxxxxxxxxxx
But it all depends on your game. My point is that you will need to resort to "ghetto coding" how you get your gameplay data into your world is very important and you need to think of something that is both fast for you to implement AND fast with you to work with.
And what it comes down to is what is your goal here? If it's to learn to code something the absolute right way, expect to spend most of your time iterating on code that seemed decent a month ago, but now that you realize what your requirements are, it could really use another pass. Do not be afraid to rewrite, you learn a lot by doing that, but if you goal is functionality, you will probably need to figure out where to hack some things in (like embedding gameplay data nad coordinates into code files) It IS ok to hack as long as you KNOW where you have hacked, and have carefully kept it separate from your good code so you can go back and properly write the code when you get the chance.
The bottom line is, you need to decide what your goal in this is, learning, or functionality and find the happy medium between.
Download the quake 3 sources at fileshack and learn from them.
Although the very long post is valueable in the long run, I feel it doesn't give the proper instant motivation of getting things on screen. Here's some facts, along with my opinion
-SDL is a 2D graphics library, you can't write an FPS in 2D, therefore you have to go with a 3D library, either DirectX, or openGL
-SDL has the ability to "sync" with openGL, using it for graphics, but there's not a whole lot of help online for that topic
I suggest you go to Lazyfoo.net, which is an absolutly amazing beginner's resource for game programming with SDL, it shows you how to draw to the screen, but also teaches you how to apply this to programming games. After going through this, you'll be able to make a tetris clone, or most other 2D type games
After this, you'll be ready for 3D(it's a lot more complex, requires a better grasp of math, and takes a lot more code to do simpler things) if you go with openGL, check out NeHe's Tutorials , they're currently working on a new set, using SDL with openGL, because the older tutorials, although valueable, are coded rather badly and use the windows(win32) API
keep in mind, game development is one of the most demanding, and rewarding programming you'll come across, so good luck
While not SDL specific, the NeHe OpenGL tutorials are an excellent place to start for learning about how to do 3D.
If this is your first game, you'll probably want to aim lower than an FPS. Writing a simple 2D Tetris game using SDL will teach you everything you'll need to know about that library.
Pretty much anything that says in the TItle the "Tricks of the Game Programming Gurus" is going to show you how to make a FPS game. LeMothe loves them.
Edit : forgot those titles.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We prototype a design, GUI, just to analyze a particular problem, proof of concept, etc. Sometimes we throw away the prototype, and sometimes it ends up in the production code. We use different languages, technologies, strategies, and styles to prototype.
What are the different situations you prototype usually and how do you prototype? Any good resource out there to master the craft?
One hot title is Effective Prototyping for Software Makers. The issue is that there are several schools of thought.
Rapid Prototyping. Use fancy tools; get
something done soon.
Evolutionary Prototyping. Evolve from prototype to production.
Some of this is legacy thinking, based on an era where tools were primitive and projects had to be meticulously planned from the beginning. When I started in this industry, the "green-screen" character-mode applications where rocket science and very painful to mock up. Tools and formal techniques were essential to manage the costs and risks.
This thinking is trumped by some more recent thinking.
Powerful tools remove the need for complex prototypes. HTML mockups can be slapped together quickly. Is it still a prototype when you barely have to budget or plan for it?
[You can mock it up in MS-Word and save it as HTML. It's quicker for a Business Analyst to do it than to specify it and have a programmer do it.]
Also, powerful tools can reduce the cost of mistakes. If it only took a week to put something together -- production-ready -- what's the point of an formal prototype effort?
Agile techniques reduce the need to do quite so much detailed up-front planning. When you put something that works in the hands of users quickly, you don't have quite so much need to be sure every nuance is right before you start. It just has to be good enough to consider it progress.
What can happen is the following. [The hidden question is: is this still "prototyping" -- or is this just an Agile approach with powerful tools?]
Using tools like Django, you can put together the essential, core data structure and exercise it almost immediately. Use the default Django admin pages and you should be up and running as soon as you can articulate the data structures and write load utilities.
Then, add presentation pages wrapped around real, working data. Be sure you've got things right. Since you've only built data model and template-driven HTML pages, your investment is minimal. Explore.
Iterate until people start asking for smarter transactions than those available in the default admin pages. At this point, you're moving away from "discovery" and "elaboration" and into "construction". Did you do any prototyping? I suppose each HTML template you discarded was a kind of prototype. For that matter, so where the ones you kept.
The whole time, you can be working with more-or-less live, production users.
Personally, I believe a true prototype should not be much more than diagrams drawn on paper to demonstrate the flow of whatever it is you are trying to achieve. You can then use these documented flows to run through several scenarios to see if it works with whoever has requested the functionality.
Once the paper prototype has been modified to a point where it works then use it as a basis to start coding properly.
The benefits of this process are that you can't end up actually using the prototype code in production because there isn't any. Also, it is much easier to test it with business experts as there is not any code for them to understand.
Right now I just draw pictures. I would like to do more, but to get something to a point where the users would understand any better than a picture would cost to much time.
I am interested in seeing some of these responses :)
I should mention where I work is just me and one other guy to play the roles of project manager (collect data, design spec & app), dbas, coders, tool researcher/developer, et al that comes with the job of making an app for a small company.
For webapps, start with an pure (x)HTML + CSS mock-up, and then use a framework that makes it easy to implement the functionality.
Template-based frameworks are very good for this, but we've had some good experiences with JSF + Facelets + Seam, too.
The main reason for doing prototypes is reducing risk. Thus, we do UI prototypes, which are really not very helpful unless they actually do something that a user can play around with. Just as important, we also do prototypes to either prove that something can work or figure out how something does work.
I start off making a prototype that makes the most interesting part work, then I throw it away and move on to a new, more interesting project...
*kills self*