Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MorphingDragon

macrumors 603
Original poster
Mar 27, 2009
5,159
6
The World Inbetween
I've been going through my head and umm,

Lets say I had a level design in a PNG format thats so many pixels long and tall. This level has floors and barriers. Representing these by a grid would be complicated and limited in ability, so what if I determined the clipping through vector/graph functions?

Lets say I have a level with a slope.


Y
|
0_______________ X
|-------------------B\
----------------------\
-----------------------\
------------------------\________________________
A

So have select case statements with X as the subject. And there are pre determined points accross the X Axis. The variables are X, Y, A, B and Velocity.

So

(Pseudo Code)
select x

case >= 0 && < B then
y = 1

case >= B && < A then
y = -2X (or Something

etc

Now I have a character in a box thats 200x200px and the movement animations are limited to within this box. Whose point of 'solidity' is in the bottom-middle.

So if X == objectInPath
velocity = 0

B, A would really be put into an array for easier coding and less memory usage.
I can see one possible glitch is that a wrong placement for the greater than signs might cause the character to float in mid air. But the effect should be negated once the character moves another pixel due to the nature of the graphing equations? This method wouldn't allow any multi-level story designs without more if statements to determine what pixel amount counts as a story.

Comments please?
 
So you're basically talking about representing the landscape as a piecewise linear function?

Not a bad idea, but actually creating such a landscape (i.e. figuring out all the coefficients for each segment) will soon get quite cumbersome unless you automate it with a tool.

Instead, if your terrain is defined as a one-dimensional heightmap, with points at equal intervals horizontally, you can use linear interpolation to find the appropriate Y coordinate on the terrain for a given X coordinate. (You could even use other interpolation functions if you want to get curvy.)
 
So you're basically talking about representing the landscape as a piecewise linear function?

Not a bad idea, but actually creating such a landscape (i.e. figuring out all the coefficients for each segment) will soon get quite cumbersome unless you automate it with a tool.

I could design the level with Illustrator and use an Illustrator script to dump the peices into a text file. Then write some code to dump the peice coordanates into an array. This could allow dynamic level loading with less code. I don't know illustrator scripting though so I would have to learn it.

This way also would let me take advantage of basic polynomials and calculus funtions, for a curved surface easily.

To overcome the the story issue, I could define in the level design how many pixels classed as a story. Then write a basic if statement to redefine the origin of the graph.

Instead, if your terrain is defined as a one-dimensional heightmap, with points at equal intervals horizontally, you can use linear interpolation to find the appropriate Y coordinate on the terrain for a given X coordinate. (You could even use other interpolation functions if you want to get curvy.)

I could, I would have to experiment see which one I can implement easier.
 
The way you're talking, it sounds like you expect to code levels as compiled C code (or Obj-C, or C++, anyway some compiled native code). This isn't always a good idea.

First, it means any levels require a full rebuild. Unless your main engine is able to load plugins. In which case every level has to be a plugin. Which means you have to manage plugins, which isn't the easiest thing to do, because it involves dynamically loading external code, initializing it, and possibly unloading it (which has even more potential for bugs).

Second, it means any bugs in a level must be debugged using the native debugger. On a dynamically loaded plug-in. Which ain't easy.

Third, it means any user-created levels have to be compiled as native code. That's only complex for users, most of whom have no idea how to use Xcode, nor would they want to learn. It also means your game engine (i.e. the app hosting the level plugins) has no way to verify the trustworthiness of any of the plugins, because every function available to any C programmer can be used in writing the level. That's a pretty big Pandora's Box whose contents you have to keep track of.

One way this is usually done is with data representing levels (or even characters), and that data is simply interpreted by the game engine. The expressive power of the data can be limited and constrained by the engine, so nothing can happen unless the interpreting engine allows it.
 
The way you're talking, it sounds like you expect to code levels as compiled C code (or Obj-C, or C++, anyway some compiled native code). This isn't always a good idea.

First, it means any levels require a full rebuild. Unless your main engine is able to load plugins. In which case every level has to be a plugin. Which means you have to manage plugins, which isn't the easiest thing to do, because it involves dynamically loading external code, initializing it, and possibly unloading it (which has even more potential for bugs).

Second, it means any bugs in a level must be debugged using the native debugger. On a dynamically loaded plug-in. Which ain't easy.

Third, it means any user-created levels have to be compiled as native code. That's only complex for users, most of whom have no idea how to use Xcode, nor would they want to learn. It also means your game engine (i.e. the app hosting the level plugins) has no way to verify the trustworthiness of any of the plugins, because every function available to any C programmer can be used in writing the level. That's a pretty big Pandora's Box whose contents you have to keep track of.

One way this is usually done is with data representing levels (or even characters), and that data is simply interpreted by the game engine. The expressive power of the data can be limited and constrained by the engine, so nothing can happen unless the interpreting engine allows it.

Who says I'm Using a premade game engine?

I plan to leverage Cocoa's features and make my own "Engine". My friend is going to take me thorugh the ropes of Quartz Composer once he gets back from Australia. Why bother learning some more arbritary engine code when I already have the skills/utilities to execute it at an OS level.
 
Why bother learning some more arbritary engine code when I already have the skills/utilities to execute it at an OS level.

Maybe you should ask this question to any company who owns or licenses a game engine?

If your goal is to write a high-quality game at the smallest cost possible, a game engine makes good business sense. If you are interested in teaching yourself how to do it, then building your own engine is a great idea.
 
Who says I'm Using a premade game engine?

You did. Not me. Reread what I wrote. Nowhere did I say "premade" or even suggest how the game engine came to be. I've made several game engines before, starting when Macs with two floppy drives were considered serious game rigs. Not every game shipped, and half the platforms are now dead, but that's the breaks.
 
Re: Can I bounce some ideas off people?

Stop throwing things at me already. :(
 
Maybe you should ask this question to any company who owns or licenses a game engine?

If your goal is to write a high-quality game at the smallest cost possible, a game engine makes good business sense. If you are interested in teaching yourself how to do it, then building your own engine is a great idea.

Well the point of this is to make me learn the 2D features of Cocoa. I can't just use examples out of a book. I have to do a real world project/example. Its just how I learn, and why I fail miserably at theory only subjects. At the end of the Steve Kochan Obj-C part 1, I made a Tax program, for example. I'm still going thorugh the foundation part of the book but because I have to do 4 prepatory papers at Univeristy I have more time than I thought I would. This might be jumping the Gun as Im not even on to my Cocoa book but this is something I just had to write down and process.

Yea I can understand using a premade game engine for a large project. But this is neither a large project or likely to make me money.
 
You did. Not me. Reread what I wrote. Nowhere did I say "premade" or even suggest how the game engine came to be. I've made several game engines before, starting when Macs with two floppy drives were considered serious game rigs. Not every game shipped, and half the platforms are now dead, but that's the breaks.

Sorry I didn't read your post properley.

I haven't slept in 24 hours...

I was an Orientation party and somebody put party pills in or something...

I'm still slightly on edge but hoping that I can sleep by midnight.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.