Game Engine Forum - Grit Open Source Streaming Game Engine
Site Header
It is currently Thu Sep 20, 2018 1:42 pm

All times are UTC




Post new topic Reply to topic  [ 91 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Wed Feb 04, 2015 10:29 pm 
Offline
Newbie

Joined: Fri Jul 26, 2013 5:30 am
Posts: 141
http://51lica.com/wp-content/uploads/20 ... dition.pdf a ai book you should read


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Thu Feb 05, 2015 4:31 am 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
I have no experience with Unity 3D, but if it is similar to UE3, yep, that's my idea

this explains why I'm taking so long to do the basics of the editor, i'm doing a lot of things around the level editor itself :Aw:
but, here is an update on the most basic tool of level editors (not so good yet, but works)


after that i think that i need to build the content browser, to add the objects on the scene (like a file explorer, that show declared object classes)

and then I will submit these updates to the svn

thanks for the ebook :)


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Thu Feb 05, 2015 7:11 pm 
Offline
Supreme Tyrant of All
Supreme Tyrant of All
User avatar

Joined: Sat Mar 27, 2010 1:13 pm
Posts: 769
Did you commit a version that doesn't require rebuilding the core engine? I'm sure lots of people will want to give it a go but that was a road block


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Thu Feb 05, 2015 11:57 pm 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
Yes, now it will be all written in Lua 8-)

also you will can enter and quit the editor at any time typing include`editor/init.lua` or selecting exit in the editor menu


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Sat Feb 14, 2015 8:24 pm 
Offline
Supreme Tyrant of All
Supreme Tyrant of All
User avatar

Joined: Sat Mar 27, 2010 1:13 pm
Posts: 769
I tried loading it today but some of the files are missing `` for the includes. Do you have a fixed version you haven't committed yet?


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Sat Feb 14, 2015 10:15 pm 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
i haven't committed yet, just a tiny update removing old files :)


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Sun Feb 15, 2015 9:34 pm 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
I committed a "stable" version of the editor, but, you may find many bugs, like these:

* the widget translation is very inaccurate
* when translating/rotating a object it may explode (i don't know if i can disable physics for a specific object), also the widget "ghost" moves a little bit the object
* you cannot disable physics when translating/rotating an object, because the widget is a physical object
* the widget size isn't "constant" anymore, grit doesn't support physical object scale
* opening a map, or browsing objects you may find many bugs on the window:
- icons freezing caused by a failed attempt to open a corrupted map (just open another folder and come back again to solve [i will probably add a "refresh" button])
- you can't see the icons displaying nicely because i used a hack to only show icons inside parent
* opening a window/menu for the first time something strange thing will appear for a millisecond
* exiting editor will take a long time until all hud will be destroyed
* sometimes the mouse can stay moving when you are not pressing right button (just click again and move the cursor off screen to solve)
* the "racing_game" game mode example is not really good, need a lot of polishment

And a few notes:
Start the editor with the command include`editor/init.lua`

Many buttons are transparent, these tools are disabled

"Event editor" isn't included on this commit

Maybe i will remove the env cycle inside the map file, because uses plenty of space (replace with external files)

Set your spawn point with GED:set_spawn_point(position, orientation), or move the green mesh representation (or just click play and move the green representation)

The content browser only shows declared objects, if you see something missing on the list you probably need to include it before, and then "refresh" the window (opening the folder again)

When exiting Grit, and opening a map you may get many errors, you need to know that you first need to include all your assets before opening a map (or you can just add these "includes" on the level properties[left side pannel button to open this window])

When not using the editor, you can run your map directly by just typing include`yourlevelname.lvl`, all game mode and so on will be started automaticaly (an easy way to test how your game is going without using the editor)

Don't want to use the editor level file format? Just click on "save as", select Lua and then you will export your map to simple lua script

Want to start your own project? Create a script inside 'editor/gamemodes' like these examples inside of it and set this script name (without extension) in your map

I didn't test all things on Linux, but the last time I do all is working

If something in the editor stop working, you can exit the editor and enter again, you map will not be lost (or, to make sure, you can save it manually: GED:save_current_level_as(name))

Maybe I forgot something, but..

Video

Have fun! (if you can deal with the bugs) :P


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Mon Feb 16, 2015 7:04 am 
Offline
Moderator
Moderator
User avatar

Joined: Sun Apr 04, 2010 3:59 pm
Posts: 59
Just saw this on twitter and though I should login to comment. I think this is great, good job and keep the good work! :up:

_________________
Image


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Mon Feb 16, 2015 1:54 pm 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
Thank you :)


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Mon Feb 16, 2015 11:07 pm 
Offline
Supreme Tyrant of All
Supreme Tyrant of All
User avatar

