Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: How can I find expertise for a game I'd like to develop?

es330td (964170) writes | more than 2 years ago

Programming 4

es330td writes "I'd like to write a program that takes the old cannon game to another level, but instead of the path being a simple parabolic arc, the projectile will move through a field of objects exerting gravitational attraction (or repulsion) and the player will have to adjust velocity and angle to find the path through the space between launch point and the target.In an ideal world, this would end up as one of these Flash based web playable games, as that would force me to fully flesh it out, debug and complete the app. I doubt this will ever be commercial, so hiring somebody doesn't make sense, and I wouldn't learn anything that way either.

I have been programming for almost 20 years, but the bulk of my work has been in corporate programming, primarily web (Cold Fusion, ASP & C#.Net,) or VB6 and then C# Windows GUI interfaces to RDBMS. I have never written a graphics based game, nor have I ever written something using the physics this will require.

Once upon a time, I could program in C but I think I would be much better off to work with someone rather than try to roll my own unless good books exist to flatten the learning curve.

Any advice on how to proceed?"

Sorry! There are no comments related to the filter you selected.

Battle Plan (1)

RobCull (1658279) | more than 2 years ago | (#39303467)

I understand exactly where you're coming from. I'm going to try to address the line, "I have never written a graphics based game, nor have I ever written something using the physics this will require."

You'll never succeed if you try designing the game in an attempt to "learn on the fly" if you have that much of a learning curve. You can learn on the fly, with a different approach however.

First lets talk about the graphics. You should try designing some basic programs which demonstrate the level of graphics control you expect the final game to have. Don't try incorporating physics yet. Maybe just design something where there is a basic projectile object which you can move around a scene with basic x/y controls. Tinker a bit. Play with it until you feel confident in doing the level of graphics control/design necessary for the final product.

Secondly, the physics. Design some programs to exemplify the physics you want to see in your final product. Naturally, this will require some sort of graphics to test, but don't make anything complex. Something simple, like use design physics to control the movements of simple points (like black dots) in a basic white region. I do this quite often, actually I normally play with the physics before I start messing with the graphics design. I've found myself testing physics code with super dirty/easy tools, such as using the physics to control mouse movements or even just using the mouse to draw in MSPAINT. If my end product needs an object moving from left to right, falling as a result of the force of gravity, I'll just have the mouse do the movements, holding left click so it draws the path. It's super effective because then you can focus on the physics without getting distracted by the testing/graphical elements. Example: I'll write some physics code in C or Java or something, write a quick class for a test run and just have it output the data (like simply time, x-position, y-position) to a .CSV file. Then, I'll have some quick autoit program use that data to control mouse movements. I've even been known to just look at it as a graph in excel (to see the movement as a trace graph), but I prefer to actually see the actions in real-time.

Once you feel comfortable with the physics and graphics, you can start writing your game without feeling like you're "flying in the dark." Remember, when you have no prior experience in something but have an aptitude towards it, practice is essential.

Re:Battle Plan (1)

mcgrew (92797) | more than 2 years ago | (#39303599)

I disagree. Save the graphics until last. Use simple shapes for the moving and stationary objects. When it's playable, then concentrate on graphics.

Oops, later you say "actually I normally play with the physics before I start messing with the graphics design" so I guess we actually agree.

I'm puzzled that he even has to ask, saying "I have been programming for almost 20 years". Writing a game like he describes would be trivial; I wrote many such games in BASIC and assembler back in the eighties; much easier than programming a complex database application in dBase or NOMAD. Maybe it's the languages he's used to.

Re:Battle Plan (1)

RobCull (1658279) | more than 2 years ago | (#39303807)

It's likely a combination of the languages he's used to, and the overall familiarity with that type of code. It's a whole different ball game writing graphics or physics versus databases or web. Even then, the physics might require mathematical knowledge that he doesn't have/is versed in presently. It normally comes down to a question of "what do I need to know" or "what questions do I need to ask."

Re:Battle Plan (1)

es330td (964170) | more than 2 years ago | (#39306349)

I'm puzzled that he even has to ask

Most of my programming world exists inside a database, specifically Microsoft's SQL Server, though I've had to work in Informix as well. I have written stored procedures in Transact SQL that ran thousands of lines that manipulate million record datasets. Outside of programs assigned in the intro programming classes I took, 99% of my code has been for interaction with a database. The last time I touched C I was trying to port the original httpd web server to run on an IBM AIX box in 1994. As a result, I know nothing about programming something that happens over time, especially in real time.

Maybe this is as simple as creating a while/for loop and building wait statements in so that it does something once every second. It just doesn't seem to me that is how real game programmers do it. What I am trying to avoid is using my limited knowledge to create a solution that turns out to be completely wrong. It seems that some research is warranted before I try to code anything.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?