next »

[desdinova]

I've been using flash, python, and more recently; Unity and C# to create little games and so far they have been really good.  I really like the fact that I can get objects interacting with each other so quickly.

However, I thought it would be a neat idea to have a go at creating an Allegro-like game library in C++, just for learning experience.  The problem is, I have no idea where to start looking for information, everything about game engine development is geared towards 3D, using DX or OpenGL.

I reckon I'm gonna re-install C++ and OpenGl, or SDL and go from there, but I'd like some info so I can at least plan the core workings of my library so That I don't make really stupid mistakes that take ages to redo.

[Lemming]

Do you want any external libraries to handle physics etc? Which parts of this engine would you like to create yourself?

Some nibbles of issues/problems/things to think about:

Layers are good (imo)
Object management
Rendering (this is where opengl comes in)
physics engine interaction (or physics simulation, if you're making that yourself)
physics engine uninteraction, some things shouldn't collide with some other things, and it's ok for some things to overlap.
event handling

There's more, but I hope that helps some atleast.

I'm using sdl+opengl for the engine I'm working on, which is hardly finished at all, but feel free to ask more specific questions.

[Tiny]

You should give Jason Gregory's Game Engine Architecture (http://www.gameenginebook.com) a go. A very good book on the subject. Designing and implementing an engine for the first time won't be smooth and you will have to refactor large parts of the code several times. The more you learn before starting the less work you'll have to do.

If you focus on 2D you might want to ignore the rendering parts and perhaps the animation system and the likes too. But there's still a lot of valuable information in there that's not directly related to the rendering method you use.

Also make sure you don't try to be too ambitious. Use as many libraries as possible for collisions, sound, ui, anything really. When you got a framework working and you've managed to make a game, it will be easier and more satisfying to replace libraries with your own code. Trying to do everything from the start will most likely be the reason why you won't have anything to show for your effort.

[desdinova]

thanks guys, I'll keep an eye out for that book.  I have one called  3D Game Engine architecture by David Ebberly from the library so I reckon that will help.  I'm going to make my way through some open source libraries and engines and start making a list of needed and desirable features.  It's been awhile since I last used C++ so I should probably get on to brushing up on that tomorrow, then SDL and OpenGL.  And, by then I should have had enough time to consider an initial design.  I'll definitely be keeping this project as simple as possible until I get a solid framework in place

[StudioFortress]

I'd recommend writing some small games first as well as looking through other engines. I wrote a simple 2D library in Java and I found it was only when I was using my library that I realised which features were in the way, which bits were pointless and never used, and what obvious features were missing.

[Lemming]

I recommend co-developing the engine along with a game you want to make too. When you need a feature from the engine, develop it, go back to the game, repeat.

[desdinova]

I'm simply doing it to learn and because its enjoyable.  I mean, I can, and will keep on making games in flash and C# but I also enjoy proper programming; data structures and algorithms, that sort of stuff.  I've made plenty of simply games using aforementioned tools, now I want to test my skills at something more low level.  Expand my horizons.  Don't worry about how inexperienced I am, my uni and pastime takes care of that.  And if it was going to be easy then why would I do it? I specifically want to challenge my self in a different way then higher level game development.  My main issue has been where to start structuring a core engine so I don't fuck something up that I could have foreseen.

[Tiny]

Don't listen to people that tell you not to write an engine. They usually speak only half the truth. I've been writing engines for a long time and it's never kept me back from anything. It is however true that you shouldn't write an engine if you want to make a game. It takes too long and you probably won't end up with what you wanted in the first place anyway.

Basically if you want to write an engine to learn engine programming and how game engines work, just do it! If you want to code a game, don't think for a second about an abstracted engine, just code your game.

If you do want to learn more about engines and not necessarily make a finished game, I can still recommend that you do small games in order to build your engine. Create a small game, say tetris. Then remove the tetris related logic and do something else, maybe a pacman clone or whatever. Start small and build on top of it. It will make sure your engine will have features actually required by a game and in the mean while you'll end up with a few small games too. Also it will protect you from coding stuff that will never be used by any game. Sometimes while designing some features sound good but in fact aren't very useful.

[oahda]

I would recommend SDL in combination with OpenGL then. You can use OpenGL for 2D graphics as well, and get hardware accelerated graphics which is great. SDL is portable to most systems, so that's also a good thing. If you want to go even lower level, you would skip SDL and program your own DirectX layer library, but that is really not recommended or even necessary. Even lower than that would be to write in Assembly.

Seconded.
Also, I prefer the newest SDL and totally revamped, newest OpenGL for this.
They will be a lot better supported when you are done anyway.

[desdinova]

Hey guys, sorry I stopped replying,  My PC stopped being able to find the tigsource forum server and I couldn't work it out.  But it's been fine ever since I formatted the other week.  I have started getting back into SDL and am loving it.  This is shaping up to be a fun project.  A belated Thanks for all the input.

[hexageek]

my only advice to you is if you're serious about this, please make it cross-platform.

[Falmil]

If you've already made more than 2 games, then you could probably use those games as the basis for a framework/engine. As Flawe said, all you really need to do is abstract common features out of every one of those games and put them into the engine. Then just use the engine to develop new games while still building on it when needed.

[MrGando]

Hello, I have been doing exactly that for about 5 months now. A 2D library for making games, it started as a side project, but now it's turning into the engine that we are using in our "independent studio". It's a great learning experience, but here's some advice:

1) Don't just start coding but try to actually design a bit what you want, will it be Classical inheritance design? Component oriented? , to get some inspiration try to learn how other engines work, some good ideas are Unity ( which I think you are already using ), but there are several worth checking.