Joined: Sat Mar 27, 2010 1:13 pm
Posts: 769
It may be worth separating the definitions from the objects in each map, i.e. split init.lua into definitions.lua and map.lua. Then we can put code in system/init.lua that will do common, vehicles, and then all the other dir/definitions.lua automatically.


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Mon Feb 16, 2015 11:46 pm 
Offline
Supreme Tyrant of All
Supreme Tyrant of All
User avatar

Joined: Sat Mar 27, 2010 1:13 pm
Posts: 769
local loadmap
if(pcall(function()loadmap = loadstring(level.map) end) ~= true) then return false
end


Instead of doing that, you can store the function () end directly in the map file

level.map = function ()
object "foo" (x,y,z) { ... }
...
end

That way you only need to call level.map() to make those objects, no need for loadstring()


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Tue Feb 17, 2015 12:33 am 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
Quote:
It may be worth separating the definitions from the objects in each map, i.e. split init.lua into definitions.lua and map.lua. Then we can put code in system/init.lua that will do common, vehicles, and then all the other dir/definitions.lua automatically.

Yeah, that would be great 8-)

Quote:
Instead of doing that, you can store the function () end directly in the map file
level.map = function ()
object "foo" (x,y,z) { ... }
...
end

I'll do that :)


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Tue Feb 17, 2015 5:25 pm 
Offline
Supreme Tyrant of All
Supreme Tyrant of All
User avatar

Joined: Sat Mar 27, 2010 1:13 pm
Posts: 769
I'd like to hear more about your vision for where this is going. At the moment you've done a whole lot of stuff here, and in particular those hud elements should be useful for all sorts of things (maybe they should go into /common/hud). And the ability to move / rotate objects with the mouse is very cool. You also have a concept of a "level" which didn't used to exist (beyond some sort of map.lua with a list of object definitions). Although, it's not quite clear what will ultimately comprise a level. At the moment it's a list of objects, env cubes, sky cycle, clock settings and some metadata, right?

Here's a brain dump:

One thing to look at is whether it can replace the level editor functionality in Blender. I had wanted to do that because it would be a pain having a level editor in every modeler (Blender, Max, ...). At the moment Blender is the only one that can really export more than just plain .mesh and .gcol, in that it can export maps and classes. With your editor you can now build maps but not classes. I wonder if it is even appropriate to build classes in an editor because they can contain custom code and other things that are hard to represent visually.


In terms of integration with the engine, we clearly want this to be available by default (without having to include editor/init.lua) and it should be cleanly integrated. I figure that ulitimately there should be 4 modes:

1) Not in a game (just showing the menu)
2) In a game (can still have the menu up if you press esc but can then go back to the game)
3) In the editor (all physics, audio, animation, and game logic disabled, objects locked to starting positions, probably some extra stuff for visualising audio emitters and the like. It's possible we might do more, like disabling fog, or whatever. You can go to the menu and back here.
4) Debugging, i.e. running the game logic as if it were a real game, but with the ability to easily go back to the editor (resetting everything) at any time. You can go to the menu and back.

So transitions between 1 and 2 are easy. Transitions between 3 and 4 and back are easy but you lose your state. Within 4 we would still want a way to go to the HUD and back for various reasons, but that wouldn't be the same as going back to the editor. So the presence of the HUD / mouse lock is not tied to the editor.

Disabling physics and game logic in the editor will fix your exploding cars problem, and generally I think if you're building a world you don't want that behaviour. We can add a special feature for positioning objects according to their physical interactions though, which would be useful for stacks, parking cars on hills, etc. That could be just setting spawn location to current position from 'debug mode'.

