SimonForsmanMember Since 18 Oct 2005
Offline Last Active Yesterday, 06:21 PM
- Group Crossbones+
- Active Posts 3,855
- Profile Views 15,452
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by SimonForsman on 03 July 2012 - 04:13 AM
1. Learn how to program, (in any language really)
2. Learn how to make games,
3. Learn how to make applications for <insert non desktop platform here>
Posted by SimonForsman on 02 July 2012 - 03:26 PM
You can first render the wall normally, then render the character without depthtesting (fairly simple but probably not quite the effect you're looking for)
you coukld also Render the wall twice, first at X% opacity without depthwrites, then render the character, then render the wall again at 100-X% opacity and additive blending.
Those two effects basically just make the character visible through the wall and might not be what you want.
You could also project the character onto the wall (in black or grey) (or the walls position rather) (towards the camera) and write that to a separate otherwise white texture, apply blur to the texture, render the character normally and finally render the wall using the greyscale characteroutline texture as the alpha channel. (There are probably faster ways to do this aswell).
Another option could be to render a scaled up version of the character to the stencil buffer and use that for a stencil test when you render the wall (works with fixed function), or render to a texture and process in the pixel shader (to get fancy edges for example), (With ES 1.1 the options are a bit limited, but with 2.0 you can do pretty much anything)
Posted by SimonForsman on 02 July 2012 - 03:57 AM
there are quite a few languages that are notorious for not being able to develop with
Good luck making something that is actually useful with it (Its not even the worst language out there, some such as "whitespace" are even worse). (When it comes to mainstream languages however its quite hard to find one that is really awful, some are quite a bit worse than others though)
Posted by SimonForsman on 02 July 2012 - 03:45 AM
I would try Unity but everything i have seen of it just looks too cartoony. i like the real look you get from unreal and cryengine
I'm going to say that your requirements list is likely satisfied in any engine.
- "figuring out the player position" is a world data query,
- movement to that position is somewhere between a "rotate to face" and a pathfind, and
- "melee attack them" is an animation change based on proximity (which is also simply world data),
Since you seem a bit new (I might be wrong), you might want to consider simply going with Unity instead like all the cool kids are doing these days (including me for many things).
The look of the final product has nothing to do with the engine really, (some effects might be easier to create in some engines than in others though), The main reason alot of Unity games look "bad" is that they use the free version (Which doesn't support dynamic shadows or render to texture, thus preventing some effects from being used) and are using amateur artists(Who don't produce the high quality assets you need for a good looking game) professional games made with Unity can look really impressive (These are harder to identify though as the pro version allows you to remove the Unity splashscreen making it virtually impossible for the end user to identify the engine used)
Posted by SimonForsman on 01 July 2012 - 11:48 PM
I wanted to know if it was a good idea to use freeGlut in a commercial quality product or if I should go with something like SFML or SDL.
Any explanation would also be nice.
If it works for you then its fine to use commercially as well, it is however worth remembering that glut was only intended as a support library for the OpenGL Redbook examples, it lacks alot of things that you will need in a game (sound, proper input, etc). and it does steal your mainloop which gets quite annoying after a while. (You can solve sound and input using additional libraries such as OpenAL)
Posted by SimonForsman on 01 July 2012 - 05:48 AM
If a basic game requires to be able to do multitasking stuff, how many threads does a game requires? Thanks in advance.
You only need 1 thread (computers are fast and multiple tasks executed after eachother will appear to run at the same time (The vast majority of games on the market are singlethreaded)).
I'd strongly recommend against writing multithreaded code if you are just starting out, it adds quite a bit of complexity.
If you are going to go the multithreaded route anyway i'd recommend looking at thread pools, don't split the game in one physics, one ai, one renderer thread etc (it doesn't help much at all), instead split for example the AI into multiple smaller units that can be processed independently and have a pool of worker threads that processes these work units for you(You can vary the number of worker threads based on the hardware it runs on more easily aswell). (a semi functional approach to your state updates will make it easier to avoid excessive synchronization (just write to an old state object/structure rather than returning a new one to avoid unnecessary allocations).
Posted by SimonForsman on 30 June 2012 - 01:45 AM
Fair enough, but I guess what I'm asking is, what are my options? Like could someone name 10 ways people make games? Presumably there's a pretty small number of *sensible* ways to make a 3D voxel game with building and multiplayer, like methods/frameworks that people who know what they are doing would use, as opposed to silly ways of trying to do it.
There are lots of ways to do it but none of the big engines is really helpful (you can't just hand them your voxel data and expect them to deal with it as you can for games using meshes or sprites) you will have to write mesh generation and physics code yourself anyway (For voxels its best if you do your collision tests against the voxel data rather than creating collider objects to use with a normal physics engine).
This means that the only features you need from a game engine is the ability to create custom meshes at runtime and render 3D graphics, Any 3D engine should let you do this and as you are ignoring most of the engines other features the things you should be looking at are:
1) Platform support (Try to pick a language that is available on all your target platforms and libraries/frameworks/engines that support as many of them as possible, keep your own code as isolated as you can so that moving it to a different engine or swapping out the libraries it uses stays reasonably easy)
2) License costs and restrictions (You won't use most of the functionality provided so cheap/free and as few restrictions as possible are a good idea)
Posted by SimonForsman on 29 June 2012 - 12:45 AM
Personally I go with Ogre, but I know c++ and Blender and am on Linux. For you, I'd recommend to have a look at Unity and UDK. And hey, without lots of time....forget about it. This should also go into a FAQ section....
I'm not sure unity is that well suited for a minecraft clone, you'd most likely benefit quite a bit by writing your own voxel renderer for such a project.
As for C# it will work on Linux and OS X aswell as long as you don't use XNA(or one of the DX wrappers), (there is an XNA port called monogame in development aswell but i don't think its quite there yet). C#+OpenTK work really well for cross platform development (atleast on desktop pcs).
If you are going to target a wide variety of platforms you really want to make sure you keep as much of your game logic separate as possible since you might have to replace/rewrite other parts of the game. (You cannot target the xbox360 as an indie without using XNA and you cannot target the ipad using XNA, you can however use C# for both platforms and just swap out the rendering/sound/input libraries.)
Posted by SimonForsman on 27 June 2012 - 04:04 PM
2) Yes, programming is pretty much required if you want to make your own games. (There are a few game makers out there that let you make simple games without any programming but as soon as you want to actually create your own behaviours (which you have to do in order to make your own game) you will have to at least be able to write some scripts)
Posted by SimonForsman on 27 June 2012 - 03:30 PM
2) Yes, a CS degree is valuable for pretty much any programming related job.
3) it depends on what software you want, you can do everything with free software if you wish allthough the more expensive applications tend to provide a fairly solid productivity boost which pays off in the long run.
4) you can't make software without it so it is fairly big, for AAA games however you tend to need far more artists than programmers. (The main thing that separates AAA games from indie or hobbyist titles is the art budget)
Posted by SimonForsman on 27 June 2012 - 01:18 PM
I don't think any language is more conceptually difficult then any other language. They all have their quirks, even assembly is pretty easy if you start with it. Feel free to start with whatever language you want, but you need to master a computer language before you can do much. You will also find knowing one computer language helps you learn others.
The problem with some languages isn't just the quirks, its their usability.
Assembly is extremely easy to learn, there are almost no rules and a fairly limited set of instructions (Which you don't have to memorize), its an extremely tedious and difficult language to actually make something with though.
It took me roughly 2 hours from installing Unity and mono until i had my first completed C# game (with no prior experience using C#), i still don't know C# (take away my references and autocomplete and i can't get anything done with it), Ask me to do the same with C++ (which i have over 10 years experience with) and not only will making the same game take me atleast two days, maybe even a week, it will most likely be of lower quality, run slower and have more bugs, Those 2 hours spent with unity also taught me quite a bit about engine interface design and allowed me to experiment a bit with gameplay mechanics, skills that will carry over to anything gamerelated i make in the future, regardless of what language i choose for it.
Modern languages let you get away with not actually knowing the language while older languages such as x86 assembly, C, C++, etc not only requires you to have a fairly solid grasp of the language (to avoid fucking everything up) but also requires you to have decent knowledge about the underlying platforms and their quirks, Those all add up to push your focus towards learning things that are very likely to change in the near future(Why does sin(6.29) give a different result on my server than on the clients when they're all 64 bit intel machines running Windows causing my lockstep simulation to desynch in a horrible mess and why should a beginner have to worry about that instead of learning how to actually write a lockstep simulation ?).
(C++ has become alot better recently but the legacy crap is still there(a problem that Java also shares, backwards compatibility is a double-edged sword) and still causes unnecessary headaches for anyone who doesn't allready know the language well)
Posted by SimonForsman on 26 June 2012 - 03:48 PM
Posted by SimonForsman on 26 June 2012 - 08:42 AM
Funny you should say that (and, to Tom Sloper). I've heard this word for the first time in my life too. Google brings up a lot of pages about a WoW cheat bot, and neither Wikipedia nor Wiktionary seem to know it.
How can you not know what epeen means when you are working in game biz?
But, back to topic... what makes you think someone would not wager money if there is something to win, solely under the assumption that anyone else is better? Greed is a powerful motivator (the main device behind every kind of con and every kind of gambling). Of course people will put money on the table if everyone at that table does.
Posted by SimonForsman on 26 June 2012 - 12:16 AM
Unrealscript can only be used with Unreal Engine / UDK and "only" lets you control the unreal engine.
Then in your opinion are there any limitations in unrealscript versus cpp?
C++ can be used for anything(almost) but supports almost nothing. it is great for building new systems but not really a nice language to use for controlling existing systems. (Which is why so many games these days use higher level scripting languages(unrealscript, lua, python, etc) for the game logic)
Posted by SimonForsman on 25 June 2012 - 12:45 PM
Store your objects in a tree structure based on location and you can avoid even looking at objects that are far away.
For 2D games a quadtree tends to be fairly efficient (it also works well for 3D games if the world is reasonably flat) , you could also look at octrees or bsp trees.