Portalized (GUI update)

fifi · Post by **fifi** » Fri Apr 18, 2008 2:34 pm

Eriksrocks, could you give me a link to this dev build of Portalized on Dev or Facepunch?

It would be fantastic!

nullsquared · Post by **nullsquared** » Fri Apr 18, 2008 9:46 pm

fifi wrote:Eriksrocks, could you give me a link to this dev build of Portalized on Dev or Facepunch? It would be fantastic!

If I'm not posting it, then don't try it. Way old, full of bugs and crap, and barely anything like the current state of the engine. I provide no support for it (either it runs or it doesn't), so, to save both you and me a lot of trouble, just forget it and wait for the next public release.

Eriksrocks · Post by **Eriksrocks** » Fri Apr 18, 2008 11:42 pm

What he said.

fifi · Post by **fifi** » Sat Apr 19, 2008 9:32 am

OK, I will wait for next public relase.

detox · Post by **detox** » Sun Apr 20, 2008 3:19 am

nullsquared wrote:
eugen wrote:i believe the 1-1 link in Portal was due to gameplay considerents, im pretty sure they can link portals in a chain
Not so sure about that. According to the commentaries, they used some kind of "unified space" or "bubble" where the two portals met - if this is indeed how they did it, they can only ever have 2 portals interconnect with each other, and not form a chain. Also, I was much referring to Narbacular Drop there

[...]

Fantastic project nullsquared. I'm a fan

I played through Portal and listened to the devs commentary too. I remember the commentary about the portal dynamics too, it was very interesting. I believe you are correct, they created some actual game-space beyond the portals. I remember the commentator said it was due to an issue they had with integrating their physics system, and maintaining a "nice" motion through the portals.

I am guessing, but I think this is really an issue with their physics system and how they chose to model the physics of the player character.

I think maybe even using their technique it may be possible to link multiple portals without difficulty, as long as you do not have multiple objects entering the portals at the same time - multiplayer or something similar.

nullsquared · Post by **nullsquared** » Sun Apr 20, 2008 2:08 pm

detox wrote: I think maybe even using their technique it may be possible to link multiple portals without difficulty, as long as you do not have multiple objects entering the portals at the same time - multiplayer or something similar.

One of the points in my engine being, you can make big portals and transport tons of objects at once.

Eriksrocks · Post by **Eriksrocks** » Sat May 03, 2008 11:42 pm

What's the update on the beta?

fifi · Post by **fifi** » Sun May 04, 2008 4:44 pm

Yea, when we can expect some new informations about Portalized?

Eriksrocks · Post by **Eriksrocks** » Mon Jun 30, 2008 10:47 pm

Update:

http://nullsquared.wordpress.com/2008/0 ... e-no-news/

eugen · Post by **eugen** » Mon Jun 30, 2008 11:23 pm

thats for the better, cant wait to see the final product

Eriksrocks · Post by **Eriksrocks** » Mon Jun 30, 2008 11:35 pm

You may also want to check out the FacePunch thread, it's been updated much more recently!

http://forums.facepunchstudios.com/show ... 09&page=19

nullsquared · Post by **nullsquared** » Mon Jun 30, 2008 11:52 pm

Yeah, sorry about that, I tend to update random threads at random intervals. Currently I'm rewriting some parts of the engine since it was getting a bit hard to maintain (which is never a good thing, especially when you're the one writing it). Too many singletons, and everything knew about everything, and it became an ugly mess. I used to have discussions about this one gamedev without ever understanding what the pros were trying to explain, but as I kept on coding I'm starting to understand what they were trying to explain.

Big pluses due to maintainability:
- I managed to rewrite about 50% of the engine using the new code base design in about 2-3 days (compare that to the months of coding for the old code base using the old design of mine)
- lots of very readable and intuitive code. Just the basics of it, including a full GUI with selective rendering (w00t QuickGUI

) and physics:

Code: Select all