The transition from 3 to 4 is a bit like your "game mode" but that might not scale in general because depending on the game being designed, there may not be actors / cars / whatever. Someone might be making an angry birds clone or lemmings. What you want is for the game to come to life in whatever way makes sense for that game, so you can test walking up areas / through doors and make sure it actually works.

So it might be enough just to go into some sort of "ghost mode" that has some extra capabilities to make debugging easier. For example you can have special debug weapon that does things like create temporary objects, create particles, light fires, and generally allow arbitrary experimentation. And we can configure that debug weapon via dialogs in the HUD, e.g. pick the class to spawn using your existing browser, pick whether to create / fire / drive the object, what velocity to fire it at, if it's a car, should it be parked or not (or just have a special mode for toggling car parked status). You can imagine these things accumulating so it's a pretty powerful concept. That may be more general purpose than having a finite set of "game modes" because you can choose where you spawn and what class you're using on an as needed basis. It also means you don't have to configure / save that information because the user can just set it up as needed each time. And if you do want to have a fixed "start location" you can just place a vehicle there and then 'enter' it from debug mode (that can be a debug weapon too). When you go back to the editor, all of that stuff would vanish because it's not part of the actual level.


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Tue Feb 17, 2015 9:03 pm 
Offline
Newbie

Joined: Sun Feb 01, 2015 1:20 pm
Posts: 4
Hi Augusto,

I'm sure that if this editor will become stable and will include functions like logic brick system and animation importer from blender, a.i system for cars, a lot of people will migrate from blender or unity.
Now I'm trying to do an simulator game like mafia 1 in blender and there are a lot of problems there.

Thank you. :number1:


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Thu Feb 19, 2015 1:26 am 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
Yes, currently the level doesn't have so much stuff, just the essential, but I will improve that with: (some ideas)
"level events" - what happens when you touch a trigger or when the level start, or end and so on.., (almost done, but I need to find some time to do what is missing)
This is a complex part a little bit, initially my idea was that in the editor you use the "logic brick" (sorry, I don't know the right name for it, I call it "LevelEvents" [UDK call it kismet, CE FLowGraph, Unity I don't know]) to create your events, and for the game these structure is used for generate a lua script that is embedded at the bottom of the level file, that is executed when you start playing or adds "level functions" that triggers can call at any time
But, when implementing that I change my mind, and find a way that it can be done in another way, like all "logic briks" are level nodes, so, if the "Level Start" node is triggered, then all childs are triggered too, so, the "in-level" code will look like some tables and values, that can be used by the editor and also by the game, but in another way

"level variables" - Used by the "level events", and also by anything else, stores per level variables that can point to a value or a level object, so you can easily use them to manipulate these variables or objects by the level event nodes and also delete them all when you change your level (for level transitions)

++ These level events and variables will also be useful for open world games, all different areas can have a "custom" structure of level events, so the whole map is like a lot of maps in a matrix, that loads them dynamically (but is a very recent ideia, needs some polishment)
(also load some other event structure can be nice, like not per level, but loaded at any time by the game)

"cinematic stuff" - keyframes to animate a door, move a platform, play character animations..

I think that we can have another tab on content browser to see .mesh and .gcol files, with a button do create simple classes for them (left side panel, I was thinking in adding some other panels, for adding like triggers or additional classes [I explain bellow])
example:
Code:
class `myObj` (ColClass)
{
   castShadows = true,
   renderingDistance = 500,
   gfxMesh = `myObj.mesh`,
   colMesh = `myObj.gcol`
}

This can be the result by selecting two files, a gfx and col mesh, and then clicking the button to create that class using these files
My first idea was that you can drag a .mesh to the viewport and then the editor automaticaly creates the class, but isn't so good because the class needs to be stored somewhere (maybe not in the editor, but in the game)

Fully integrated with the engine using diferent modes is a very cool idea 8-)

My idea for the "game modes" was that the file is the start point for a project, you can put your other code anywhere you want and then include them in this game mode script.
The game mode itself just include these additional scripts and define what will happens when you play and what happens when you stop playing (these two examples spawns a new object in a defined position (spawn point) and then start controlling this object (also set your custom binds))
And my objective for these game modes was that you can play different kind of games just by including the map file and nothing more.
But, thinking a little more, is not a good ideia for big projects, a little waste of resources for who don't want more than one game mode, but I need to think another way to do that

