XCode OpenGL Game Engine

Member
Posts: 312
Joined: 2006.10
Post: #16
Also, as you learn OpenGL you will have a much better idea of what needs to go into a renderer of a game engine.

I'd suggest focus on making a game, and through that you will build reusable code that will help you eventually create an engine. The code may be bad, but it will lend it's self to writing the same code, but only better.
Quote this message in a reply
Member
Posts: 715
Joined: 2003.04
Post: #17
bronxbomber92 Wrote:I'd suggest focus on making a game, and through that you will build reusable code that will help you eventually create an engine. The code may be bad, but it will lend it's self to writing the same code, but only better.

The suggestion above and the screen shot you provided is how iGame3D started.
From my end all I was capable of was making a .nib file that looked a lot like yours, that and making near limitless number of "cool engine" suggestions.
Here's an embarrassing reference to those simpler times

Trying to get through the Xcode tutorials put me to sleep time after time, my background was commercial graphics, and playing with cool level editors from games like Tomb Raider and Myth, which were fun. Xcode tutorials are not fun.

I came to iDevgames with less of a clue and even loftier goals than yourself, and was told "if you want it, write it yourself." To give you an idea of what I was fantasizing, just look at Unity, they made my dreams a reality. Some said it could never be done, and if it was done, nobody would buy or use it, ha!

Then I read a post here on iDevgames titled "Check out my engine", written by a sixteen year old kid who was extending a 'game' (term used loosely) he'd made for the uDevGames competition several months earlier. The code was awful, the 'game engine' was primitive (an understatement). But hey, the kid knew his C pretty well and so we moved forward from there step by step, volume after volume of books and documentation, feature after feature, facing more bugs than a bait store.

Six years later now and we are still at it. Life likes to get in the way, from school, whining children, screaming wives, buying houses, traveling around the globe, rushing deadlines for contests, you name it, interference to the great work comes from every angle. Starting from near scratch several times is also a possibility you are going to face as we have.

Another angle to consider in building an "engine" is that you have to document every single function and feature, best to keep a living document of that as you go along. I've had to start documentation from scratch a few times, our first big mistake was creating our own scripting language, 125 keywords created and documented, then thrown out the window, it was fun and often hilarious to do that but not the best course of action.

Whatever you do while writing an engine, don't attempt to write a full featured 3D modeling and animation app with particle effects and movie rendering in the process, ouch, that cost me at least three years of interface design, troubleshooting, and coming up with features that I could have had with a two minute internet purchase of low cost software.

Also choose a good free text editor and established scripting language that is supported by the software. Smultron or Editra for Lua is what we are using, after I spent probably a year or more trying to write such a beast myself.

A feature your engine will need is a method to collect and package assets for distribution, else you'll find yourself weeding out a thousand experimental levels and files every time you want to post your work for testing. You might want to try developing this earlier than your OpenGL wonder toy.

Another issue you will face is having people say "Hey I want to help", and completely vanishing from the face of the earth (or interweb) between the time you read their email and reply. Good (ie, free) help is really hard to find, sometimes you get lucky, like me, I couldn't have done any of this if I hadn't hooked up with someone dedicated to building their skills. In the same vein I can't imagine where he'd be now if I hadn't jumped on board and been available to encourage, suggest, test, and take on several responsibilities like UI design, documentation, promotion, paying hosting fees, etc.

On that note, promote and test your work often, no matter how embarrassing and primitive it is, or how awful the feedback is. I remember some really harsh private reviews of Unity when they were still working out their kinks and before they went fully commercial, it never stopped them.

What other advise do I have from the front lines of engine design? Hmm.
Start really small before going into full fledged UI design and über application programming. To give you an idea iGame3D started with "walk around an ultra low poly 3D world, shoot things, they scream, they die".

Support a standard 3D format, decide very early on if you will need animation support or if you will be shooting at static targets (like a spaceship).
Don't go to full screen for early testing, its impossible to see errors in the console when you are in full screen. The last thing you want to do is hard reboot because you've locked yourself out of your system while erasing all your memory due to a simple typo in your code and you can't see the 20,000 "malloc" errors scrolling along.

Study other engines, often. A couple of others I forgot earlier:
StarLogo from MIT.
Alice from Carnegie Mellon University
Playkode from biggerplanet (hey Nathan whats news?!)

