9 replies to this topic

[Nepomuk]

Hi everyone!

I'm new both here and to game development in general (though I do have programming experience) and a friend and I are planning to write a game engine for 2D or 2.5D Point & Click Adventures. (You know, for games like the Monkey Island or Manic Mansion series for example.) Yes, I know there are other engines out there already, some of them open source or otherwise free of charge. And yes, I know it is a big project (though smaller than, say, a 3D engine I would guess). And yes again, we do have both a game that we'll want to use this engine for and plans to incorporate it into further games, so an engine is a valid idea in this case. Plus we'll be splitting the code into a few parts anyway for different reasons.

We have a basic idea of what we'll have to do and I have browsed the Tutorials here, but what I'm trying to do is learn from other peoples experience in writing this kind of engine and I haven't been able to find anything about that so far. What I'm really looking for is a sort of rough set of instructions on what to do or tips on what I have to do in what way. Tips on how what is a good way to split the code into various bits maybe. Hints for the ingame logic. Advice on how to decide, what exactly the player clicked on. Stuff like that. The tips should ideally be language independent too, but of course there can be examples in any language that would be understandable to someone with a background in C-style and/or bash-style languages.

What I'm not looking for are

• people telling me to give up the plan or giving me reasons why it's a bad idea
  
• suggestions on what other engines to use instead of writing my own
  
• (full) code solutions to any problems

I know we'll both have to learn a lot of things for this project (including at least 2 new programming languages by the look of it) but I'm sure it will also be a very interesting experience. :happy:

So, does anyone here have experience in writing that kind of engine they would be willing to share, links that could help us or (free) book recommendations? Google gave me a disappointingly low number of useful results this time...

Thanks a lot in advance,
Nepomuk

[Reedbeta]

You might look at ScummVM, an open-source engine that can run the old LucasArts point-and-click adventures on modern computers. Looking over the source for that might give you some ideas about architecture and so forth.

You said you have programming experience, but didn't mention whether you have any 2D graphics experience; if not, that would be a good place to start. You could use SDL to jump-start your graphics development. It's not an engine, just a framework that does a lot of the common, boilerplate work of setting up a 2D graphics environment; you'll still have to write all the actual rendering and game code. SDL can also help out with getting keyboard and mouse input, and playing audio.

[TheNut]

In addition to what Reed said, Ogre is a graphical engine that has a reputable architecture (note that I never used it), so you may want to take a look at how they designed their engine. It's 3D based, but 2D = 3D - 1D, so it's not all that much different. I would recommend you look into Windows Presentation Format (WPF) to learn how to write a proper user interface API. Box2D is a popular 2D physics engine. You can learn a lot from that.

I often use my game engine for regular applications, so don't be narrow minded when developing your own. A game engine is not a game, so don't ever write logic specific for a game inside a game engine. Leave that for your game project. It's a good idea to architect and design your engine before you write any code for it.

In addition to a game engine, these days most developers build an editor around it. This enables them to easily build levels, add scripted events, manage game resources, etc. If you're building a game world, an editor is pretty much mandatory. I personally use Blender as my game editor and export the data into a format compatible with my engine. Options for you to consider.

So with those goals in mind, there is of course a lot to learn. SDL will help eliminate some of the menial tasks if you don't mind using it. Starting from the ground up will require extensive amounts of research. Start by looking at existing engines, see how they do it, take what designs you like most and incorporate it into your own.

[fireside]

There's a big difference between a 2d and 2.5 engine for adventure games. 2d is really not that big of a deal, you just move sprites around, but you do need to scale. 2.5 d is quite a big deal as you need to import the modeled characters and worry about how they blend with the background. You'll need to keep track of the exact camera position in the modeling program so it can be duplicated in the rendering process and the angles, etc, look right. Personally, I would rather go full 3d than do that, but I would just use a 3d engine if I did. With a 3rd person view you will also need to do path finding if it's a standard point and click which is really the more advanced thing you'll need to do if it's straight 2d. That and set up an inventory system.
If you do decide to do 2.5 d, I would go over to Wintermute and ask the author for some tips. He's quite a nice guy.

[Nepomuk]

