PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Glitteroutlaw on April 11, 2011, 01:32:10 PM
-
question for you that are somewhat expirenced... would somoen with huge math troubles be able to make it as a game developer? its whats kept me from trying to go to any school
Wrestling and video games are my passion and sicne im not a body builder this seems to be my only hope... i know maybe this is the place for this but though id ask.
-
If you can do basic math, then you can make some kinds of old school games. :) Don't try to get into 3D game making though... you need a good firm grasp of trigonometry for that. If you plan on making a living out of game development, you're probably not going to get very far unless you're simply doing non-programmer game design... and in that case, you need to be the best of the best.
-
yikes.... doing some retro games would be coool tho... i dont think id waste a college on that but... ugh... i dunno...
-
Maybe try your hand at Android development? The SDK is fairly easy to set up, and there are tutorials aplenty. If
-
Yeah, Android is pretty easy if you're not already used to procedural coding. :)
-
i havent tried programming sicne Hypercard so if yourt old and had a mac you know how long its been haha....
i always wnated to get in the field cuz i love video games and didnt knwo what else to do with a career so ya... lol.
-
You don't need math. It helps, but you really don't need it. I know plenty of great coders that couldn't solve for X to save their lives on simple algebra 2 concepts.
There are plenty of things you can do that aren't mathematical as far as programming goes. Menus and other interfaces require simple math (counting, etc.). Dialogue, character systems, things like that... they require more elementary school math.
As far as 3D gaming goes, you really only need math for physics relating stuff, including movement... but usually engines these days take care of that for you. A buddy of mine did an entire game with the Quake 2 engine, and he's not exactly a math genius. You'd be surprised how much the engine does for you. Plus you can trial and error stuff if you aren't sure. If you shoot a gun for example, and the bullet shoots straight up in the air, or goes backwards....... adjust values until it works. It may take you longer, but it isn't a permanent roadblock.
As far as old consoles, etc. go... You need basic math yet again, and simple geometry concepts.
If you aren't pro at geometry, I wouldn't sweat it. You really could go get like a "how to learn geometry in 20 minutes on the toilet" book, and get the basics enough to where you can put it into effect.
The BIG kicker is to get a firm understanding of hexadecimal and binary. Knowing how to perform bit manipulation is very important stuff. Even that stuff is easy to pickup on. Most "how to program books" for nearly any old processor go over this stuff. The Z80 one by Rodney Zaks did a nice job from what I remember.
-
Wow, hypercard, eh? I haven't heard of that in years...
My 2 cents:
As a former software developer -- of simple internet apps, not games (this is a key distinguishment) -- I couldn't recall many instances where advanced math was needed. I only did it for a year, but only in one instance where I used anything beyond basic math.
BUT, there are some other factors. I worked in a small company with about 8 developers, and some of the best ones out of the lot were math majors in school. It's not that you need math to make good programs, but I found those folks who were good in math also had the skills to be good in programming with using overall logic in step-by-step instructions.
-
Understand math is a good idea for programming considering the entire computer operates using math...
At the lowest level, is a bunch of circuit logic. Its all Ands/ors/XORs, etc. Its like discrete math, applied.
So if you are good at math/logic/problem solving, most computer programming things are simple.
-
Here's the thing... for business software and high-level development you don't need to know much math. Some logic and awareness of basic algorithms is really helpful, but you can make software that works. In those cases you tend to be programming things that aren't particularly tasking to the computer and aren't overly complex. They just shuffle things around a bit and help people manage data.
When you're programming games, especially on low-end hardware which use low-level languages which are closer to the hardware and have fewer accommodations for "modern" programming languages and conventions, math becomes more important. Again, a great deal of it's advanced logic and algorithms, but you also need to do some actual math if you want any kind of performance, and computer math at that. It's hard to be a good retro console developer, because the skills are so different from stuff like, well, Hypercard and Java and JavaScript and PHP and whatnot.
If your game idea is simple enough (think retro arcade style games) you can get by, even on the PCE, without much hard math, as long as you're meticulous and careful. Look at what Arkhan's doing. None of it tasks the system overly much in special effects and crazy coding, but through careful construction and attention to detail it looks and sounds good and plays well to boot. And I doubt he's getting overly down and dirty with assembly, but I think he's picking game designs carefully so that he doesn't have to. (Arkhan, correct me if I'm wrong or accidentally insulting your efforts.) But you'll not be able to create the next Gate of Thunder or Street Fighter 2 using the community tools (most likely) and without really good math and low-level programming skills. Maybe an RPG, though. That's mostly about memory management, frankly. It's just that it takes so much writing and art development. So an RPG could be doable without too much math, at least not advanced math.
-
When you're programming games....math becomes more important.
Not really. Being able to logically develope ideas is much more important. You can usually look up the math
formulae if you really need to.
If your game idea is simple enough (think retro arcade style games) you can get by, even on the PCE, without much hard math...Look at what Arkhan's doing. None of it tasks the system overly much in special effects and crazy coding, but through careful construction and attention to detail it looks and sounds good and plays well to boot/
Well, thats pretty much true of any game, really. Attention to detail is mucho important in any kind of programming.
And I doubt he's getting overly down and dirty with assembly.
Consider yourself corrected. Some things just have to be done in assembly to get the required speed. BUT, if you have it working (albeit slowly) in some higher level language, it's pretty easy to convert to assembly. Really.
But you'll not be able to create the next Gate of Thunder or Street Fighter 2 using the community tools (most likely) and without really good math and low-level programming skills. Maybe an RPG, though. That's mostly about memory management, frankly. It's just that it takes so much writing and art development. So an RPG could be doable without too much math, at least not advanced math.
Actually, you probably could, if you were willing to go all assembler with magic-kit (not Huc, though). As for RPG's, they are much more complicated than you think; it's not all memory management or writing or artwork. A lot of it is being able to foresee / plan for all the possible interactions that can occur. Like I said before, math isn't that important: the ability to plan and think logically is.
I've actually had this discussion with half a dozen people, including arkhan. The point of taking all those math classes isn't so you know the math - several of my professors admitted when they needed to know something specific, they -looked it up-. The point is that solving a math problem requires you to learn how to think logically to solve the given problem. And that translates directly to programming ability. It's a shame (to me, anyway) that they don't teach basic logic outside of math classes anymore. A lot of 'educated' people I know make very simple logical mistakes without even realizing it, and then are surprised when it is pointed out to them that their conclusions are invalid, simply because they applied a logical rule incorrectly.
-
What alot of people dont notice is that 80% of the games overall presentation is graphics. when you get right down to it, Lords of Thunder and say, Gradius 1, are about the same thing. horizontal shooters with weapons/bullets/stuff going on.
The thing that sets LOT apart is the amazing graphics. No amount of programming skill can make the graphics better if they werent great to begin with. :D
Im not picking games that wont require assembly, Im just picking games from an era that was before the PCE, and as a result, not ON the pce.
There aren't many pre-crash style games for the console.
-
When you're programming games....math becomes more important.
Not really. Being able to logically develope ideas is much more important. You can usually look up the math
formulae if you really need to.
I'm not going to address everything because I think it really comes down to this point. You DO need math in that you need to understand math. You need more than logic in that you need to know what formulas or equations to seek out. People who say they don't know math well usually aren't just poor problem solvers but also don't understand well mathematical concepts and relationships. There's more to math than just logic. Sure, many great mathematicians use computers and calculators to do much of the actual calculating, but they have to understand the concepts and WHY what calculations are done WHERE. In my mind that's math. Math isn't just working problems, but understanding relationships in space. With games, much more so than, say, business software, you have to track objects and the relationships between objects. In those cases, math, in the broad sense, is necessary.
Perhaps that will clarify my point.
Also, Arkhan, I didn't mean to suggest that you were picking "easy" games or not doing any assembly, but that you probably weren't doing the whole thing in assembly and likely weren't using as much assembly as some other games might require. In a relative sense, your output is potentially lower on the assembly-per-capita scale as a side effect of your game choices.
And yes, I neglected to note that RPGs also have lots of management of variables and game conditions. But writing is also essential, because if your writing sucks your RPG sucks. Good writing can still result in a shitty RPG, but without good writing it's guaranteed to suck.
As for graphics, well, a lot of the fancy graphical tricks require, well, trickery to make work, which makes for more complex code and need for more assembly to make sure everything's clipping along at a healthy pace.
Yeah, yeah, I'm generalizing.
-
In the grand scheme of things, a lot of the fancy dancy visual effects aren't much in the programming department, and if the base artwork looks crappy, it will still look crappy. :D It mostly involves planning what you are doing.
Then there are games that don't use alot of fancy dancy nonsense and look great, like Bonk's Adventure. The most complex thing you'll see is some parallax in the background as you walk. Nothing crazy.
A majority of Insanity was rewritten in assembly. Don't let the simplistic game designs fool you. They're still a pain in the ass to write and require the same kind of fiddling that any big commercial game would've. Any action-y game requires assembly. C, especially of the HuC variety, isn't going to cut it. Slower games will be ok.
When you really get down to it, for such a simple game, there is alot of crap going on. 11 sprites (10 robots and you), 11 shots (10 robot shots and you), and possibly Otto.
and ALL of these sprites have to actively see if they are colliding with another sprite, or a wall (tile).
In the case of alot of kickass shooters, the collisions-per-frame check aren't even as high as Insanity, despite being better looking, faster paced, and better overall.
11*11 = 121 sprite vs sprite collisions (You or robots colliding with one another)
1*10 = your shot vs. 10 other shot collisions
1*10 = your shot vs 10 robots
10*1 = 10 robot shot vs. your hero collisions
10*9 = 10 robot shots vs 9 other robots (cant shoot themselves)
1*11 = Otto colliding with any other sprite
1*11 = Otto absorbing shots
1*22 = wall checks for all 22 sprites
Thats like 285 maximum collision checks per vsync and the game doesn't slow down. I might have missed one.
I can't think of many games that could be doing 285 collision checks max. Thats what happens when most games don't have enemies colliding into each other and shooting each other, on top of shooting at you.
I imagine if Blazing Lazers allowed for enemies to hit each other too, the game wouldn't be so blazing anymore, lol
Another case in point: The MSX scene. Every homebrew game is written in assembly. Save a few that were done in BASIC, that were obviously done in BASIC.
-
Alright, then. Now that I've completely unintentionally insulted Arkhan's development efforts... I still stand by my statement that an understanding of math is essential for programming games. Not so much actual doing math problems, but a solid understanding of how mathy stuff works.
-
I get what TheOldMan is saying and completely agree. Logic and problem solving are more important than knowing anything above algebra (or intro to algebra 7th grade, IIRC). But when you work with any level of math algebra or higher, you're problem solving. This direction works out and builds up that part of your brain. I highly doubt you're gonna get a quadratic equation, and need to solve the vertex and line intercepts in most programming projects. But, IMO, knowing how to reduce a more complex equation into something simpler, or expand it into simpler steps (it goes both ways). Or just looking at what's need for the equation, and set limitations so that you can further reduce steps (replacing variables with coefficients and/or putting limits on variable's value range), etc. On these old systems, there's no multiplication or division. Binary shifting is the closest you'll get. If you need (i*c)+j. And 'c' is a constant and a value of the power of 2, then you can simply shift i and add j. Like wise, if you're in a loop where i increments by a constant value, then you can reduce it down to just an add and no shift. I.e. problem solving by removing redundant operations. A lot of times, you need to come up with the limitations yourself on the higher level end, so that you can optimize for it on the lower level end.
But that's not to say just because you're not good a higher level math, that you don't possess an intuitive ability for problem solving. The mind works in mysterious ways like that. They're not mutually exclusive. But practicing/learning one (math), does helps out the other IMO. How much, depends on the person.
11*11 = 121 sprite vs sprite collisions (You or robots colliding with one another)
1*10 = your shot vs. 10 other shot collisions
1*10 = your shot vs 10 robots
10*1 = 10 robot shot vs. your hero collisions
10*9 = 10 robot shots vs 9 other robots (cant shoot themselves)
1*11 = Otto colliding with any other sprite
1*11 = Otto absorbing shots
1*22 = wall checks for all 22 sprites
That's a lot of collisions per frame.
Also, writing in assembly necessarily guarantee automatic improvement in speed (relative improvement) over some higher level language compiler. It's highly depended on the processor and it's highly dependent on how you optimize your code. But I can say this, 9 times out 10 your real optimizations are going to come from the higher level logic first, then lower level logic (cpu instructions). Optimizing the hell out of something that's poorly designed to begin with, usually doesn't net much result for the amount of work put in. The best optimizations come from thinking in both levels at once.
-
But when you work with any level of math algebra or higher, you're problem solving. This direction works out and builds up that part of your brain.
But note that this is -not- the only way to work out that part of your brain. Do some serious programming and planning, and you'll get better at it. Anything you practice you get better at (usually).
........................................................................................
But I can say this, 9 times out 10 your real optimizations are going to come from the higher level logic first, then lower level logic (cpu instructions). Optimizing the hell out of something that's poorly designed to begin with, usually doesn't net much result for the amount of work put in
I agree with this, sorta. If something is poorly designed, it's going to be hard to optimize it; hence, trying to optimize it will probably result in a cleaner design, which -can- be optimized better. I was taught a long time ago that programming means writing, and then re-writing, and then .... You get the idea. The second try is almost guaranteed to be better than the first.
As for 'real' optimizations, yeah. Major improvements are only going to come from changing the algorithm used; You're not going to get a 10-fold improvement just by moving to assembly. That's just part of optimizing.
But there are a -lot- of things that can only really be done one basic way; Take strcpy() as just a basic example. Knuth shows about 3-4 different ways of writing it when he explains pointers. But he takes the time to point out that each version will run at different speeds on different machines; those that have multiple index registers (ie, used as an array index) will run that version as fast as cpus with a single indirect register will run the pointer version; it all comes down to what the cpu can do as to which version is 'best'.
But that's not why we optimize some sections of the code. Quite simply, HuC sucks at generating anywhere -near- optimal code. And if you think that's not a problem, try writing a pc program with and without optimization using gcc. You'll quickly discover there are a -lot- of optimizations that can be performed automatically (like all of those you mentioned), that -aren't- in Huc. (And don't get me started on simple things, like function calls and parameters. Much less pointers.) A lot of the optimizing we do involves working out a relatively speedy algorithm in HuC, and then fixing the crap assembler it generates. Makes a world of difference in speed. [And don't think it's just HuC. I used to do the same thing with the earlier versions of Microsoft c.]
That's a lot of collisions per frame.
[ But I think 1 frame = 1/30 sec. If Arkhan hadn't insisted on using bounding boxes (ie, not the actual sprite sizes; it varies depending on which way you face) we could have done it in 1/60 sec. All those adds added up. No pun intended. It's one of the things I want to fix for the multi-player version :) But to be fair, is -was- his decision to make.]
-
Yeah, Insanity has alot of collisions per frame. The fact that it has no slowdown is a testament to the bamfness at Aetherbyte.
But I think 1 frame = 1/30 sec. If Arkhan hadn't insisted on using bounding boxes (ie, not the actual sprite sizes; it varies depending on which way you face) we could have done it in 1/60 sec. All those adds added up. No pun intended. It's one of the things I want to fix for the multi-player version :) But to be fair, is -was- his decision to make.]
If you used 16x16 boxes the game would be more shitty than it already is! :D
You'd collide before you get visual confirmation! :)
and Spenoza, you didn't insult anything lol. I'm sorry if I'm coming off defensive. I'm not! I'm just giving the behind the scenes stuff that most people are unaware of. Things that seem kind of plain/easy on the surface can pandoras box into a nightmare.
... like Insanity did!
More collisions than a commercial shooter! Whoops.
Also, an understanding of math only gets you so far.
See, there are programmers who program, and then there are engineers who program.
I have a buddy that has a masters in controls systems engineering. He is a mathematical god. Tons of physics, calculus, and other odd maths. You give him a math problem, he will solve it. He's reverse engineered Ultima Online to the point where hes got more money than the rest of his server combined. You will probably lose most table top games with him. He crunches numbers in his head and figures out how to pummel everybody before they even finish their turns usually.
He can't program. He openly admits it. He can f*ck with something until it does what he wants, but it will be inefficient and have "what the hell were you thinking" written all over it because he doesn't have a grasp on key good-programming concepts. He will get a problem, figure out how to solve it, get it working, and be done with it. He's not expected to be an ace at efficient programming. Hes an engineer! :)
Being able to think abstractly, planning for things to be modular (collision checks!), having tightly-knit logical processes.... that stuff is far more important. If your mathematical algorithms are the most amazing things ever, but the logic to implement them is full-retard, it won't matter. You'll bottleneck all over the place and produce tons of overhead just by being sloppy with your planning.
and, lol, pointers in HuC. Yeah right. We don't even get structs.