I can remove completely the spawn point like the way it currently works, and add it like and additional class, that you can use only if you want it for your project
These "additional classes" are editor classes with special behaviors, like what to do when start playing or stop playing..(hide in game, show in editor..) or anything you want
Maybe I can create something for the game developers to easily expand the editor itself for add some specific (per project) extra features that needs to work in line with the editor (like adding new windows, tools..)

I have already programmed some things like weapons and inventory system, but isn't finished yet, so, when I finish them I can create that debug weapon ;)

Icra, that's would be great :)


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Sun Feb 22, 2015 5:15 am 
Offline
Supreme Tyrant of All
Supreme Tyrant of All
User avatar

Joined: Sat Mar 27, 2010 1:13 pm
Posts: 769
Since we already have the ability to script behaviours like those, I don't think it should be a priority to introduce another way of doing it on top of the existing way. There are a number of things that are worrying about graphical approaches to programming as well, and this goes for mission logic as well as shaders and other things:

* They are always less powerful than language based approaches
* Simple things look nice but complex things are a mess of boxes and lines, and hard for others to understand
* They don't play well with version control systems (patching in changes etc)

I really don't think the benefit is worth the cost, compared to more low hanging fruit like the basic functionality of a level editor. The cost is high too -- you are inventing a programming language, which is the most challenging and risky thing you can ever do.

The very first thing to do if you really want to do that is to get the basics in order, and implement a whole lot of realistic cases, like elevators, doors that open, that kind of stuff, and do that in basic Lua. Then we learn a lot about how things are done with Lua and where the pain points are. We may be able to fix them at the level of Lua (e.g. using coroutines or changing the framework in various ways) but if that doesn't work then there is the possibility of using a higher level language. But if you don't do that initial work you don't really understand the problem space and success is then impossible.

Quote:
"cinematic stuff" - keyframes to animate a door, move a platform, play character animations..


So modellers are already pretty good at that, but the current idea is to model a single mesh at a time in the modeller, so the animations would be for the skeleton of that mesh only. For animations involving multiple bodies / objects, it might be necessary to have something in the level editor, but it's quite a lot of work and those kinds of animations I think are in the minority, especially since simple ones can just be coded up in Lua.

Quote:
I think that we can have another tab on content browser to see .mesh and .gcol files, with a button do create simple classes for them (left side panel, I was thinking in adding some other panels, for adding like triggers or additional classes [I explain bellow])
example:
Code:
class `myObj` (ColClass)
{
   castShadows = true,
   renderingDistance = 500,
   gfxMesh = `myObj.mesh`,
   colMesh = `myObj.gcol`
}

This can be the result by selecting two files, a gfx and col mesh, and then clicking the button to create that class using these files
My first idea was that you can drag a .mesh to the viewport and then the editor automaticaly creates the class, but isn't so good because the class needs to be stored somewhere (maybe not in the editor, but in the game)


It's not so clear whether a class belongs in a map, and what to do about classes that are not part of the current map (e.g. are common or shared).

Perhaps the problem is that classes tend to be a bureaucracy in many cases, and maybe we should be thinking about eliminating them for simple cases like scenery etc. In that case, you may not have to worry about editing classes at all, because cast shadows, rendering distance, etc, could all be given as object attributes. The only people making classes would be people who are writing complex logic, e.g. vehicles and so on.

Quote:
My idea for the "game modes" was that the file is the start point for a project, you can put your other code anywhere you want and then include them in this game mode script.
The game mode itself just include these additional scripts and define what will happens when you play and what happens when you stop playing (these two examples spawns a new object in a defined position (spawn point) and then start controlling this object (also set your custom binds))
And my objective for these game modes was that you can play different kind of games just by including the map file and nothing more.
But, thinking a little more, is not a good ideia for big projects, a little waste of resources for who don't want more than one game mode, but I need to think another way to do that


Something like that is necessary but I don't think it's really relevant for the editor. You can imagine the editor is simply for the world, and the actual game logic is something else that uses the world that is output by the editor. That way you are limiting your scope and can focus on doing just world editing really well.

