Sign in to follow this  
overeasy

Tips on code organization?

Recommended Posts

overeasy    100
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 this post


Link to post
Share on other sites
kuroioranda    304
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 this post


Link to post
Share on other sites
dangerdaveCS    122
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 this post


Link to post
Share on other sites
ChugginWindex    187
Quote:
Original post by kuroioranda
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".


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 this post


Link to post
Share on other sites
andrew111    310
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 = false
cam = Camera.new()
cam.speed = 5

function 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)
end

function 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()
end
end

function 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
end
end

function Main.mousePressed(b)
if b == 0 then
mouseLook = true
Main.lockCursor(true)
end
end

function Main.mouseReleased(b)
if b == 0 then
mouseLook = false
Main.lockCursor(false)
end
end

function Main.mouseMove(x,y)
mouseSmooth.mouseMove(x,y)
end

function 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 this post


Link to post
Share on other sites
overeasy    100
i'm taking your guys' advice. it ain't pretty (the code).

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]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this