Thoughts / Requests for future release

by TheLove on 01/04/2013 23:11, 25 messages, last message: 01/27/2013 00:07, 4769 views, last view: 05/04/2024 22:40

Hey yo

collect edition is up after long waiting time, the delay caused by mappers mostly, anyway no big changes compared to justice edition else maps and sound effects.

so what do you expect from the future release?
i really do want client demo recording (very helpful + available with SWLACC) and new simple logo, new menu interface & background, editing demo for newcomers, improve rocket speed?

so what is your thoughts?

   Board Index   

#6: Re: ..

by suicizer01 on 01/07/2013 08:57, refers to #5

You sir, have no idea about the goal of cube engine 2. That has been suggested a lot of times before and there are several reasons why it shouldn't be done.

reply to this message

#7: Re: ..

by eihrul on 01/07/2013 09:17, refers to #6

Well, I am not specifically opposed to it, it just takes time to think out how to do it right. And right now, after being completely dehumanized by the release process, now is not the right time for me to think it out... It needs to also be done in the context of a saner auto-update mechanism for the game releases itself, because I think these giganto releases are becoming a bit too traumatic for all involved.

reply to this message

#8: Re: ..

by kripken2 on 01/08/2013 04:07, refers to #7

+1 to less giganto releases, and finding a better solution for getting content out.

This is sort of what I messed around with in my syntensity fork of cube2 a few years back. It split up maps into assets, and downloaded the ones it needed right before running the map. Uploaded maps could be played immediately. You can of course have more curating/testing of maps before making them downloadable if you want.

I am working on multiplayer in the BananaBread port of cube2 to HTML5 right now actually, which offers another potential solution to avoiding huge releases: The client is a website, just like gmail or whatever, whenever you connect to it you get the latest version automatically. With some continuous integration infrastructure this could be very convenient for devs - no big releases at all, and content is also managed by the browser with respect to caching etc.

If there's interest in either approach I'd love to work on it with the main cube2 project. If not, I'll continue in the BananaBread fork ;)

Anyhow, forget all this, congrats again on the great release eihrul, we all know it is a ton of work. Take a well-deserved break :)

reply to this message

#9: Re: ..

by Hansbert on 01/08/2013 10:26, refers to #8

+1 to #7 and #8

reply to this message

#10: Re: ..

by ultrasemen on 01/08/2013 15:59, refers to #7

But what do you think about mods in general? It seems for me that all this sauer party is against modding, against innovations, but I like Sauer, more than red eclipse or other cube games... It just needs to be more variative and diversified.
Complex auto-update and auto-download system would be just great. Would be great if servers would set not only "map" and "gamemode", but also "mod" (or any "mod" would be other "gamemode"), so we would download maps and mods the same way. And you can filter out all mods but default, without changing different master-servers.

reply to this message

#11: Re: ..

by Q009 on 01/08/2013 16:17, refers to #10

This is not Garry's Mod.

reply to this message

#12: Re: ..

by ultrasemen on 01/09/2013 10:33, refers to #11

Where did you see anything like Garry's mod in my concept? Many games have a nice mods reorienting the gameplay, but keeping the style, the feel of the game.

reply to this message

#13: Re: ..

by Q009 on 01/09/2013 10:44, refers to #12

"Would be great if servers would set not only "map" and "gamemode", but also "mod" (or any "mod" would be other "gamemode"), so we would download maps and mods the same way. And you can filter out all mods but default, without changing different master-servers."

Right there ;)

reply to this message

#14: Proper Collision for Imported Meshes

by DreamBliss on 01/09/2013 12:14

I would like to see some sort of collision detection system for imported meshes.

So far to my knowledge there exists only basic collision, based I think on the bounding box.

There are two ways to do this. The Morrowind/TESCS way, which was to all the import of a special, invisible collision box along with a mesh. The collision box had a unique name and of course was not visible in-game.

Far better is the Unreal Tournament/UnrealED way. You can have textures that cause collision, or the game pretty much does it all for you. It wraps a sort of collision bounding box around a mesh, fitting it as efficiently as possible. You could have very complex models, and you can see evidence of this in any UDK map.

Why do we need collision detection for meshes when we can do everything in Cube 2? Because it is far easier to create an archway or some complicated shape in a modeling programming than in Cube 2, where you are limited how you can move the equivalent of vertices.

Also meshes can help speed up the game a little, depending on how Cube 2 handles meshes VS BSP.

I don't know about anyone else, but if I was creating a map like say, Monastery, I would sure prefer to make my meshes in Max, Wings 3D or even (gasp) Blender because I could do them in minutes, VS the hours it must have taken the guy who made that map.