Oh and one last suggestion of the day, just for the OSC types.
Be aware of strangers with case sensitive formatted hard drives.
Do_Some_Function("Spaceship.obj") will crash your app if it is run from
these drives and your model is really called "spaceship.obj".
This shouldn't be an issue if your scripts are generated and modified from your
interface using existing models, instead of say just typing in a model name into a text file in the wee hours of the morning.

Ok good luck, hope this helped some and you can keep your enthusiasm piqued for the years it will take to master the art of game engine design.
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2008.08
Post: #18
igame3d Wrote:The suggestion above and the screen shot you provided is how iGame3D started.
From my end all I was capable of was making a .nib file that looked a lot like yours, that and making near limitless number of "cool engine" suggestions.
Here's an embarrassing reference to those simpler times

Trying to get through the Xcode tutorials put me to sleep time after time, my background was commercial graphics, and playing with cool level editors from games like Tomb Raider and Myth, which were fun. Xcode tutorials are not fun.

I came to iDevgames with less of a clue and even loftier goals than yourself, and was told "if you want it, write it yourself." To give you an idea of what I was fantasizing, just look at Unity, they made my dreams a reality. Some said it could never be done, and if it was done, nobody would buy or use it, ha!

Then I read a post here on iDevgames titled "Check out my engine", written by a sixteen year old kid who was extending a 'game' (term used loosely) he'd made for the uDevGames competition several months earlier. The code was awful, the 'game engine' was primitive (an understatement). But hey, the kid knew his C pretty well and so we moved forward from there step by step, volume after volume of books and documentation, feature after feature, facing more bugs than a bait store.

Six years later now and we are still at it. Life likes to get in the way, from school, whining children, screaming wives, buying houses, traveling around the globe, rushing deadlines for contests, you name it, interference to the great work comes from every angle. Starting from near scratch several times is also a possibility you are going to face as we have.

Another angle to consider in building an "engine" is that you have to document every single function and feature, best to keep a living document of that as you go along. I've had to start documentation from scratch a few times, our first big mistake was creating our own scripting language, 125 keywords created and documented, then thrown out the window, it was fun and often hilarious to do that but not the best course of action.

Whatever you do while writing an engine, don't attempt to write a full featured 3D modeling and animation app with particle effects and movie rendering in the process, ouch, that cost me at least three years of interface design, troubleshooting, and coming up with features that I could have had with a two minute internet purchase of low cost software.

Also choose a good free text editor and established scripting language that is supported by the software. Smultron or Editra for Lua is what we are using, after I spent probably a year or more trying to write such a beast myself.

A feature your engine will need is a method to collect and package assets for distribution, else you'll find yourself weeding out a thousand experimental levels and files every time you want to post your work for testing. You might want to try developing this earlier than your OpenGL wonder toy.

Another issue you will face is having people say "Hey I want to help", and completely vanishing from the face of the earth (or interweb) between the time you read their email and reply. Good (ie, free) help is really hard to find, sometimes you get lucky, like me, I couldn't have done any of this if I hadn't hooked up with someone dedicated to building their skills. In the same vein I can't imagine where he'd be now if I hadn't jumped on board and been available to encourage, suggest, test, and take on several responsibilities like UI design, documentation, promotion, paying hosting fees, etc.

On that note, promote and test your work often, no matter how embarrassing and primitive it is, or how awful the feedback is. I remember some really harsh private reviews of Unity when they were still working out their kinks and before they went fully commercial, it never stopped them.

What other advise do I have from the front lines of engine design? Hmm.
Start really small before going into full fledged UI design and über application programming. To give you an idea iGame3D started with "walk around an ultra low poly 3D world, shoot things, they scream, they die".

Support a standard 3D format, decide very early on if you will need animation support or if you will be shooting at static targets (like a spaceship).
Don't go to full screen for early testing, its impossible to see errors in the console when you are in full screen. The last thing you want to do is hard reboot because you've locked yourself out of your system while erasing all your memory due to a simple typo in your code and you can't see the 20,000 "malloc" errors scrolling along.

Study other engines, often. A couple of others I forgot earlier:
StarLogo from MIT.
Alice from Carnegie Mellon University
Playkode from biggerplanet (hey Nathan whats news?!)

