The trouble with that is that the editor would have been useless after a month. As the game is developed often things have to change to make things work.
Edit: Software development is a whirlwind of changes and refactoring. Building the editor first might save some time initially because you’ll be able to quickly perform common actions. However, as the game features change and evolve, the editor has to evolve right alongside. This creates lots of additional work and probably wouldn’t be worth it until those types of changes really slow down.
how is it additional work if the goal is to provide a mod-able game with an editor? My suggestion nets out to less work but more of it front loaded. Once the editor is done, making the game becomes trivial. (I armchair dev in this forum a lot and I rather not, so I’ll just stop here.)
The additional work comes from changes. Let’s say the editor is fully built and the game is being developed. One day Radiant decides to add enchantments to weapons. Now they need to go into the editor and make it support enchanted weapons. This isn’t that bad right at the start. You added a feature and updated the editor.
Except now let’s say the enchantment feature changes three or four times because it was unbalanced, was incompatible with some other new feature, or just sucked and needed redone. Each of those changes requires you to also change the editor so it still works. If you build the editor at the end of the game, then you don’t have to go through all those changes and you just get to do that work once.
It sort of comes down to budget and time. With a small team on a limited budget, they can’t spend the time making changes to the editor all the time when they can develop pretty quickly without one. Plus, maintaining an editor might increase time between alphas from 1 month to 1.5 months. Over ten or fifteen alphas, that adds up to an extra 5-7 months! Might be a bit extreme, but the point is that everything would take longer. With a larger budget this might be OK, but I think Radiant has found the right balance between making the game moddable and making the game moddable with really awesome tools.
Except for maybe a few things (test worlds!) I think most people would prefer features first, modding tools later.
You misunderstood what I wrote… it sounds like you haven’t done much interactive programming. If the editor was written in the engine, most of your arguments don’t make sense.
There are many old school games with editors built into the engine, if it’s done properly it is LESS work. It’s really that simple. There is a huge body of evidence for this in computer science literature, the history of REPLs and smalltalk/squeak are good things to google if you’re interested.
I have been working in software for 17 years. Using REPLs/interactive development is just faster. When tooling a system from the ground up, it is often times worth it to build tools first… this is just common sense really, look at any wood shop. But because this game is being developed publicly and crowd funded the best technical solution is not always the best solution for the problem at hand. As evidenced by the lack of scaffolding in mines, for example. I really like the game so far, and I respect that a lot of hard work is going into it… but that doesn’t change which methodology is known to work better.
Not saying you’re right or wrong, but if (when?) Radiant Entertainment make their next game, they’ll at least have the experience of Stonehearth to know when they might want more specialised tools like you suggest.
However, I would say that, notwithstanding the devs’ experience in non-gaming software development, they’re still learning a lot on the job as it were. I would be surprised if their efficiency does not improve in their next title, and indeed improve during the development of Stonehearth itself.
Yes and no. While this seems like a rather primitive but sane flow (create tools, use tools to build other tools, use other tools to build final product), it wouldn’t have worked. I don’t think there wasn’t a fixed, precise software design in the beginning (and there doesn’t need to be one for a game, in my humble opinion) so creating an editor would have proven difficult.
While having an editor might would speed up development, it’s nowhere as useful as having actual gameplay. We’re talking about plaintext assets here: lua, JSON, HTML, JavaScript, CSS - it’s not like to change a model we all have to open a hex editor and flip bits. Creating and editing assets is easy enough - surely it could be easier, more comfortable and all that, but it wouldn’t justify the effort. I don’t think Radiant would have, in the course of their development, saved more time using an editor than building and maintaining it in the first place.
On top of that, having an official editor will cause more work (not only maintenance but also support) and it has the danger of becoming dependent on the editor, as in “Well, we can’t improve our entity system because somebody would have to rewrite the editor/because the editor uses way X”. Without one, you don’t have those issues.
I tend to sound more negative than I intend to. I would have done something else personally, but I rarely finish my coding projects so their decision seems completely reasonable to me
I still have a TON of work left on this, but I thought this would be fun to tease!
I’ve never worked with 3D in my life, so this is a lot of fun. Coming soon hopefully: particle editor. Whether or not it’s useful, it should be neat to play with.
That looks pretty good . If you could make that we can change the model displayed in the viewer, it’d be awesome (although that’s integrating effect files besides cubemitters…)
I can’t wait to see people making fireworks, waterfalls, bubbles, rain, petals, glows, tornados, feathers, snow, smoke…
Look at my unfinished fountain :
And sorry for the low fps and lack of shadows …
It’s the beginning of a lot of things. Right now it’s a mod manager. Its soon to be a particle system editor. I’ve got some other ideas as well bit they all revolve around modding tools.
SHED is a standalone application and is compatible with all mods. It will only break if Radiant changes something major about how missing in general works.
I think he meant our mods, that usually break between releases (not always, but there’s always a file that needs tweaking or something, especially when they introduce many changes)…
I would love to add the ability to launch awesome tools like StoneVox or Jofferson from SHED. Unfortunately, I think all of us use different technologies so doing any sort of combination would be a lot of work…maybe one day!
The additional work comes from changes. Let’s say the editor is fully built and the game is being developed. One day Radiant decides to add enchantments to weapons. Now they need to go into the editor and make it support enchanted weapons. This isn’t that bad right at the start. You added a feature and updated the editor.
. If you could make that we can change the model displayed in the viewer, it’d be awesome (although that’s integrating effect files besides cubemitters…)
:
…