# Tips on code organization?

This topic is 2780 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

So I'm using Ogre3d and Box2d to create a rougelike / dungeonsiege type game. So far I have working the random generation and of levels and automatic building of them in 3d via manualObjects.

I can't do much more because I can't figure out a system for drawing ANYTHING. Should a level hold its own geometry? How do I update an entity? Should it hold a pointer to its scene node?

Sorry I'm not being clear - I'm very confused as how to integrate everything together - 3d renderer, physics, and gamelogic.

##### Share on other sites
Is this your first time writing a game? If so, I wouldn't worry about structure at all, or you'll paralyze yourself with agonizing over doing it the "right way".

Just get it working. If a pointer to the scene node helps you now, go for it. If a level holding it's own geometry is the easiest way for you to get the data drawing, go for it. As you go, you'll find that some of your choices worked out really well, and some have been a royal pain to work with. And when you get to that point, you can take a moment to shuffle the painful bits around into something cleaner and easier to use. But right now, you don't know what will and will not work well, so you just have to experiment! Experience is the best teacher for this sort of thing, I think.

Programming is a lot like painting. Right now you're in the sketching stage, just roughing things in to get a general feel for the program. Nothing is set in stone, you're just experimenting. Worrying too much about super gritty details like what has a pointer to what is similar to worrying if colors in your painting will clash before you've even got the outlines finished.

##### Share on other sites
I really like the Model-View-Controller architecture as a starting point. The general idea is to seperate your logic, graphics and input as much as possible.

As you've alluded to, organising them can be quite difficult. I tend to use pairs of classes, one for logic and one for view/controller. E.g. World/UI_World - the UI_World is responsible for creating the World and interfacing with it. Other complex objects can also be split into pairs, e.g. I have a Surface class and a UI_Surface class. The UI_Surface holds a pointer to a Surface. The Surface is deformed by the World, then the UI_World uses UI_Surface to render it.

I run my UI and logic in seperate threads and use boost::asio for cross-thread function calling. Seperating your UI and engine into seperate threads isn't for the lighthearted, but is worth pursuing. However, you really need to start your project with this in mind, since trying to modify your code later for multithreading can be a bitch.

Hope this helps.

I would be interested to hear other people's approaches to code organisation also...?

##### Share on other sites
Quote:
 Original post by kuroiorandaIs this your first time writing a game? If so, I wouldn't worry about structure at all, or you'll paralyze yourself with agonizing over doing it the "right way".

This is a crucial lesson to learn if it is in fact your first serious project. (I mean serious as in not just a simple 1 or 2 day concept that you played around with) I've spent the last few years in my spare time working on learning a lot of the stuff involved in creating any type of real-time application, trying to do things "the right way" on the first shot. Up until about a year ago everything I did took forever because I either couldn't figure out the best way to do it, or I ended up rewriting each and every part 500 times to make sure it was perfect.

I'm just getting out of that habit now, and things are going a lot smoother for me.

Tip from a recovering perfectionist/amateur: Don't spend so much time on the planning and design specifics if you're not getting paid to do so. If you really wanna know a bit about what the "best" ways to do stuff, pick up a copy of the Gang of Four book. It's a priceless resource for that sort of thing. After that just do what you want to do and when you hit something that isn't working or you can't figure it out on your own then THAT is the time to go looking for it.

I've made more progress on my own projects in the last couple of months than I made in the last few years before I realized the value of making my own decisions first and then revising them later when it was appropriate.

##### Share on other sites
I've also had this problem a lot, where I have lots of pieces of logic (e.g. physics, rendering, mouse/key input), with no easy way to tie them together (without too many interdependencies).

Though recently I've been using the lua scripting language to allow each to bit of logic to interact without any real dependencies between them, where each has an interface to lua. While the lua code tying them together might not be the prettiest, I find it really nice to contain any messiness to the scripting section of my project.

I'd really recommend trying this, it took me about 3 weeks to learn lua and how to interface it with c/c++.

Here's what my main lua code looks like (I'm still in the middle of implementing the render code):
require 'Vec3'require 'Mat4'require 'Camera'require 'mouseSmooth'require 'Timing'require 'Model'require 'Render'timing = Timing.new(1/60,5)mouseLook = falsecam = Camera.new()cam.speed = 5function timing.step()	mouseSmooth.step()	if mouseLook then		cam.yawing = mouseSmooth.x		cam.pitching = mouseSmooth.y	else		cam.yawing = 0		cam.pitching = 0	end	cam:step(timing.stepTime)endfunction Main.keyPressed(k)	if k == 87 then cam.moveForward = true	elseif k == 83 then cam.moveBackward = true	elseif k == 65 then cam.moveLeftward = true	elseif k == 68 then cam.moveRightward = true	elseif k == 27 then Main.quit()	endendfunction Main.keyReleased(k)	if k == 87 then cam.moveForward = false	elseif k == 83 then cam.moveBackward = false	elseif k == 65 then cam.moveLeftward = false	elseif k == 68 then cam.moveRightward = false	endendfunction Main.mousePressed(b)	if b == 0 then		mouseLook = true		Main.lockCursor(true)	endendfunction Main.mouseReleased(b)	if b == 0 then		mouseLook = false		Main.lockCursor(false)	endendfunction Main.mouseMove(x,y)	mouseSmooth.mouseMove(x,y)endfunction Main.run()	timing:run()	cam:run(timing.stepTime, timing.interpTime)	local projMat = Mat4.newPerspective(math.pi/4, Main.clientWidth/Main.clientHeight, 1, 300)	local viewMat = cam.mat:inverse()			local modelMat = Mat4.newIdentity()	local modelViewMat = viewMat * modelMat	local modelViewProjMat = projMat * modelViewMat	local normalMat = modelViewMat:norm()		Render.viewport(0,0, Main.clientWidth, Main.clientHeight)	Render.clear{color={0.1,0.2,0.3, 1}, depth=1}	Render.test_run(modelViewProjMat)	Render.drawElements('triangles', 3, 'unsigned_int', 0)end

##### Share on other sites

i'm having light-leaking issues i need to fix. here are some screenines.

using ogre3d for gfx and box2d for physics. levels are dynamically created from tilemaps (but not using tiles! example: a wall is not made of tiles, it is an actual one piece! very low poly count! great for physics functioning!)

[Edited by - overeasy on December 6, 2010 2:37:13 PM]

1. 1
2. 2
Rutin
24
3. 3
JoeJ
19
4. 4
5. 5

• 17
• 40
• 23
• 13
• 13
• ### Forum Statistics

• Total Topics
631729
• Total Posts
3001918
×