2) Do something practical, that actually leads you to prototype faster, instead of a bloated monster that in the end will not help you very much.

A nice challenge is trying to go cross platform, I did that, but still it's not quite done, I chose C++ for our main language, and I embed some external libraries in the Engine, like Box2D for physics.

Good luck, 

[Falmil]

Components are probably better. Inheritance alone will usually just leave you with large trees with half of each object's functionality being unused.

[MrGando]

I agree, but component management systems often look very nice in paper, while in code they can require some experience to implement and fully understand.

[InfiniteStateMachine]

I'm on my 4th redo of a 2D engine. It has proven to be a really good way for me to learn programming beyond the basic stuff.

One thing I've noticed, is I like to get a decent state machine running first so I can more easily test the rest of the engine.

[dr.crow]

One thing I've noticed, is I like to get a decent state machine running first so I can more easily test the rest of the engine.

Got any recommendations for tutorials on state machines?

[InfiniteStateMachine]

One thing I've noticed, is I like to get a decent state machine running first so I can more easily test the rest of the engine.

Got any recommendations for tutorials on state machines?

I'm doing this in XNA so I started off with this tutorial

http://xna.jtmbooks.com/xnatutorials.html

Also used the tutorial in this book:

http://xnaessentials.com/unleashed/

Neither really worked that well for me with XNA, they required me to set up a lot of states before hand and their methods of switching states didn't really do it for me. Was a great starting point though.

After playing with Flixel for a while and seeing how Adam implemented a global method to quickly change states, I sort of took that functionality and tried to implement it in XNA with a couple extra features (mostly state popping and pushing so I could have menus render on top of a game etc).

Those first 2 tutorials are great for getting a window into how state management works but you'll probably find yourself wanting to make something that fits your needs better.

[MrGando]

I have found two nice tutorials that I used in my Game Engine

1) http://www.fastgraph.com/fsm.html
2) http://www.kiwicode.org/game_char_anim_tutorial/tutorial1.html

If you want to go a bit deeper into state machines, and agents, I could recommend you a decent lecture about it, http://www.cs.berkeley.edu/~russell/aima1e/chapter02.pdf

Good luck :-)

[oahda]

I've been using flash, python, and more recently; Unity and C# to create little games and so far they have been really good.  I really like the fact that I can get objects interacting with each other so quickly.

However, I thought it would be a neat idea to have a go at creating an Allegro-like game library in C++, just for learning experience.  The problem is, I have no idea where to start looking for information, everything about game engine development is geared towards 3D, using DX or OpenGL.

I reckon I'm gonna re-install C++ and OpenGl, or SDL and go from there, but I'd like some info so I can at least plan the core workings of my library so That I don't make really stupid mistakes that take ages to redo.

OpenGL does 2D (internally, it's handled like 3D, but it looks like flawless 2D), and I believe DirectX does this too, but I see no reason not to use OpenGL. SDL is a great choice for the window and input.