Oh and one last suggestion of the day, just for the OSC types.
Be aware of strangers with case sensitive formatted hard drives.
Do_Some_Function("Spaceship.obj") will crash your app if it is run from
these drives and your model is really called "spaceship.obj".
This shouldn't be an issue if your scripts are generated and modified from your
interface using existing models, instead of say just typing in a model name into a text file in the wee hours of the morning.

Ok good luck, hope this helped some and you can keep your enthusiasm piqued for the years it will take to master the art of game engine design.

Well see this morning I thought about this, Im going to instead work on other engines(particle, A.I, Physics, graphics) and get those done then when I feel pretty good about those engines, I'll start putting them together to form my game engine.
But one more question.... could the OpenGL graphics match that of the PS3 or 360?
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #19
MoltenWhale Wrote:... But one more question.... could the OpenGL graphics match that of the PS3 or 360?

On the vast majority of Macs (and Windows PCs): NO

On some machines, yes. On some machines, even better than 360/PS3. It all depends on machine configuration (and software) and what you consider "matching". This would require a very complex answer if you want to know everything. Again, I can't help but think you're way ahead of yourself. Wink

BTW, if you are interested in developing the for the Xbox 360 you can check out XNA. It's not Mac, but it's pretty darn cool!
Quote this message in a reply
Member
Posts: 715
Joined: 2003.04
Post: #20
AnotherJake Wrote:On the vast majority of Macs (and Windows PCs): NO

BTW, if you are interested in developing the for the Xbox 360 you can check out XNA. It's not Mac, but it's pretty darn cool!

What AJ said. Here's the xbox 360 system spec and PS3 system spec, so generally if your target Mac is 3.6 Gigahertz with 256 Megs of Video Memory, and you have the $4 million dollars and 50 man team of an average dirt poor Xbox 360 / PS3 video game dev team, with an average four years to spend developing your game engine, yeah sure, should look and play great for the 10,000 or so Mac users with the comparable equipment, of which only 1% might ever even run your engine (because their $4,000 Mac is used for professional work and not games).

On my 2 Ghz Imac with its 256 Meg video memory...no.
Halo which is six years old now, plays awesome on an Xbox, still stutters something terrible with full settings on this Mac. Quake 4 ran smooth as silk on a 360, (even if dead things float in air) played like complete garbage on this Mac. Tomb Raider Anniversary was unplayable on this Mac, but a year ago I was enjoying its wonderful hours of beautiful adventure on a lowly PS2!

I agree, you are getting way ahead of yourself. Before you worry about how well the graphics look you will have months of tweeking out how the graphics even get on the screen, loading model formats, getting sounds to play, getting physics to work, making animation happen, getting a game beyond pong to function as an actual game.

Put it this way, iGame3D, Dim3, Unity, and Torque are all separate engines, still in development, and all three have taken more than six years of work, and each engine was started by a programmer with at least five years of some kind of programming experience on the table. You are starting at day zero, you've got a lot of work ahead of you to catch up.

XNA, has the benefit of having books available to guide you, so if you have a dual booting Mac and like the world of Windows its something worth looking into.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #21
igame3d Wrote:Halo which is six years old now, plays awesome on an Xbox, still stutters something terrible with full settings on this Mac. Quake 4 ran smooth as silk on a 360, (even if dead things float in air) played like complete garbage on this Mac. Tomb Raider Anniversary was unplayable on this Mac, but a year ago I was enjoying its wonderful hours of beautiful adventure on a lowly PS2!

There's a reasonable possibility that the slowness is more the developers' fault than the hardware's fault. Ported games often lack the proper Mac-specific tweaks and optimizations to make them perform their best on the platform.

Sometimes it's the other way around, though... World of Warcraft apparently runs significantly faster on the Mac than on Windows.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Some Game / Engine Source code in C++ and MSVC kiavash2k 1 5,375 Apr 12, 2012 11:35 PM
Last Post: DJyStyler
  artificial intelligence engine for game like sherlock holmes sefiroths 3 6,230 Feb 26, 2011 12:15 PM
Last Post: Macmenace
  OpenGL Velocity and Grouping of Lines (C++, Xcode) TheThirdL3g 2 3,516 Jul 29, 2010 01:28 PM
Last Post: SethWillits
  What engine to choose for bowling-like game? Sergnsk 2 3,520 Jan 30, 2010 11:53 AM
Last Post: mikey
  Easy game engine for Mac OS X YvanSoftware 7 11,558 Dec 17, 2009 03:04 PM
Last Post: SethWillits