Announcement

Collapse
No announcement yet.

Introducing The R5 Game Engine

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Introducing The R5 Game Engine

    Introducing The R5 Game Engine

    Phoronix: Introducing The R5 Game Engine

    With open-source game developers, the ioquake3 game engine is quite popular to use as a base since the Quake 3 / id Tech 3 engine is well-developed and famous thanks to id Software and then their kid generosity to open-source it when it reached the end of its commercial life. But there are many other open-source game engines out there too, including a new one that's just recently come about: r5ge, short for the R5 Game Engine...

    http://www.phoronix.com/vr.php?view=OTM3Mg

  • Dragnadh
    replied
    Where can you download the complete package of the r5 engine?(Does it have a editor or a recommend editor?)

    Leave a comment:


  • Dragnadh
    replied
    Xreal is still going but it replaced itself from place. It is mainly on splash damage forum and they have made some progress. http://www.splashdamage.com/forums/s...=21825&page=20

    Leave a comment:


  • dacresbu
    replied
    Originally posted by eugene2k View Post
    Since I'm the one working on linux support, you can take my word for it
    who's working on mac support?

    Leave a comment:


  • voriDoomy
    replied
    Introducing The R5 Game Engine

    What is the worst game ever made or at least the worst that you have played?

    Leave a comment:


  • ArenMook
    replied
    Time for some clarifications

    R5 has a model viewer, and documentation. The documentation is in the code, however. The idea is that us, developers, quite frankly shouldn't have to open up a web browser in order to figure out how something works. We work with code, so why shouldn't the documentation in the code as well?

    It also does follow a component-based model. Object class is like a GameObject in Unity. Script class is like a Component in Unity. You build your game by attaching scripts to objects. Scripts can't exist without objects. It's almost exactly like Unity in this regard, except that the same system also applies to the UI: you have UIWidgets, and you attach UIScripts to them to make them do what you want.

    R5 has ASCII, binary, and LZMA-compressed file formats for models, textures, fonts, and JSON-like format files.

    It's also a hobbyist engine -- it's something I've been working on for years in my spare time, on and off. It's not meant to compete with Unreal, Unity, or id Tech 5. It is, however, meant to be free and easy to work with. As for some demos, here are some screenshots of a game I was making using the engine last year:

    http://www.nextrevision.com/dotc/buildings.png
    http://www.nextrevision.com/dotc/improvements.jpg
    http://www.nextrevision.com/dotc/story2.jpg

    Thanks for the feedback, guys. Tools are indeed important and I will be focusing on making an editor in the near future.

    Leave a comment:


  • eugene2k
    replied
    Originally posted by elanthis View Post
    That's the serialization format.
    Oh, sorry, got confused there a bit.

    You should work on that first, soon as the core framework is even remotely usable (which I'm guessing it is).
    That was the next milestone

    Thanks for the feedback.

    Leave a comment:


  • V!NCENT
    replied
    No object model and editor? Whoah... I'll stick to jMonkeyEngine...

    Leave a comment:


  • Setlec
    replied
    Originally posted by cb88 View Post
    The Xreal feature set was just all over the place and it was bloated... it had java in it O.o and all kinds of other useless crap.(...)
    Java was used for JBullet - Java port of Bullet Physics Library, which was Tr3bor decision, there were others that implemented bullet physics. iirc

    Leave a comment:


  • elanthis
    replied
    Originally posted by eugene2k View Post
    Object model is r5's own format (there's a binary and an ascii format).
    That's the serialization format.

    How are game objects in the engine handled? Is there a component system? Reflection? Custom type checking or RTTI? How are object lifetime managed? How do you attach graphics and physics data to the game objects? Scriptable? etc.

    Honestly I'm just looking to make sure you haven't re-implemented Unreal's broken-ass 1990's style object system. They didn't understand component systems, tried to implement a hierarchal class system, realized that those don't actually work, and ended up just moving all the data and logic that any particular object might need into the base object class. So every bullet has all the data members necessary to implement "camera bob" because the same class is used to implement cameras. So every bullet flying through the air needs like a 2kb object allocated.

    Ideally, you go with a component system. The base GameObject is just a container of components. You can have a Transform component (position, scale, rotation), a PhysicsBody component, a Mesh component, a Light component, a Camera component, etc. PhysicsBody and Camera would just depend on the Transform component, so there's no duplication of data, but objects can be composed in exactly the way they need. A ton of game-specific components will be written for each game of course (like a TurretAI component that tracks other objects and then fires at them), and then object-composition is necessary of course (a complex game object like a vehicle is actually many objects with different component sets that are attached to each other and act like one object).

    I took a quick look through the code and couldn't find anything but graphics and other low-level implementation files, which is why I'm asking. I don't see anything for an object model anywhere.

    No editor yet.
    You should work on that first, soon as the core framework is even remotely usable (which I'm guessing it is). A graphics engine is borderline useless; I can get a few DigiPen sophomores to whip together a gorgeous high-performance graphics engine in less than a year. The hard part -- and the part that makes a game engine useful or not -- is the toolset. The toolset is what lets the content folks actually make a real playable game. As a tech guy myself it took me a while to really learn that lesson properly, but learn it I did. A game engine without a toolset is just a tech demo at best, and when it takes months to iterate on something that should take days, it becomes impossible to create a high-quality, entertaining, polished game experience, no matter how beautiful the graphics are. Tools, tools, tools!

    Unfortunately there's only two of us working on it, and we can't do everything. If you're interested in helping out though, you're very welcome to.
    Yeah, I know how that goes. Good luck finding more people with free time and the know-how to do a game engine. If you look around for people to recruit, try to find a detail-oriented UX guy with experience with 3D content apps and games. That's what you want to get a good editor made, and that'll take you into the realm of being able to compete with the Big Boys (at least for indie titles).

    Leave a comment:

Working...
X