Wow, quite a few points to go into... let's see.
[quote name='Reedbeta']You might look at [url=http://www.scummvm.org/]ScummVM[/url] [...]. Looking over the source for that might give you some ideas about architecture and so forth.[/QUOTE] Yes, I thought of that and even have the ScummVM code already. The problem here is of course, that there's a huge amount of code I'd have to sieve through (I count 45 directories in the "engines" folder and many of those contain over 60 separate files) and I don't even know what file to start with. For specific things it's a totally different picture of course, but for getting a general overview of what has to be done, reading other projects is possibly a bit too much. Well, I'll see.
[quote name='Reedbeta']You said you have programming experience, but didn't mention whether you have any 2D graphics experience; if not, that would be a good place to start.[/QUOTE] A good point, yes. I do have very little experience with 2D graphics so far.
[quote name='Reedbeta']You could use [url=http://www.libsdl.org/]SDL[/url] to jump-start your graphics development. [...] SDL can also help out with getting keyboard and mouse input, and playing audio.[/QUOTE] I don't know yet, whether SDL is a good choice with my requirements, but I'll try to find out. One thing we'll be using for sure is OpenGL, but I could maybe combine them... We'll see.
[quote name='TheNut']In addition to what Reed said, Ogre is a graphical engine that has a reputable architecture (note that I never used it), so you may want to take a look at how they designed their engine. It's 3D based, but 2D = 3D - 1D, so it's not all that much different.[/QUOTE] Well, here of course we have a similar problem as with ScummVM - loads of code and probably little of it that would actually help me. I imagine it's a pretty big leap going from 2D to 3D and I'd have to identify and then ignore everything that's extra. Mind you, I may be being a bit naive here, but I imagine that the sort of graphical environment I'm envisioning should be pretty simple - use a few PNGs, have some way of telling my system where my character can walk and what areas show objects or NPCs and redrawing that a few times per second. There will be little movement over all - the main character will move of course, NPCs will mostly stay put and there should be a few items that move in a very limited area.
[quote name='TheNut']I would recommend you look into Windows Presentation Format (WPF) to learn how to write a proper user interface API.[/QUOTE] I want to write a platform independent engine. WPF is .NET, which is only pseudo platform independent, so I won't be using that.
[quote name='TheNut']Box2D is a popular 2D physics engine. You can learn a lot from that.[/QUOTE] Hm, just checked that out because I had never heard of it. Not bad, but I don't think I'll have that much use for "simulat[ing] interaction and collision between moving 2D objects."
[quote name='TheNut']I often use my game engine for regular applications, so don't be narrow minded when developing your own. A game engine is not a game, so don't ever write logic specific for a game inside a game engine. Leave that for your game project.[/QUOTE] Well, the way it's planned right now, we will have 3 layers to the final game - the first one that indeed I could use for completely different projects (receive input and pass it on to the next layer, offer connections to the sound system, etc.), the second one that would prepare the basic logic (how to draw backgrounds, objects, NPCs, the player character, the existence of the inventory and interactions, capability to save & load games, ...) and a third one that will describe this specific game (the areas, objects and NPCs that are used, the choice of interactions we want to offer, the puzzles, etc.). Does that sound like a good separation?
[quote name='TheNut']It's a good idea to architect and design your engine before you write any code for it.[/QUOTE] Yes, that's the phase we're in right now. Admittedly, I have written a little bit of code, but that's more for the learning process and will probably never make it into the project.
[quote name='TheNut']In addition to a game engine, these days most developers build an editor around it. This enables them to easily build levels, add scripted events, manage game resources, etc. If you're building a game world, an editor is pretty much mandatory. I personally use Blender as my game editor and export the data into a format compatible with my engine. Options for you to consider.[/QUOTE] I've been thinking about an editor... Keep in mind of course, that I'm not going to have levels or anything like that, I'll have a certain amount of areas, puzzles and dialogues. Blender is for 3D stuff from what I understand, so I'll probably not use that. What we use in the end will probably depend on what language we choose for the 3. layer. That will probably be some script language (I'm thinking LUA or Python right now, but that's not definite yet) and we'll just see what we do with that. Maybe we'll just use VIM...
[quote name='TheNut']So with those goals in mind, there is of course a lot to learn.[/QUOTE] Absolutely! :lol:
[quote name='TheNut']SDL will help eliminate some of the menial tasks if you don't mind using it. Starting from the ground up will require extensive amounts of research. Start by looking at existing engines, see how they do it, take what designs you like most and incorporate it into your own.[/QUOTE] Sounds like good advice! :happy:
[quote name='fireside']There's a big difference between a 2d and 2.5 engine for adventure games. 2d is really not that big of a deal, you just move sprites around, but you do need to scale.[/QUOTE] Yes, that's the sort of thing I was imagining.
[quote name='fireside']2.5 d is quite a big deal as you need to import the modeled characters and worry about how they blend with the background. You'll need to keep track of the exact camera position in the modeling program so it can be duplicated in the rendering process and the angles, etc, look right.[/QUOTE] Hm, I hadn't thought of that yet... I guess it will be pure 2D then.
[quote name='fireside']That and set up an inventory system.[/QUOTE] The inventory should be relatively easy, I would think. The logic behind it is basically a list (array, vector... whatever fits the bill) of objects (combinations of a picture, a description, possible combinations with other items and maybey a state), right?
[quote name='fireside']If you do decide to do 2.5 d, I would go over to Wintermute and ask the author for some tips. He's quite a nice guy.[/QUOTE] I came across that engine while doing some research into my project, yes. The lite version is for 2D games only, so that might be worth looking at. But that's not open source, is it? I may get some tips there nevertheless of course.

OK, that's all those replies taken care of. :lol: I'd be happy to take more advice though, so if anyone has further suggestions, spit them out! ^^

Thanks a lot,
Nepomuk

EDIT: I just saw that it IS possible to download the Wintermute Lite source code, so I take that comment back.

[Reedbeta]

Nepomuk said:

I don't know yet, whether SDL is a good choice with my requirements, but I'll try to find out. One thing we'll be using for sure is OpenGL, but I could maybe combine them... We'll see.

SDL actually has built-in support for creating an OpenGL environment and is cross-platform, so it sounds like it would be a good choice based on what you've mentioned here so far.

[TheNut]

Nepomuk said:

Well, here of course we have a similar problem as with ScummVM - loads of code and probably little of it that would actually help me.

You don't have to look at the code ;) Personally I look at code as a last resort and prefer to read documentation. Ogre has some documentation you might find useful. I would focus on how they organize their classes. Get an idea of how to organize your own engine based off the experience of others. Things like how to architect your scene management, spatial partitioning, game resources, etc.

Nepomuk said:

I want to write a platform independent engine. WPF is .NET, which is only pseudo platform independent, so I won't be using that.

I'm not suggesting you use WPF, rather read up on it. It has one of the best UI architectures out there. Learn about MVC pattern, binding, and commanding. These will provide you with more design guidelines to help you out.

Nepomuk said:

Admittedly, I have written a little bit of code, but that's more for the learning process and will probably never make it into the project.

Prototyping is fine. Just make sure the prototype doesn't morph into the final version, unless you can maintain quality control in the process ;)

Nepomuk said:

Blender is for 3D stuff from what I understand, so I'll probably not use that.

Blender can do almost anything, 2D and 3D. I've used it numerous times to render 3D models into 2D sprite sheets.

Nepomuk said:

... Does that sound like a good separation?

I would say it's a start. Component design and API will be your most important issues. Keep code coupling to a minimum. One engine I worked with was built using a layered design without any focus on component design. While you could build games with the engine, it was so tightly coupled that everything had to be packaged together. Layered development is fine, just make sure you decouple components and write a facade (design pattern) to expose the API.

[Nepomuk]

Reedbeta said:

SDL actually has built-in support for creating an OpenGL environment and is cross-platform, so it sounds like it would be a good choice based on what you've mentioned here so far.

Well, I'll certainly consider it. Right now I'm trying to understand a few things about the graphics, so it may fit right in.

TheNut said:

You don't have to look at the code ;) Personally I look at code as a last resort and prefer to read documentation. Ogre has some documentation you might find useful. I would focus on how they organize their classes. Get an idea of how to organize your own engine based off the experience of others. Things like how to architect your scene management, spatial partitioning, game resources, etc.

Ah, OK. Yes, that does sound like a good idea, hadn't thought of it in that way. Thanks for the suggestion! :yes:

TheNut said:

I'm not suggesting you use WPF, rather read up on it...

OK, reading up on WPF won't hurt I guess. ^^ Whether or not it will help me I'll see once I've done that.

TheNut said:

Blender can do almost anything, 2D and 3D.

I'm still not convinced that we'll be able to really use it, but I'll check it out. Wouldn't be the first time I was surprised at how I could use a piece of software. :lol:

TheNut said:

Component design and API will be your most important issues. Keep code coupling to a minimum. [...] Layered development is fine, just make sure you decouple components and write a facade (design pattern) to expose the API.

That makes sense, especially as we'll want to be able to reuse the engine. But which alternatives could make sense? We're still quite early in the planning process, so if there are better ideas around, we could still change our minds.

It's great to be able to learn from your experience everyone, this is really helping! :) Thanks a bunch!
Nepomuk

[alphadog]

Lots of good advice above, but what you are really skirting here is that you want to properly architect an engine such that it can help you for your first and other games. (Correct me if I am wrong.)

For this, I'd think you want to get some books, ex: this one or this one (not really 2D but broaden your horizons), that overview various types of game architectures to lay down some foundational knowledge, some "big picture" and some lingo to kick-start your googling-for-details. You may want to step back also and look at general architecture and patterns. Concepts like game loops, state machines, the MVC architectural pattern (amongst others) should be familiar to you when intending to building a reusable 2D game engine.

From there, you could expand to more focused papers and online articles such as this one.

The issue with looking at existing projects is that, being a neophyte, you will not know which ones will lead to bad coding habits and bad structure. I've seen more than my fair share of poorly designed frameworks.

[Nepomuk]

alphadog said:

Lots of good advice above, but what you are really skirting here is that you want to properly architect an engine such that it can help you for your first and other games. (Correct me if I am wrong.)

That sounds about right, yes. :)

alphadog said:

For this, I'd think you want to get some books, ex: ...

Those recommendations do look good, thank you. However right now I'm a bit low on cash so if anyone has a few links with which I can get started until I have saved up enough to buy books, that would be great. :-)

alphadog said:

From there, you could expand to more focused papers and online articles such as this one.

Looks good. :-)

alphadog said:

The issue with looking at existing projects is that, being a neophyte, you will not know which ones will lead to bad coding habits and bad structure.

Yes, that makes sense. Though of course there are different views of what is a bad coding habit. :lol:

Greetings,
Nepomuk