int main(int argc, char **argv)
{
    engine::renderer *renderer = NULL;
    try
    {
        renderer = new engine::renderer(engine::DATA_DIR + "renderer.xml");
    }
    catch (const std::exception &e)
    {
        std::cerr << "ERROR: " << e.what() << "\n";
    }

    Ogre::ResourceGroupManager &rgm = Ogre::ResourceGroupManager::getSingleton();
    rgm.addResourceLocation(engine::DATA_DIR, "FileSystem", "General");
    rgm.initialiseResourceGroup("General");

    engine::input input(renderer->hwnd());
    input.resize(renderer->width(), renderer->height());

    engine::gui *gui = new engine::gui(renderer->viewport());
    // gui input dispatcher
    engine::guiDisp *guiDisp = new engine::guiDisp(*gui);
    // let our basic gui input dispatcher grab the current input
    input.grab(guiDisp, guiDisp);

    engine::physWorld physWorld;
    physWorld.freq(1.0 / 60.0); // step physics at 60 FPS

    engine::timer timer;
    while (renderer->windowIsOpen())
    {
        renderer->begin();
        input.capture();

        timer.tick();

        physWorld.tick(timer.delta());

        renderer->render();
        gui->render(renderer->viewport());

        renderer->end();
    }

    delete guiDisp;
    delete gui;
    delete renderer;
}

- due to the new design of the code base, there's very tight coupling with Lua:

Code: Select all

-- camera is Ogre::Camera, vec3 is Ogre::Vector3
camera:pos(vec3(10, 10, 10))
camera:look(vec3(0, 0, 0))

prop = physProp("prop", rootSceneNode, physWorld);
-- load from a script
prop:parse(DATA_DIR .. "props/box.xml")
prop:pos(vec3(0, 10, 0))
prop:impulse(vec3(0, -5, 0))
prop:mass(10)

-- step physics at, say, 30 FPS (just an example again)
physWorld:freq(1.0 / 30.0);

function tick(dt)
    -- slow motion works seamless with the whole
    -- engine, without choppy physics (as in the "fix your timestep" article)
    if keyDown("-")
        timer.speed = timer.speed - dt
    end
    if keyDown("+")
        timer.speed = timer.speed + dt
    end
end

- easier gameplay coding

hpesoj · Post by **hpesoj** » Tue Jul 01, 2008 11:52 am

Mmmm, glowing stuff. It's really funny some of the abuse you get thrown at you in your other threads. Odd how this doesn't happen on these forums.

I am working on something quite similar to your engine at the moment (Ogre + Newton + Lua), albeit without the whole portal thing

. I'm interested in knowing how you are handling your "entities" internally. I have most recently gone down the smart pointers route, mainly because I want to make it as hard as possible to crash the engine via script. With regular pointers to objects, it's easy to end up with a Lua reference to a deleted object. Problem is that my code is steadily getting more and more complicated, and to add even simple features is a chore. It'd be cool to know how you have organized things in your engine.

Joe

nullsquared · Post by **nullsquared** » Tue Jul 01, 2008 2:10 pm

hpesoj wrote:Mmmm, glowing stuff. It's really funny some of the abuse you get thrown at you in your other threads. Odd how this doesn't happen on these forums.

These forums are definately a lot mature than facepunch. On FP you either have "woah 1337 epic awesome woah omg rofl awesome!", or you have the other end "lol noob sucks stupid portal is so much better noob lol".

I am working on something quite similar to your engine at the moment (Ogre + Newton + Lua), albeit without the whole portal thing .

Newton Archimedia? Definately use the betas (PM Julio), don't stick with 1.53 (just making sure

). Newton Archimedia ran 1000 concave hulls in real time for me. (X2 3800+)

I'm interested in knowing how you are handling your "entities" internally. I have most recently gone down the smart pointers route, mainly because I want to make it as hard as possible to crash the engine via script. With regular pointers to objects, it's easy to end up with a Lua reference to a deleted object. Problem is that my code is steadily getting more and more complicated, and to add even simple features is a chore. It'd be cool to know how you have organized things in your engine

Everything in lua is wrapped with boost::shared_ptr (using luabind).

JeDi · Post by **JeDi** » Tue Jul 01, 2008 4:08 pm

Great you are teaming up to create a real game out of it. Having seen the tech-demos of your engine, I'm pretty sure the end-result will be mind-blowing.

I also had a quick read at your facepunch thread, and I was amazed of the immature answers you get there. It seems as if everyone there is a bit jealous of your work, and tries to make you look bad. Most of the guys are probably at least ten years older than you and haven't accomplished anything yet. So nothing but respect to you here

Greetz,
JeDi

nikki · Post by **nikki** » Tue Jul 01, 2008 4:22 pm

