why did u stop BlitzMax and start on different language?

[iWasAdam]

With your "all made manually" approach, how would you create 100 differents plates (like in my "hidden items searcher finder" game) with each plate having a different text ? same comment for the text on messageboxes... 

OK. I'm not going to say one method is better than another, just provide 'my' answer to the plate issue above:
1. You are never going to have 100 different plates (in basic look), so I would probably use 3 different meshes for the basic plates.
2. any mesh can be rendered with any color. so lets say there are going to be 8 minor variations in color
3. Lets assume that we are going to map some textures to the plates to give them some more variation. lets give them 5 variations

(we are already up to 120 possible color/shape/texture ways)

Text is irrelevent as is messagebox as they are attachments to the 'object' and rendered separately <- that's how I would approach it

How would you modelize the (all different) caves that i am currently making ? in a modelisation software ? try it and see how quick it is...

Me personally, I would break down the caves into the minimum that I needed and work from there. Usually the first things would be a floor, a ceiling, and a wall plus corner.

The issue you are really raising is about 'difference': cave A 'looks' the same as cave B.
For any generative system, unless you have loads and loads of time and skill. it will always 'look' the same after a few different caves. That is why a lot of games use partial pre-made and generative system together, or drop generative systems entirely for one that looks and feels 'right'.

The best example of Procedural content done completely right - but ending up completely wrong is the recent "No Mans Sky" monstrosity. "wow, it's all different. wait a minute, it's all the same. oh gawd this is a load of crap".
And the reverse of that is "The witness". Beautiful on every level.

So how does CaveA not look like CaveB?
* The first is design - so you start to need to have procedural systems that are programmable and give different results - that still feel 'right'
* dressing - each cave must have a very different visual look, color, type of rock, moss, etc <- your now getting into procedural fixtures. but they have to be directly related to the first design so they feel 'right'
* does it have water. is it dry. is it cold, etc
What you are actually doing is writing systems that interact with each other and after a few caves the player will be "Meh, seen it all before... NEXT!"
And that is before you try and make sense out of puzzles - which usually end up being hand crafter, just because a human can do it far better than a machine can.

To recap:
caveA = blue cave with hidden room, etherial sounds emanating from a crack in the wall. when you get near you hear a mystic voice saying "beware the Creme Angaise"
caveB = rock cave with one end going down to a submerged room containing a treasure chest
caveC = many small chambers connected together forming a maze. at the center of the maze is a bottle with the words "eat me" written on it
caveD = arid dry cave with sand piled along one wall (not sure if the sand is red or pale buff colored yet) with some painted stuff peeking out. further investigation shows the location of a second cave plus lots of scorpions pop out of the sand

With that list and a set of minimal resources I could reuse and create all the different caves with the same stuff and a simple map tool.

how would you create a volumetric glow effect depending on the shape of the item ? how would you create volumetric rays depending on the color of the grawings of a window ?

hmmm. volumetric - nasty stuff. not a problem. just use a particle glow at the same position of the mesh
volumetric rays - I've not got any god rays in my renderer, but if I was faking it, then I'd again use particles. In both cases you have complete control over alpha, color, etc

[Derron]

Dunno when I used 3DS Max the last time - might have been in the early 2000s ;-)
Am using Blender since 2.3x or so. Tried to do things with Poser a decade ago - but was too much "for artists" than for "make your own" people.


@ RemiD
As with all missing effects: you need to do this on your own then. But as said: you do it in a way that it allows to "attach" things each to another. So if you had a "god ray" effect, you might also add a "swirling dust effect" to that so particles swirl around.
If you follow the rules of the toolkit then you, the artist, whoever, is able to setup these things in the toolkit editor - seeing things previsualized and so on.

For "one time effects" this is often meaning "doing more than needed" but with the second time you need this effect (of course here and there adjusted) then things start to pay out. It surely depends on the scale of your project or how many projects you want to do with it. it is similar to the discussion we had some weeks ago - about "finishing stuff" instead of writing tool after tool for it and making things overly complex just to allow a user to colorize the buttons in your game.

Nonetheless: if you had a layout editor for the gui stuff of your game, then you would not need to run ...adjust ...run ... your game until the buttons are looking fine. For GUI apps RAD tools were accepted or do you do it all the hard way manually adding buttons to layout containers ?
(I only do that for dynamically created sub windows).


bye
Ron

[RemiD]

I would break down the caves into the minimum that I needed and work from there. Usually the first things would be a floor, a ceiling, and a wall plus corner.

That's exactly what i did to build each cave, but then if you don't want to cause slowdowns, you want to merge the parts which share the same material / texture and are near each other (what i did : each area is one mesh with one surface one material one texture), or if you want to alter the structure of the surface in order to make it more different (like the "outlines heights" or "irregularities depending on normals"), you also have to be able to analyze, modify, merge, surfaces...

But i agree that there are several ways to build a map, in the past i have coded a map editor which used premade meshes / textures (Unity users call these "prefabs") and then you position / rotate copies of these premade components.

For some cases this works, but not for all cases.

[ENAY]

RemiD, you can keep going on and trying to convince everyone that doing a mesh is more difficult in Unity than Blitz. I think all of us can agree with you on this point.
If developers are THAT intimidated by 3D, then that just leaves less saturation for people who can and want to make 3D games and are able to use Unity.

Does it really matter in the beginning how easy it is to create a mesh in Unity, when at the end of a project, compiling to various platforms or getting conversation, feedback and debug reports from an active community (industry standard) of programmers on various topics?

That part is a lot easier than Blitz, and perhaps you could say, more important than how easy it is to create primitives in native code?

If you have a complex issue that broke Unity by say, a Windows update. You can be sure that it will be fixed, and with haste. Now if something breaks or gets deprecated in Blitz, can it be fixed? Who will fix it?

Unity is not THAT MUCH harder to use than Blitz, although of course many things you could easily do in Blitz are missing in Unity. That's just life I'm afraid.

[RemiD]

you can keep going on and trying to convince everyone that doing a mesh is more difficult in Unity than Blitz. I think all of us can agree with you on this point.

i just don't understand what is the advantage to complicate the language, that's all. And as a lone / indie dev, the simpler / faster it is to make progress, the better...

when at the end of a project, compiling to various platforms or getting conversation, feedback and debug reports from an active community (industry standard) of programmers on various topics?

of course, i agree

If you have a complex issue that broke Unity by say, a Windows update. You can be sure that it will be fixed, and with haste. Now if something breaks or gets deprecated in Blitz, can it be fixed? Who will fix it?

me, or a coder that i will hire to fix it (or i will end up using blitzmax + openb3d)

[ENAY]

I suspect Blitz3D does the exact same thing as Unity, except those calls and traingle construction are just wrapped into a neat function and hidden from you.

Mark dipped into all the horrible parts of 3D math and C++ so we didn't have too. Unity is somewhere in between I'd say.

At any rate, I can't help think that there are better things to worry about in the programming world, other than which language can create primitives with fewer lines of code.

[RemiD]

I suspect Blitz3D does the exact same thing as Unity, except those calls and traingle construction are just wrapped into a neat function and hidden from you.

@ENAY>>most likely yes. And that's what "Blitzlike" (a Blitzbasic "wrapper" for Unity) did.

After a quick look at some tutorials, creating a mesh, a surface, vertices, triangles, in Unity is not so complicated after all (more than in Blitz3d, but less than in AGK).

Anyway !