Jump to content

  • Log In with Google      Sign In   
  • Create Account


MrDaaark

Member Since 01 Aug 2001
Offline Last Active May 16 2013 07:14 AM

#5043060 Why facebook games developed in FLASH and not HTML/5?

Posted by MrDaaark on 14 March 2013 - 08:21 AM

i want to develop facebook game and i really don't what to start to learn FLASH .

That attitude in general won't get you very far. There is always a new language, skill, or technique to learn when developing something!


#5042952 Size of 3d models for a fighting gameand others doubts

Posted by MrDaaark on 13 March 2013 - 08:58 PM

I'm not sure what you mean by reference pic-

Most models, especially characters are modeled on top of reference pictures that are dragged into the 2D viewport.

It doesn't matter what size they are, because the proportions will never change. Just drag them in, and line them up so that the front and side views match up. Don't worry about the scale until you are done. When you are happy with the model, remove the reference images and scale your model to whatever height you want. If you're using 1 unit to a meter, then your model will end up 1.8 units tall.

There isn't any form of using the same rig for various models, right? You have to rig manually every single character, isn't it?

You can use the same skeleton for all your characters with some exceptions. You can re-target, or even copy and paste the skeleton from one model to another. As long as the characters have the same number of joints.


#5041906 portfolio

Posted by MrDaaark on 11 March 2013 - 10:49 AM

Put your showcase work on your website. Use DeviantArt for everything else.


#5041855 Existing 3D Game Engine for Gameplay Programming

Posted by MrDaaark on 11 March 2013 - 08:44 AM

Yeah, that inventory stuff is all simple programming. It is just a list. Complex ideas do not mean complex programming. Everything you mentioned is just a few lines of code attached to different events that reference that list. The code will more or less look the same in any language.

Scripting languages aren't dumbed down. They often aren't 'scripting' languages at all. They are full on languages that can do anything, and as I said in my post above, they are only called scripting languages in the context that they are being hosted in another program. They exist because they have different goals than C++. They let you model problems at their face value and ignore machine specific technical details that have nothing to do with the problem you are solving.

C++'s purpose is to be a portable language that targets system level programming. It's good at moving memory around and doing complex calculations really quickly. Other than ASM, it's the best too for that job. It can leave a lot to be desired in other areas though.

Other languages are better suited to different tasks, and to express different ideas. C++ is all about machine level details, but when the problems you are dealing with have nothing to do with those details, C++ can actually become a hindrance.

Sometimes you just want to process text and numbers at face value (instead of as char arrays, and numbers as objects with bit limits and sign issues). Sometimes you want 8 to just be 8, and not a representation of a 32-bit unsigned integer. Sometimes you want to deal with words and phrases, and not character arrays or strings. There are languages that can hand C++ it's own ass in these areas. That doesn't mean C++ is bad. It's just not what C++ was designed for out of the box, and it can't express those ideas as neatly and elegantly.

So it turns out that the best tool for the job is to use a C++ to solve the system level problems, and host a virtual machine to handle the actual game. The engine can then be small and fast and focus 100% on it's area of responsibility.

The scripts can be executed quickly, changed on the fly, without recompiling anything, and won't introduce bugs into the executable. The scripts also add almost infinite possibilities to what an engine can do. It's a win/win situation.

An engine will take 10,000 objects in a scene and do a quick collision detection pass on them. It will then generate a list of collision events, and hand them off to ->

The scripting engine, which will handle collision response. A script will fire and it will know which object it collided with, and have a data structure passed along with all the other relevant information. You object can now bounce, disappear, turn green, blow up, play a sound, trigger another event, generate code on the fly, or whatever else you come up with.

The engine does the detection because it's faster, it's technical, and it's standard behavior, not needing flexibility.

The script handles the response because it needs to be flexible and open ended. Most scripts will be dealing with event reactions, which are rules, and not technical details. These are not 'c++ / system level' problems.

Quote
Also, why do gameplay programming positions require expertise in C++?

It's an industry buzzword, and a C++ programmer can easily learn any other language. A C++ programmer will have experience dealing with systems on the low level, and can be switched around to different tasks with different amounts of required technical expertise. There are many different tasks in programming a game.

You may join as a scripter and only ever write lua/C#/java/python/etc scripts. However, when that task is complete, it's nice to be able to do other things, or you will become redundant when they don't need anymore of those scripts written.

C++ deals with the machine at a very low level. It's easy for a C++ programmer to jump into any higher level language and be somewhat productive immediately. Because it's all the same concepts, but you don't have to be as specific, and don't have to manage memory. It's harder for a someone without C++ knowledge to jump into C++ because you suddenly have to know how to think in terms of memory management and being specific.

I never said not to learn C++. I said it's not required to make a good, fast, game, and certainly not desirable to find a C++ only engine. You can use an engine and create tons of successful games without ever needing to write a single line of C++.


#5041798 Existing 3D Game Engine for Gameplay Programming

Posted by MrDaaark on 11 March 2013 - 05:26 AM

royibernthal, on 11 Mar 2013 - 05:57, said:
I see. Wouldn't big systems like inventory, quests and such be better off programmed in C++ rather than scripted?