When we have an actual concrete game, we can figure out how to start / stop it, what winning means, etc., at least for that game. When we have a few games we can try to generalise it, and at that point it might be worth having something in the editor but it really depends on what we come up with.

Quote:
I can remove completely the spawn point like the way it currently works, and add it like and additional class, that you can use only if you want it for your project
These "additional classes" are editor classes with special behaviors, like what to do when start playing or stop playing..(hide in game, show in editor..) or anything you want
Maybe I can create something for the game developers to easily expand the editor itself for add some specific (per project) extra features that needs to work in line with the editor (like adding new windows, tools..)


It may not even be necessary to have an actual spawn point. I can imagine the editor being able to drop you into the game from your current camera position and just falling to the floor or whatever. That ought to be enough for debugging aspects of the level, like whether you can jump up things or whatever. Having a spawn point would get in the way for this kind of task because you would spawn somewhere else and have to walk/drive there.

To be more clear, I'm proposing there are 3 modes -- editing (where everything is frozen), debugging (where things are alive but you have lots of special powers and there is no real game happening) and playing (where usual game rules apply). Clearly the common case is going to be toggling between editing and debugging, and when you do that you want to stay local to the place in the world you were editing.

The most general purpose thing to do might be to, when you choose to debug, have the editor throw you into ghost mode at your current position. At that point you have a whole bunch of tools to allow you to spawn a car / character in order to test various things. So, you don't need extra code in the editor to create those things. Moreover, you have the ability to abandon / delete that car and make a different kind of car, or generally do all sorts of things that you wouldn't be able to do with a fixed spawnpoint with a fixed set of capabilities.


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Tue Feb 24, 2015 6:20 am 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
So, then i will remove/abandon completely:
Spawn Point (useless)
Event Editor (better with code)
Cinematic editor (better with code)

Now i think that I understand your idea, basically there is 3 modes, 3 independent modes, so you can move from editor, to game or to debugging, and vice versa from any one, at any time, not resetting the camera position at any one
(currently from editor you can play, but if you press esc you return to the editor, on the editor camera position)

evolving the ideia a little more, and thinking a practical way to implement:
On all modes, exists a menu that you can open pressing a key, you can select the other two modes (a subtle menu, that can also be opened inside editor)

On the editor you have a complete Content browser, and on debug mode you have another content browser, but more simple, just to set what to spawn when you use your debug weapon

The debug mode can have a little inventory, with key bindings to 1, 2, 3.., so you can drag a object to the inventory slot and spawn it when pressing the corresponding key

Grit without any loaded mode needs to be clean, without any HUD element or specific bindings, unless what is shared between all the modes, like the modes menu, debug layer and console (but can have the base of debug mode, like camera move or other simple things)

Each mode needs its own constructor/destructor functions, what to create when starting and what to destroy when exiting, including key bindings (I know how it works on player_ctrl.lua, but I don't know exactly how it can be implemented now with the editor)

how the in-game mode will be defined? (I mean, if you create a specific game, like racing, FPS, or TPS, or any completely different game, you will need to find where it is and modify the player_ctrl.lua file?)

Let me know if I understand right and if these are not dumb ideas :)


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Tue Feb 24, 2015 8:35 am 
Offline
Site Admin
Site Admin
User avatar

Joined: Fri Mar 26, 2010 10:06 am
Posts: 440
I'd think you will still need the spawn point for playing the game, even if you "play from here" in the editor, the spawn point is going to be needed, among a host of other things that should be handled visually and absolutely NOT be handled with programming. There are hundreds of things games need that get reused and that programming is a waste of time for. You code it once, and make it placeable behavior. If it needs to be different, that's up to the users to edit.

Anything that negates the need for code and lets users define in-editor with nodes or whatever else to define events, is good.

Event editor is good.

Look to unreal 4 for inspiration and guide. Especially blueprints. Just be less redundant and bloated than unreal.

The more a level designer can do without programming, the better.

A project to focus on would inform your development.

That project should be a GTA III, VC, SA game clone. Because that covers basically every game one can think of. It doesn't mean we should copy everything, or that it should behave exactly the same, it means that in a broader sense - GTA has vehicles, has player, has lots of things that are in every game. Every game has a player controller. Not every game has cars. hence GTA engine was used to make Red Dead Redemption and Bully. And those titles benefited from vehicles, like with the first car being in RDR, but just unplayable as the player.

