WorldSpawn official WIP thread

[Mugwump]

It's already impressive that you managed to squeeze a Quake engine out of Flash!

like models wont receive shadows from the world

No clue if it's feasible but here's an idea: could you make some sort of "anti-particle" that would be invisible but would block light? Considering the sheer amount of particles your engine can handle, there could be a solution here.

My next engine will attempt to compete with FTE and DP.

I would be VERY curious to see that! When you get to it, try to keep compatibility in mind. I love DP but its issues with a number of custom maps and mods are annoying to say the least.

[MadGypsy]

One thing to note. I don't build quake engines. When I say "attempt to compete with DP and FTE" I am speaking in a features sense. Even my current engine is not trying at all to be a quake engine. It is simply utilizing some quake technology. When it comes time to work on a game language, I assure you it will be next to nothing like QC and i have no plans to ever make QC or even just the progs.dat supported. I even have my own gamepack for radiant. It is tiny ATM but I am not even trying to keep ex func_door...none of it.

We already have like 50 quake engines. I'm building a custom game engine and I have every intention of making it proprietary (the next one). I can't even consider simply rewriting someone elses work in a different language and making an actual quake engine would be little more than that.

[MadGypsy]

Oops I forgot to answer your particle question...

Actually, I'm curious if I could use the particle technology or some part of it to get amazing performance for all the models. In a way, everything is just a bunch of particles. We call them faces but, in the end it's just textured polygons which is what a particle is. Something tells me it's not that simple otherwise why wouldn't my API already be doing it but, I bet there is something there that can be used to add performance. 1/2 a million particles is insane. There is no way in hell I could even load 1/2 a million polys...but why? There is obviously something here I don't understand yet.

@blocking particles - you are more than welcome to grab my source from me and take a stab at that idea. I currently wouldn't even know where to begin. My idea for attempting to add light to models was to consider the lightmap to be almost like a sheet and shove the model under it. I'm not saying that is good or will even work but, that's an idea I've thought about over the last week or so.

[Dutch]

@proprietary

Documenting your engine will be key. Lack of coherent documentation is what plagues some of the features of the fancier quake engines...its probably why there's such a strong fan base for more faithful engines. They don't do as much cool shit, but very few people know how to implement that cool shit without spending weeks collecting hard to find info on the internet, or reverse engineering the source code. (i know I'm talking quake engines here, but the concept still applies...knowing you though, documentation and cleanliness in your packaged final product won't be an issue).

[MadGypsy]

Honestly, I cant wait to write some documentation. That would mean I actually have something that can be used. However, my code is commented out the ying-yang. Practically every line in some cases. I even have my methods commented in such a way that if use a method in another class and hover your mouse on it, it fully explains...everything.