This sentence doesn't make very much sense.

There is no distinction between programming and scripting that needs to be made. Scripting is only used as a context to describe the programming where you tell an existing program what to do, instead of the programming that is done to make the actual program in the first place. This allows a program to be small and fast, and just describe some basic object models. After that, it's handed off to the user to create scripting data to tell it how to behave.

Gameplay interactions have no business being in the engine code in the first place. The engine has it's own single area of responsibility. It manages memory, takes input, checks for collisions, draws the screen from a list of visible objects, etc. It doesn't need to know or care about your inventory system, or what a quest is, because they have nothing to do with it's job.

For instance, the engine has defined generic game objects, and triggers. It has events for when an object enters and exits a trigger. The user of the engine can hook into these events with a script.

The user can now write a script to define what happens when an object enters or exits a trigger area. The possibilities are almost endless, and any type of action can now occur without having to change the actual engine program.

The script becomes content, and can be loaded, swapped for new ones, and possibly modified on the fly. They will get trashed like any other data when they are not needed anymore.

Scripts are mostly safe, and usually will just be halted with an error message instead of crashing the whole program. Usually you just get bad behavior that you can isolate and fix quickly, and then you don't have to recompile your whole program. The script is just a file in a folder. No different than altering a texture or a sound.

If your inventory and quest systems are big and complicated, then you doing them wrong.

An inventory is a just a list of some custom data structure with a few functions to manage that list. When it comes time to draw the inventory, you just tell the GUI skin you customized what items to draw in what slots, and the engine takes care of adding it's standardized GUI with the correct image references to the render queue.

What if you don't want that? Tell the engine to draw your inventory items dangling from your belt by making one call to add the model to the scene graph.

What if you don't want that either? Tell the engine to draw a floating model of your inventory object on the top corner of the screen.

etc...etc...


#5041725 Existing 3D Game Engine for Gameplay Programming

Posted by MrDaaark on 11 March 2013 - 12:00 AM

Why make poor decisions because of stupid, self imposed rules?

C++ is used for the system level code, and scripting engines and VMs are used for the actual game logic. This isn't slow. This has been done going all the way back to the 80s. Game logic is just content.

That's why engines like Unity3D and Unreal don't give C++ access. Because that part of the job is already done. The things that you would have written in c++ instead of the scripting language are already written and working.


#5040859 Would DRM be bad for this game?

Posted by MrDaaark on 08 March 2013 - 10:20 AM

Basically what I'm trying to ask is if DRM is ALWAYS a terrible thing in the eyes of gamers

It is in my eyes.

I don't agree with the concept of having to ask someone else to use something I pay for. I am a legitimate, paying customer, and I get bit by faulty or ill conceived DRM checks all the time. There have been a few recent cases of massive DRM failures with EA and I believe UBISoft.

Half my downloaded games on PSN deny me the ability to play them every time PSN goes down for maintenance, which is a few times a week. Capcom's DRM servers rely on PSN being up. It's fun coming home from work and trying to play the game I just bought, only to be told 'I'm unautorized' because Sony needs from tuesday at 9am to thursday at noon to fix their network again.

I can't use half my android software as soon as I leave wi-fi range. Most tablets sold at retail do not have any connectivity beyond wi-fi unless you spend an extra 50$ to get a 3/4g model, or you get one from a cell phone store.

I have a star charting app that wouldn't run (online check seems to have been patched out recently) when I'm not home. Yes, you read that right. An app made to use outside on a portable device that won't run because you're outside.

It's fun paying 20$ for an a tablet game, and then being told I have an unauthorized copy because I went one step too far in my backyard. Square-Soft "allows" me to run FF3 a random number of times with failed wi-fi check. Which means when I run it on my way home I have to pray that it works, and then remember to run it once when I get home to restart my failed wifi check counter, or I'm out of luck the next day? I would have no problem with the wi-fi check if it happened once during the initial install.

Why am I being treated like this? Over the course of my life, I've spent near 1,000$ on Square-Enix products. I (and others like me) am the reason these idiots denying me the use of MY game even have a job right now. If it wasn't for the support of their paying audience, there wouldn't be a Square-Enix. Same goes for any other software company. They are privileged to have our business. They are not entitled to it.

So now when FF4 on android comes out soon, my potential purchase comes with a list of conditions in an e-mail. I politely state my support over the decades, going all the way back to their first release until now, and all the problems they have given me trying to use and enjoy the software I have have bought from them. And that if current practices continue, we will have to unfortunately end our business relationship.

This stuff has gotten out of control, and these guys have forgotten how the relationship works. These companies make products that no one needs, and they are asking us for our money and support. They are lucky when and if they get that support, and they are entirely reliant on the customer for their continued existence.

The only model I support anymore is 'I buy it. I own it.' The GOG.com model.
If you think you're going to tell me how, when, why, or on what machine I can run something on, you're not getting my money.
If you think you're going to install something else that will watch me, or 'manage' something, you're not getting my money.
If you think I'm going to ask permission to run use your product, you're not getting my money.

