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.
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.
I don't know UDK,but I'm interested is it possible create war shooter(like Call of Duty,Medal of honor etc.) with Udk in one year with two programmers and one 3D designer?I'm not say as good as Call of Duty or Medal but close to them.
As someone working in the games industry, I would say no. There is a good reason for multiple year development cycles with those teams. Call of Duty games take 2 years to develop even with large teams like Treyarch (around 250 employees).
It's not simply creating tons and tons of content, but making it all fit together, and all the dependencies between things going in. Like you can't start scripting up encounters until you have a level blocked out, and you can't start adding effects to weapons if the weapon isn't in game. You can't localize the text or dialog until it's finalized. A lot of that also depends on new tech from the engineering team. Etc etc etc.
That's all independent of what engine you choose to use.
Yes.
It is an extremely ambitious goal but if you are all working full time on this you could get something of middling quality in that time. It may be buggy and/or unoriginal but it could be done.
No chance of it being anywhere near the quality of the mentioned games though.
Umm of course you can do it, 3 ppl army to build a whole game, well... I will suggest you one thing, scrap cinematics, get rid off nonsense levels and cut to the cheese, thats whats most of the hard gamers look for, no fancy cinematics, straight to the action point.
In my opinion a good multiplayer game mode will do the trick as ,,, per now.. and wait fot the feedback, maybe if your game is good enough you can hire more staff, and work on the 1 player side. So cut to the cheese, and straight to the action, thats my opinion according to the amount of ppl involved in your game development. And many guys here will tell you,, ohh noo you cant get the same level of quality as COD, gee man of course you cant, thats obvious,,3 against 100's no chance, but what it is important is the idea, you have a good idea, put it on paper and then on your game. Dont go crazy and try to create the whole thing, theres no physical time for you 3 guys working 24/7 to finish this off in a year. So, start little with good visual texturing, then go from there. I hope you guys do well.
Nowadays that might be almost impossible. I work at Treyarch, and while I can't say much details, here are the basics:
You need QA - just this, and your quest is over. And this is only to test your game play, logic, whether a level can be completed, etc.
You need even more QA, for things you've never expected - certification (Xbox, PS3, Nintendo), localization (language, censorship, etc)
You need production team. Very motivated and goal oriented.
You need programmers, artists, animators, builders, scripters.
You put at least one person behind every profession, and you need at minimum 10 people. That would've been fine 15 years ago. Unfortunately not now.
People can still do it. There's been some game development of 9 people of sci-fi robots game using UDK (can't remember the name of the game) - but this means engine is provided, and the people have very good motivation, and probably are very good themselves.
Of course you can...the art assets won't be as good though
If you were to purchase your assets (3D models, open source engine, pre-made textures) then I suspect this could be all put together if you guys coded in only the fundamental parts of the game that make it yours.
The question is how much do you want to have commercialy bought versus homegrown and implemented
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.
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 5 years ago.
Improve this question
I am interested in programming for games. I am currently building an iphone game with Shiva using Lua as the scripting language. After that, I am not sure what I should do or what languages I should learn. My goal is to keep building games but I also want to build my own game console. Of course, that won't be for years but I need to learn something right programming now. I know that programming games vs applications is totally different and that's why I need some help. What languages or things do you recommend for me to learn? I also want to be able to create applications but programming applications and programming games is a whole different thing.
The first game I ever wrote was a snake game written in Turbo Pascal. I was fiddling around and managed to get (using a series of dots) a line moving across the screen. Once I did that I made the line change direction. I hooked that up to the arrow keys and got excited. Two hours later i'd gotten a different coloured dot as 'food' up on the screen and it was a game of snake. Each game I wrote pushed me further and forced me to learn new things (ideas tend to roll on from one another.)
Try and stick to arcade style games. Breakout, Pong, Snake, etc. The amount of time it will take you to build Halo doesn't bear calculating!
Don't worry about which language you learn. You will learn many over the years. Right now is the time to ask which is easiest to start writing games with. If you already have the basics of C, then that's your answer straight away.
If you have no idea where to start, start doing animations instead of games. Ideas will come once you get used to your tools.
Write a program that draws a smiley face in the middle of the screen. Changing screen modes and using big graphics engines might be overkill for this. Keep it simple. Get that smiley face to move around, change it's colour, make it an unhappy face, etc. Before you know it you'll pick up some good momentum.
The question to ask is how do I write a smiley face on the middle of the screen instead of just on the next line in the console. In my first snake game, the answer was to write a load of space ' ' characters until i got to where I wanted. The better answer, apparently, is ncurses. If you are on Windows XP then the MingGW compiler is free you can get the (non-standard) conio.h library. That's what I used in my second snake game and it will get you started very quickly.
Good journey!
Look into modding.
I found QuakeC (how Quake1 mods were made) to be really easy to pick up, and you already have a very rich base of game content to use so that you can focus on gameplay and such. I found it a lot easier to stay interested when you're starting with a fun game and adding your own twist to it, rather than starting out making 3d box demos or other overly simple but needed low level programming steps.
Quake1 is pretty old but has the upside of pretty much everything involved in it being open source and free to extend. You could just as easily start modding any of the newer games out there.
A lot of todays big name game shops got their start making Quake or Halflife mods.
Having worked in the industry for several years, this is the best summary I can find:
http://gamesfromwithin.com/so-you-want-to-be-a-game-programmer
My advice:
Learn C++ inside and out. Program in it every day. If you're already set up for iPhone development, learn OpenGL. It wouldn't hurt to learn Direct3D as well if you have access to a PC ( also have a look at XNA ). If graphics isn't your thing, make sure you know how pathfinding (A* algorithm) or collision detection works.
Keep building your own projects, and find a good online community that can support you if you have questions. Employers want see that you are smart, but more importantly, that you are dedicated - game programming is very hard, don't let anyone tell you differently.
You can download free development tools for Windows here:
http://www.microsoft.com/express/download/
The one you want is Visual C++ 2008 Express Edition.
Perhaps check out some of the game programming links here: http://lazyfoo.net/SDL_tutorials/index.php
Those tutorials assume C++ which is used a lot in games programming so may be worth learning.
Or you could check out this tutorial if your interested in Java http://www.cokeandcode.com/node/6
Adam
You should check out Unity3D website. They have now a free version (named Unity) for personal and commercial use. You can use scripting with C# (possibly any .NET language), JavaScript, and Boo.
XNA would be a good fit too.
When you're just starting out, C, C# and C++ might be a bit complex to start with. If you're serious about game development, you will probably need to learn C++ eventually, but if you just want to quickly get some things done, you're already on the right track with lua.
Javascript is another language which is very similar to lua in many ways (and very different in others). One advantage of javascript is that everyone in the world has javascript installed on their computers. Another advantage is that it's very easy to learn. There are disadvantages too, but they are not nearly as bad as most "serious" programmers think. Javascript gets an undeserved bad rap.
Here is a very good tutorial for learning javascript:
http://eloquentjavascript.net/
It does not cover games programming, unfortunately- But it does cover concepts that are relevant to both games programming and application programming.
Here is a tutorial for javcascript that does cover games programming:
http://billmill.org/static/canvastutorial/index.html
you will need a web browser in order to follow that tutorial. This does not include internet explorer, so you will probably want to use safari, firefox, or opera.
Once you are comfortable making games in an easy language like javascript or lua, then it will not be quite so hard to learn to make games in a hard language like C or C++.
On the other hand, you might be happy just making games in the easy language, and that's okay, there's no rules that say you have to learn C or C++ to make good games. Good games come from good ideas, not difficult programming.
Priority Order for a game programmer.
Any subject that needs Analytical thinking and Logical Problem Solving.
Necessary knowledge in the following domains.
Mathematics
Data Structures
Computer Graphics
Physics
Artificial Intelligence
Computer Networks
Web Technologies
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.
There are many CASE tools, many software for diagrams, drawing, documenting. But can they replace old good paper?
Every day, all day! (Okay, not all day, but a lot)
I actually had a debate a while back on the value of psuedocode, and I was giving my input on how much pen/paper and some pseudocode could work wonders at times :)
I use computers to solve easy design problems, but when I hit something really hard I break out the powerful tools - pen, paper and brain.
I use a whiteboard for design and pen-and-paper for TODOs.
Especially when it comes to doing some math before the implementation, there's nothing better than putting it down on paper first!
No software can ever replace the sheer ease of jotting down ideas and solution sketches using pen/paper! EVER!
Once you have your critical thinking down on a paper you can take your time to beautify them using fancy softwares and tools.
All the time I use pen and paper, I find them invaluable tools to programming! Making notes, etc, etc...
Using quick sketches is an invaluable tool in clarifying requirements with a client. You don't have to be Da Vinci to quickly encapsulate complex business logic or UI behaviors in some simple sketches. Leah Buley at Adaptive Path has great resources on sketching for UX. Programmers can learn these techniques as well. You'll save a lot of time using paper first, before sitting down in front of Visio.
I vastly prefer pencil & paper (or pen & markerboard) for real-time thinking. It can handle just about anything my brain thinks of. If I need to create any official artifacts, I'll take what I've drawn and set it up using a tool. But usually the initial copy is sufficient.
On a side note, I'm still not sure why just about everyone in college switched to laptops for taking notes. You don't have anywhere near the ability to express your thoughts in Word as you do on paper.
All the time, especially for complex logic with lots of conditional programming!
I always find it easier to jot down what I'm about to draw/model before using application tools.
All the time. When I want to draw/write something complex, I don't want to master a piece of software to do it. Also means there are no extra applications hogging up my system resources. Plus, there's something satisfying about writing at all angles on a piece of paper :).
Most of the times when I program you can see papers all over my desk, some are wrinkled on the floor and some are not.
I usually do my brainstorming on paper and preliminary UML diagrams.
If only I had a whiteboard... :)
I don't use pen and paper when working alone, but I always use them when working with other people, talking with customers and so on. I mainly use pencils to draw diagrams.
In my opinion, the most beauty about programming, its heart its about designing good algorithm or pseudocode.
I thought before that a paper and a pen could be a good idea but I went ahead to write it, They were easy programs though, short ones.
I just approached the PNP question, not that I expect to resolve it but curiosity rules me,
You do not need to face such a big problem to use paper and pen but since I got into that I realized how important It is.
It saves time, makes you more efficient.
General while you are programming you concentrate in small concepts like: Is this variable int...?
To have a big picture of the program, the best way It is a pen, that lets you concentrate on a problem and the go with the technical stuff, memory management, security, fast code...
If you go directyle into the keyboard, You might spend lots of time creating a big powerful function to realize at the end You do not need that because It happens that variable "a" will always be negative or whatever.
But please trust me I just started programming but happily I have discovered the world of the pen and paper.
I just realized that your question is actually nor a yes no question is it about comparison with diagrams, documenting.
Pen and paper before writing the program.
Documenting while You program and that It is a good idea to use a computer, I mean of course You can document it with papers but having you code full of /* */ It is just faster and better to read it and edit it again.
So there is a place for both things but stick with the pen at the beginning.
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*