ex: You could type something like
var something = StaticClass.myStaticFunction(

actually I'll just screencap it BRB

[MadGypsy]

this


I probably should have used a function that expects more stuff but, I didn't so, just imagine everytime you hit a comma that message turning to the explanation of the next thing it expects.

Some of it needs to be updated. I just noticed that the main function in that image has wrong info in the main comment. Like I said, I program things 3 and 4 different ways. Sometimes the docs for a feature get left behind a little. ie that comment is the docs. All that @param stuff etc is where that tooltip is getting it's info.

[Gem]

I haven't read all your posts (lack of time) but I did catch the idea that you're working on some sort of an engine, which is a great thing. I caught sight of the fact that you are great at programming and know a lot of languages, so I think it's a super cool idea about creating a game engine. I think I may have suggested this to you in the past, about making a game or something..

In any case, I think that you're on to something here. I'd like to imagine an engine that you can play on the fly or plug textures in or models (there is a lot of development on those things at this site)

Further more, maybe you can go with it to Steam to garner even more support Ehh.. the last thing I wanted to say is that, one of the most important thing is how it plays/ handles, so make sure it has super nice physics, nice jumps, (maybe glides) hehe, or maybe some unique gameplay mechanics that were not thought of. Most importantly that it will be fun to play All in all, all of this does show a promising future

Much success

[Mugwump]

One thing to note. I don't build quake engines.

Crap. Here I was hoping for a better DP... Oh well.

you are more than welcome to grab my source from me and take a stab at that idea. I currently wouldn't even know where to begin.

If YOU don't know, how could lil' old me ever do? I think I mentioned this before but the closest I've ever come to being a coder was a dozen (at most!) simple instructions in Amstrad Basic 30 years ago. Coding has always been chinese arithmetics territory to me.

[MadGypsy]

@Gem - thank you! I appreciate your response very much.

@bfg - I'm gonna say something but, I want to preface it with the fact that I fully realize this cannot be true for everyone. When I started this project I knew NOTHING about building a 3D engine and whereas I am pretty familiar with 3D from the blender angle I was practically illiterate in 3D in the "background" sense...ie everything that's going on in the background. Interleaved buffers and other such things were completely unknown to me. I have never had a "can't" attitude regardless of how complicated things might be. I don't know if you guys think I just sit down and start programming up a storm, or something but I can assure you I don't. I make one zillion mistakes, break the shit out of everything and then methodically fix the errors one at a time. It is entirely due to spike that this ever got off the ground. Everything he has ever suggested to me has been implemented. Every push he has ever given me has resulted in me becoming better at this. Once or twice he even totally pissed me off to the point of figuring it out so he would get off my back . I love him for that but, I digress. You might be the most bad-ass programmer on earth you just haven't found a passion, a reason, a fire to drive you through every wall and hurdle that WILL stand in your way. And on top of that you just need to find someone to give you some guidance when the challenges are over your head.

@hoping for better DP
You already have that, it's called FTE. I don't think you guys realize that nobody is ever gonna beat Spike at this. It's not gonna happen. I'm not saying that because he helps me. I'm saying that because it's painfully obvious. He might be the only guy here with a quake engine that REALLY knows what he is doing. That's coming from someone that programs in a hell of a lot of languages and has read a LOT of quake source code. Most quake sources are 50 or so files and IMO really sloppy. FTE is like Mt friggin Everest in size. It never ends, folders and folders full of code. That engine could probably even do your taxes with some cvar or something.

[MadGypsy]

I'd like to say that I appreciate all the participation in my thread tonight. Sometimes I feel like everyone couldn't care less about any of this. I don't let it kill my spirit but it is a bummer.

[Mugwump]

@coding Yeah, I know I could learn it if I wanted but I don't have enough patience for that! Plus I'm already involved in time-consuming activities like having a girlfriend, being a music composer and currently learning to map, so...

@FTE I haven't tried this engine yet but I've read a bit about it and my understanding is that it doesn't support as many enhancements as DP.

@participation I don't often comment here because when you get technical it's a bit like klingon to me. QuakeOne, unlike Func_Msgboard or InsideQC, is more a global community with some programmers but mostly simple users. I guess you'd get more responses at Func_...

[MadGypsy]

@FTE not supporting enhancements

I don't see how that can be true. Recently, Spike was working on a vulkan renderer and that's not even a thing yet. I mean, I don't know every square centimeter of FTE but, I'm gonna say it's not very likely that DP has more features than FTE. Go read the DP source and start counting all the times Spike is mentioned. In DP there are comments like:

//spike said setting this blah blah blah is bad

That doesn't sound like the comments of an engine that is more feature rich. That sounds like the comments of an engine that is trying to be better. Which is great. I should probably put comments like that in my engine. Maybe I'll even name my collision class Spike cause I'm just gonna steal his collision class. Mostly cause he told me to and other mostly cause IDKWTF I'm doing.

[MadGypsy]

@func_

I'm pretty loyal and whereas func_ is "on the same team" so to speak, this is the community that I joined. This community is the one I feel at home in. I have been here about 6 years (gettin close). I know everyone here to some degree or another and have a lot of respect for the grand majority of our members. func_ is like a completely different planet to me and I don't want to be on that planet. I wouldn't discount that that planet doesn't want me on it...lol.

I'll change my style a little for you and others like you so you can identify better with the material and have more room to participate. There will still be a bunch of klingon here (cause I'm programming in klingon) but I'll make sure there is lighter material as well.