Thankfully, most of the e-book world now agrees with the above. I'll be happy when the gaming world catches on.

Also, I know I didn't touch on piracy, because I don't care. I know it's a real problem, but it's not MY problem to deal with. You either treat me like a proper customer, or I'll go do business with someone else that does. I don't call up Home Deport and ask them permission to sit on my own toilet just because other people are stealing toilet seats, or stealing water service. I also don't let the grocery store send an employee over to check up on the eggs I bought from them. It's no less ridiculous when a software company does it.


#5040828 Best way to create full screen, 320x240 surface, no anti-aliasing?

Posted by MrDaaark on 08 March 2013 - 08:35 AM

Draw onto a 320x240 texture, then draw that texture as your screen. The only way to keep it sharp is to scale it at an even ratio (2x,4x, etc..), and use the NEAREST/POINT filtering mode.

But we don't have square screens anymore. You'd have to center it over a background image, or use a 16:9 or 16:10 resolution in the original image. Such as 320x180 (16:9).


#5039647 Can't decide which math/physics basics book to get

Posted by MrDaaark on 05 March 2013 - 01:11 PM

If you think Mathematics for 3D Game Programming and Computer Graphics is too advanced for you, (or at least too fast on the basic) you should take Practical Linear Algebra: A Geometry Toolbox.

You could also attend the Khan Academy, in th elikely case that he doesn't have a 10,000$ book budget.

https://www.khanacademy.org/math/algebra


#5038962 Can't decide which math/physics basics book to get

Posted by MrDaaark on 04 March 2013 - 01:50 AM

It was on your list? You mention 2 books in your post. That wasn't one of them.

You don't need to worry about 2D vs 3D. There isn't a new type of math for every dimension. A 2D collision check is the same as a 3D one minus one dimension.

I only have the second addition, but it starts at points, then vectors, matrices, volumes, collision detection (of every type), collision response, physics, graphical techniques (like polygon reduction), ocean simulation, and then it ends with a bunch of small chapters on general purpose techniques that are good to know. Third addition has more.

If a chapter looks short, it's because the book isn't full of source code. It explains concepts and shows formulas.

It's all general purpose knowledge.


#5038948 Can't decide which math/physics basics book to get

Posted by MrDaaark on 04 March 2013 - 12:48 AM

Mathematics for 3D Game Programming and Computer Graphics is not on your list, but I own it and think it's excellent. It has chapters on everything from simple topics to advanced, and will function as permanent reference material when you are done reading it.


#5038931 Is a mesh a 3d model?

Posted by MrDaaark on 03 March 2013 - 10:27 PM

I'll just re-enforce the above with an image I posted the other day to ScreenshotSaturday

http://screenshotsaturday.com/images/directlink_BET1gACCEAEYrua.jpg

I have a 3D object called DummyRig. It consists of a world position, a rotation, and a scale. You can call it a model, but a 3D object doesn't have to be. It could be a light, a particle system, a marker, a target.

It references a MESH data block, which is the green man you see. As stated above, this is vertex, edge, polygon, etc data.

The mesh references a material called 'vertex colors' which tells the renderer to use the vertex colors in the mesh data to color the model.

The mesh also references a skeleton (seen in stick form in the image above), which will tell it how to deform. The skeleton refers to the mesh data in the form of vertex groups, which is list for each bone of which vertices they will affect. A vertex in the mesh can belong to more than 1 vertex group.


#5038621 PS3 games in C++..

Posted by MrDaaark on 02 March 2013 - 09:28 PM

People don't mention homebrew because it's a waste of time, and contrary to what most people want. People don't want to work on things that have an effective audience of 0.

There is no real homebrew scene. It's all people who broke their consoles, porting over other people's code bases (quake 2 on my xbox!? Who cares?!?!"), or writing tic tac toe games you can download, burn and run. They aren't worth the cost of the disc! There are no real tools, no real support, and it doesn't get anyone any closer to their original goal of making a proper game.

That scene is mostly just one of many crutches for people who say they are making a game, but are really just screwing around. Just like half the people I follow on Twitter in my gamedev list who are supposedly working on games, but really they are just switching APIs every week, or rewriting things over and over that solve problems they weren't actually having, all to mask that they have no creativity, and they always get stuck at step 1 of actually making their games.


#5038570 Best way to learn game programming

Posted by MrDaaark on 02 March 2013 - 05:40 PM

You can't ever skip further along ahead, because everything will build on those concepts. The advanced things are all things you invent! Every programming language is just a bunch of simple keywords and build in utility functions. From there it's up to you to combine them into whatever you need.

More advanced programming talk will end up dealing with concepts instead of actual code.


#5038403 Do I learn the skills I need then make the game, or do I work on the game, an...

Posted by MrDaaark on 02 March 2013 - 06:38 AM

You need to know the basics of your language before you start anything, otherwise you can't even begin to design, because you don't even know what tools are available to you or how they work. Once you learn enough of the basics, you will start to understand how to mix and match them to make your ideas work.

You do not have to memorize anything. When you need something, it's there to look up.




PARTNERS