Keep up the good work with Cube!
- DreamBliss

reply to this message

#15: Re: Proper Collision for Imported Meshes

by Q009 on 01/09/2013 13:41, refers to #14

It would require some major rewrites in the physics engine and that's very unlikely to happen.

Also, I thought I'd point out: Cube 2 doesn't use BSPs. It uses octree ;)

reply to this message

#16: Re: Proper Collision for Imported Meshes

by suicizer01 on 01/09/2013 14:05, refers to #14

What you are describing is just what is happening on Cube Engine 2. When you import a model (ad for use in maps!), a boundingbox will be generated automaticly that serves as a collisionbox (it's just named boundingbox in Cube Engine 2), which stops players going any further, unless certain clipping settings has been configured for the model.

The playermodels just have a static boundingbox which can't be changed without modifying the sourcecode (I recommend not to do so unless you won't connect to the original masterserver anymore).

reply to this message

#17: Re: Proper Collision for Imported Meshes

by suicizer01 on 01/09/2013 14:25, refers to #14

What you are describing is just what is happening on Cube Engine 2. When you import a model (ad for use in maps!), a boundingbox will be generated automaticly that serves as a collisionbox (it's just named boundingbox in Cube Engine 2), which stops players going any further, unless certain clipping settings has been configured for the model.

The playermodels just have a static boundingbox which can't be changed without modifying the sourcecode (I recommend not to do so unless you won't connect to the original masterserver anymore).

reply to this message

#18: Re: ..

by ultrasemen on 01/09/2013 20:56, refers to #13

Well, this is logical thing to do with any game being multiplayer and having global mods, no matter, what game exactly it is. Still don't understand, why you're saying mods are bad?

reply to this message

#19: Re: ..

by Q009 on 01/09/2013 20:57, refers to #18

When did I say they're bad? I'm just saying that the thing you want is pretty much what Garry's Mod is.

reply to this message

#20: Re: ..

by ultrasemen on 01/10/2013 15:26, refers to #19

Okay, you didn't, it's just the feel that always pursues me here. Sorry.

reply to this message

#21: Cube 3.

by Evropi on 01/13/2013 20:30

I say it's about time for Cube 3. Or Cube will just grow a bit *too* old, and die. If we don't break compatibility *now*, we will always be behind. And Cube will gradually disappear. This must not happen.

Here's what I'd like to see:

- A well-optimised Tesseract - for dynamic lighting.
- An off-the-shelf solution for a physics engine. Why do you need to reinvent the wheel when you can use outstanding open source libraries such as Bullet? The current one is both slow and bad.
- Better support for translations.
- Possibly scrapping CubeScript. It is weak as a DSL and has meant serious regressions in interface, where there could be a great interface to the game.

reply to this message

#22: Re: Cube 3.

by Razgriz on 01/13/2013 23:36, refers to #21

Aww, but i liek cubescript. And if by interface you refer to 3dgui, yes, that is indeed horribly limited, but not completely useless.

PS: If another person says a language sucks because it doesn't offer arrays out of the box should eat soap and gargle vodka afterwards.

reply to this message

#23: Re: Cube 3.

by Julius on 01/26/2013 19:13, refers to #21

What you are looking for is called Octaforge and should have a first release soon:
http://octaforge.org/node/378

It implements tesseract, a new gui, full LUA scripting, and bullet integration is AFAIK on their road map.

Development is a bit slow and behind closed doors it seems however. I hope that will change once there is an official release.

Besides that, a content restart using only really open-source and more modern graphics would do the Cube2 engine well (albeit that is already done with RedEclipse to some extend).

reply to this message

#24: Re: Cube 3.

by suicizer01 on 01/26/2013 20:57, refers to #23

Go ask Open Arena for that.

It's not on us to decide it would be good because we have no such input to the project, as that could only happen whenever a new project based on Cube Engine 2 which is more "open" as Sauerbraten or the lead-developer wants it. So actually it should be a target for a certain project to be really open-source at the very first start.

reply to this message

#25: ..

by Julius on 01/27/2013 00:07

That is what I ment... a new "Sauerbraten2" or what ever, that uses Octaforge/tesseract and this time uses CC art only.

Obviously it wouldn't make sense to change all of Sauerbraten now.

But RedEclipse is already such a project, albeit so far not with Tesseract yet.

Oh and I was mistaken, the octaforge developers just told me that bullet has some problems with Cube2 and they would probably use Newton physics at some point instead.

reply to this message

   Board Index