[Dutch]

@klingon

Same here. When I read your snippets, I can usually make sense of what's going on, but the engine on a whole baffles me cause, I haven't jumped into this learning curve yet. But I will say I know a lot more of an engines inner-workings than I did before you started this. Take anisotropic filtering. I didn't have a fucking clue what this was, until you and spike started talking about it. So I started researching it.

Point is, is although I can't contribute much to the conversation, I don't think there's a single post I've missed and I'm just soaking up info here. Kind of like a groundwork or battle-plan on coding an engine. So keep those posts coming bro!

BTW nice job on the function explanations. It will be nice not having to crack open a big manual every time someone wants to use a function lol

[MadGypsy]

@It will be nice not having to crack open a big manual every time someone wants to use a function lol

honestly, I didn't even consider that there would ever come a time where someone else would want to modify my flash engine source. I put the documentation in for myself... and cause that's how you do it.

---

Speaking of documentation lets write some regarding what I see as the future of this engine. I decided that the flash version will not have any game code. This is because I am confident I can make it unnecessary BUT mapping will be far more complicated. Let's take a walk back in history. A few years ago I started rewriting QC from the ground up. I did it with a strong sense of inheritance in mind. a very generic example would be

MoveBrush extends BrushEntity extends MostGenericEntityEver
and
Player extends ModelEntity extends MostGenericEntityEver

I also started writing an ent file to accompany it, with entities like

MoveBrush
BrushEntity
ModelEntity
MostGenericEntityEver

You see how that works? It allows you to come in at the point that most represents where you need to be and of course the lower you go in the chain, the more stuff you have to set in the ent inspector. This pretty much allows you to make custom entities that represent whatever the hell you want. All of the above being said, I want to implement that concept for my flash engine. I know I recently said I have a broken QC replacement that I am going to fix but that was a "sidetrack". I thought it was awesome and I got excited about using it. The only problem is, it's not part of the vision I had. I'm sticking to my original idea. My next engine will absolutely have game code.

There is more to say about this though. Let's take a particle brush for instance. It would be RETARDED to have to fill out the ent inspector for every particle brush, especially since in many cases there would be duplicates. For those situations, we have my JSON solution. point_particle has one field and it simply expects the name of the JSON descriptor. You may be thinking "this all sounds well and good but how will you handle things like mdl animations?" ...JSON descriptor.

Between the map ent and JSON descriptors I am confident that I can make my engine "figure it all out". This has strong implications. In QC (like all code) you have to find every point where a thing needs to be modified. In my method there are only 2 possible places. The ent inspector and the json descriptor for that thing (if any, cause not everything needs a json descriptor).

There are 3 layers to web programming - Content(html), Appearance(css) & Behavior(js...). My system borrows from this concept. The actual map is Content. The info in the ent inspector is Appearance and the json descriptors handle Behavior (with very little exception). When you consider that all you need to do is recognize what group the thing you want to modify falls in and there is ZERO guesswork as to where the change needs to be made.

Anybody can remake a quake engine. I'm under the impression that most of these engines are just modifications of an existing one. I don't want to remake anything. I want to introduce completely new ways of doing things. I've already decided that this is my "figure it out" engine so why not make it a playground of ideas... things no one has ever done (respectively). In the case of my JSON descriptors I believe it is going to make modding very simple cause in most cases you can just open an existing descriptor, change some values and save it under a new name. I could even make prototype descriptors that have every possible value filled out and every single line is commented. In the case of doors, plats, etc there wont be a descriptor. Movement will be programmed directly into the engine and the type of movement you need will be set in the ent inspector. Everything will be "MoveBrush" and stuff like trigger will be a simple flag. You can make anything a trigger.

Anyway, that's where this is all going. The map editor will practically be the only thing you need to build games and the possibilities will be very open. I've had conversations here long ago regarding these ideas and I got some negative feedback. Stuff like "What mapper wants to need such a deep knowledge of the inner workings to make a map?" My answer to that simple - I don't know but I'm not building an engine for people that want to make maps. I'm building an engine for people that want to make games.