Posted by TheTroll
on 02 September 2012 - 10:55 AM
wattywatts, there is no game engine that requires no programing, or it would already be the game you wanted just without your art. The reality is if you want the game to be your own, you need to code it to be your own.
Posted by TheTroll
on 02 September 2012 - 09:10 AM
I just thought of a fourth way, and the way that I would suggest. Use force. Instead of linking them directly, use force. Force = Gravitation Constant * mass object a * mass object b / distance between objects * distance between objects. Gravitation Constant is = 6.6726 x 10-11. That gives you the force acting equally on both objects. To get movement we use Force = Mass * Acceleration. So you take the Force / Mass and that tells you how much the object accelerates. Remember it accelerates in the direction of the other object.
If you need help with the basic code. Let me know.
Posted by TheTroll
on 02 September 2012 - 09:00 AM
Movement is always a vector, so you have a magnitude and a direction. Now you could be doing that by an x, y, z, magnitude. Since I don't know your exact code I have to just make some assumption.
There are three ways you can do this;
1. Assume they are connected by a bar, that would in most cases you just add the x, y, x magnitude change of object a to the connected object. For rotations, you would just object a as the center point of a circle and rotate it with the distance of the bar you made.
2. Assume they are connected by a rope. for magnitude changes it would be the same, for rotations, you would have to allow the object to come closer and whip around the object a. I haven't thought of exactly how to do the math.
3. Assume the are connected by a spring, this would mean object a would start to move before object b. Object b, would continue to move after object a stopped. Rotations would be a bit rope like with a delay.
There is nothing inherently evil about statics or globals. What is evil about them is letting static or global variables be changed anywhere in the code. The reason people run into problem is because they allow them to be changed anywhere. This leads to a debugging nightmare. If you have a bug you have no idea where it is coming from. So, allow the static to be read from anywhere, but only changed from one location and you will be fine.
I don't use statics that often or globals but there are times in which it is more effective and easier to read if you do.
I have never realy understood this compulsion to make games cross platform for indi groups. Windows covers just about 90% of the computer gaming market. So why put all that extra effort and time into 8% of the market for Macs and 2% for others. Why not just focus on getting the best game for the largest part of the market?
The reality is that it is easier to just define your database tables with the data you need to store, and stop trying to store "objects". If you store all the data stored by the object is not hard to create a constructor that takes that data and recreat the object at any time.
C++ is not a bad language it itself. You can do anything you want. The advantages of some of the other languages is that you can do things quicker then you could in C++. What might take 20-30 lines of code in C++ you can do in 4-6 with C#, Python or Java. So you will be doing more work to get the same end goal.
The other issue with C++ is that most languages give you enough rope to hang yourself, C++, will tie the knot and put it around your neck. There are a lot more little things that you can mess up in C++ that will cause your app to crash and many of those are fairly hard to find.
So it is up to you. If you really want to know C++, dig in and have fun, but expect that there will be days you want to toss your computer out the window.
I am going to say this is a VERY VERY idea. The reason people run things in window mode is so we can quickly do other things and then come back to the game. The "correct" way to handle this is to pause your game when the person leaves the area or is in another window.
Let me jump in on this. When I first started progamming we used punch cards. Yeah, dropping them ruined your day, well, more like days. Thne I moved on to Assembly, boy life was great, I could do in hours what took days. Then I moved to C, wow what a step up that was, then C++. (Now there was some others in the mix, but not really needed for the point). Then came along C#. So what do I use? Well for 90% of what I do it is C#, not because it is the "best" lanaguage ever, but because I can get from point A to point Q in the quickest amount of time while fullfilling the requirments that I need to get done. I still use C++, C, and Assembly for other things but C# gets the job done most of the time.
The trick is to use the right tool for the job. If you just want to put out a game, use the one that gets the game out the quickest with the least errors. If you want to dig into the guts, find the tool that works for that.
There is no "best" language, only "best" languages for the job, and even that is questionable depending the person doing the job.
C++ is a bit better at getting down the core of things.
There is very little you can do in C++ that you can not do in C++. That is why I recomended C#.
They both have things that can mess you up that you have to be careful of, like every language does. The saying goes that; "Every language gives you enough rope to hang yourself C++ just ties the knot and puts your head in the noose". That is why I suggest C#. Much better learning langauge.