Clone the behavior of GTA III into a placable editor. That is the golden path. It will later expand to be like later iterations and come into its own personality depending on a given project that uses it. But make a REPLACEMENT FOR GTA MODDING that is BETTER THAN GTA MODDING. Without focusing on negating programming unless someone wants to customize a behavior or add, no one has a reason to use this engine. They can use unity or unreal, or just keep modding GTA and other games like skyrim. Make it like modding a game that already exists, just with access to source code is the key and golden difference. That means, place checkpoints/mission triggers. Be able to build mission templates which are generic and can THEN be later edited in the code generated (even if completely rewritten, the placable indicators indicate to programmer coords for things, and informs them of what they are supposed to be accomplishing and expanding in code, what was laid out by a designer to save them time and solve problems on their programming before the task is even given).

Don't fear about a cluttered screen full of boxes and lines. Just make each one hidable. "Here is a collection of triggers for a mission. And here is the checkbox that hides and unhides each of those data structures".

Programming is for engines. Programming for the games developed on those engines is quickly becoming archaic and counter productive. Program the engine. Let users make games without programming, and let the programming be only for customizing a project to be different than what is supplied.

If you clean the map out of GTA games, you have a whole game, just waiting for a map and a mission script. That should be what grit is, what it was meant to be, and not focusing there has meant 8 year of a scene viewer that no one has joined in on because GTA gives them results. Skyrim gives them results. That is our target. MODDERS becoming DEVELOPERS and GAINING FREEDOM from EXCLUSIVE LICENSES is the only sensible target for this engine. People who already consider themselves "game developers" are not the target end user of a game engine. They are targets who should be brought to help make the engine before it reaches the end user. The target end user of an engine is not a programmer in the majority, and only a few programmers should ever be needed. Otherwise, they may as well roll their own engine, and not even download grit.

If we can't tap into an existing, unanswered market of people, then look forward to another 8 years of working on an engine that doesn't have any projects.

There is no motivation to use this engine. It's a scene viewer with some basic, non-practical interactive elements. Where is the handling.cfg? Oh, there is no vehicle system, just scripts for single vehicles - horribly bad workflow. Horribly bad priorities.

Clone GTA III. Make an editor that lets you place triggers and do template missions. Then watch the hands come and help. Otherwise, I'm sure it is depressing to hear, it depresses me to say it, but nothing will change in the next 8 years either. And people still won't know about grit, because it still will not be solving any actual problems for people, and they will rather keep modding existing games, and never evolve.

This all comes from real conversations with people and what they want to see and why we don't see them here.

Look to the target audience, and you'll find that this is all true. If people find it false, then the target audience is probably not being considered. :P


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Tue Feb 24, 2015 10:11 am 
Offline
Newbie
User avatar

Joined: Fri Mar 21, 2014 12:25 am
Posts: 116
Location: Rio Grande do Sul
Brian, I agree :)

Removing these things may be just temporary, anyway my intention was to keep developing them, for personal use. But I can finish them and show exactly how it works, and then we can discuss if we can include on Grit or not

I'm actually more an artist than programmer, so I know how it is hard to do simple things without knowing so much of programming

GTA like engine is exactly what convinced me to download Grit for the first time (also Lua and Bullet).


Top
 Profile  
 
 Post subject: Re: W.I.P. Grit Level Editor
PostPosted: Tue Feb 24, 2015 5:46 pm 
Offline
Site Admin
Site Admin
User avatar

Joined: Fri Mar 26, 2010 10:06 am
Posts: 440
Great! I was worried driving the points passionately came across as something else at first.

Sounds like a great plan. I have loved all the things you've been doing and spark has been doing.

Here's an idea, too. Can you already spawn cubes of arbitrary size in there? Forgive me if that was previewed and is already there, but, for example, this would be really really great for pre-visualization blocking in.

So like, lay down some roads and land and make the baseland and import to engine, then anyone can make arbitrary cube-blockings of skylines or other buildings and stuff like that and gives people something to paint over or just to model based around, informs on what to do next. Cubes are a cool tool.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 91 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Localized by Maël Soucaze © 2010 phpBB.fr