Well... Maybe its called 'facepunch' for a reason.

hpesoj · Post by **hpesoj** » Tue Jul 01, 2008 5:25 pm

Newton Archimedia? Definately use the betas (PM Julio), don't stick with 1.53 (just making sure Wink). Newton Archimedia ran 1000 concave hulls in real time for me. (X2 3800+)

Newton 2.0? Yup, just got the betas seeing as there is no 1.53 library for 64-bit Linux. Looking forward to trying it out

.

Everything in lua is wrapped with boost::shared_ptr (using luabind).

Does this mean that the lifetime of your entities is controlled by the Lua references to them? How would you handle clearing of the scene, just by deleting all Lua references? (this wouldn't be a bad method of course, so long as the Lua code is organized, I'm just curious because I've spent a lot of time thinking about this).

nullsquared · Post by **nullsquared** » Tue Jul 01, 2008 6:14 pm

hpesoj wrote:
Newton Archimedia? Definately use the betas (PM Julio), don't stick with 1.53 (just making sure Wink). Newton Archimedia ran 1000 concave hulls in real time for me. (X2 3800+)
Newton 2.0? Yup, just got the betas seeing as there is no 1.53 library for 64-bit Linux. Looking forward to trying it out .

Sounds good

Everything in lua is wrapped with boost::shared_ptr (using luabind).
Does this mean that the lifetime of your entities is controlled by the Lua references to them? How would you handle clearing of the scene, just by deleting all Lua references? (this wouldn't be a bad method of course, so long as the Lua code is organized, I'm just curious because I've spent a lot of time thinking about this).

Pretty much. To be completely honest, I haven't really figured out the final design here. I'm debating between scripting the whole game in Lua and just having the engine in C++, and between allowing Lua to "listen" on the game in C++. Leaning more towards scripting everything in Lua, since it'll be a crap-load more flexible, and WAY easier.

Eriksrocks · Post by **Eriksrocks** » Wed Jul 02, 2008 1:55 pm

Just curious, is this the Svenstaro you've teamed up with?

nullsquared · Post by **nullsquared** » Wed Jul 02, 2008 2:12 pm

Eriksrocks wrote:Just curious, is this the Svenstaro you've teamed up with?

I actually never heard about this site of his, but according to his skype and birthdate info, yup, that's him. It's also him over here in the Ogre forums, the guy with the Ubuntu Hardy compilation "guide"

Svenstaro · Post by **Svenstaro** » Fri Jul 18, 2008 10:57 pm

Oh dear, I'm being googled. And that site you found is awful

I really gotta redo that over the course of the summer break.

Post by **Noman** » Fri Jul 18, 2008 11:48 pm

On the subject of the scripting debate, I'm kinda against scripting entire systems. Not for performance considerations, but for development integrity reasons.

Sometime along the future, somebody will change a feature in a "Core" script (because lots of the system is scripted, there will be a core) and will break something, and it will be very hard to track down.

Debugging from c++ to scripts and stuff like that is rather hard.

In my opinion, it is best to script out the content. Just like the materials can be scripted in ogre (since they are supposed to be created by a technical artist and not a programmer), the parts of the game that should not be created by the programmer should be scripted. High level game rule logic (how do you decide how much damage a shot took), dialogs, level layout and cutscenes should all be made in scripts.

Sometimes its easy to miss the role you are currently filling when working in small teams, because everyone does everything. But when deciding, you should ask yourself "If I had a team of 300 people, would I want a programmer to write this section?", if the answer is yes, don't script it out.

Eriksrocks · Post by **Eriksrocks** » Tue Jul 29, 2008 2:47 am

Svenstaro wrote:Oh dear, I'm being googled. And that site you found is awful
I really gotta redo that over the course of the summer break.

Yes, you are.

It wasn't that bad...

Svenstaro · Post by **Svenstaro** » Tue Jul 29, 2008 4:43 am

I'm currently in the process of creating a Portalized mainsite so hang in there

Svenstaro · Post by **Svenstaro** » Mon Aug 04, 2008 1:51 am

Okay here we go guys: http://www.portalized.org/

Null and me will release news, screens, videos and what else as they become available. Please, take the time to register yourself on the forums, introduce yourself, ask us a few questions or just give us some feedback.

We'll be waiting

.