As you may have heard (probably not because no one reads this anyways) my Kickstarter failed!
I had a particular roadmap planned out to reach video production gameplay goals for the Kickstarter campaign but now that the campaign has failed I have had to re-evaluate what features I need and in what particular order.
Had I been able to fund my project I would have proceeding in particular direction and had considerably more resources available to me.
Now that those resources are off the table the question at hand is given this is a single player RPG can I go to early access?
I feel that going to early access with part of my single player campaign is a fairly bad move - players will grind through that rather quickly and then be crying out for more content that is going to take a considerable amount of time for me to produce by myself.
Doing that would hypothetically result in an initial good release but would be followed by a lot of negative feedback/reviews from customers who might not be happy with my pace of updates.
User created content can far outstrip my personal ability to produce content ; but without a level editor there will be no user created content! Given this I felt the best way to proceed forward would be to pivot my focus towards the level editor.
The first step of doing this was to tackle a task I had been putting off which is to "refactor" the level editor into a much more manageable architecture.
I had designed it on a 'as I need' basis and literally thrown functionality in anywhere I could to get things moving for the Kickstarter.
But now I need the Editor code to be solid and easy to work with in the sense of extending it and adding new features, but also in the sense of troubleshooting/debugging any issues that come up.
So I spent approximately the first 30 days after the Kickstarter refactoring all the core level editing functionality to point at the Level Loader class.
The Level Loader of course .. was meant to load saved levels in to the game. But as you can imagine as you are editing - you are literally loading a level ... on the fly!
Previously I had "on the fly" editing being done in an Editor class, and final "in game" loading only in the Level Loader.
There was also another type of loading which was "inspector based loading" where you get into the individual details of any one grid square and change those details. This represented a 3rd place code lived to load elements of a level.
So after refactoring all this - all loading is done in the LevelLoader now!
Having achieved this I then added several new features which I demonstrate in this video:
- ability to have an in-game preview window
- ability to toggle to a full screen gameplay mode
- ability to drag & drop monsters in to the game
- ability to toggle a skylight for ease of editing or previewing actual dungeon lighting conditions
- new create level dialogue with configurable elements
- a new player arrow icon - with a emissive texture to make it easy to see regardless of lighting conditions
Other work I did that is not shown:
- refactored the save/store/loading of levels into the local users directory structure ; this ensures users can save their levels to disk where they have permission ; it also gives a default place where I can look for levels to load that the user has created
- added ability to set custom save level names
- added loading dialogue that presents a drop down list of all levels available to load
- fixed quite a few bugs
- refactored the GUI to be more streamlined/minimalistic (more work to do here in the future)
So my next set of goals is to add even more functionality to the level editor; some of these additions should happen pretty quickly because they are just similar to functionality that I've already demonstrated here. Other items of course are more unique and will require specific work to implement.
Thanks for reading, see you next time!
I had designed it on a 'as I need' basis and literally thrown functionality in anywhere I could to get things moving for the Kickstarter.
But now I need the Editor code to be solid and easy to work with in the sense of extending it and adding new features, but also in the sense of troubleshooting/debugging any issues that come up.
So I spent approximately the first 30 days after the Kickstarter refactoring all the core level editing functionality to point at the Level Loader class.
The Level Loader of course .. was meant to load saved levels in to the game. But as you can imagine as you are editing - you are literally loading a level ... on the fly!
Previously I had "on the fly" editing being done in an Editor class, and final "in game" loading only in the Level Loader.
There was also another type of loading which was "inspector based loading" where you get into the individual details of any one grid square and change those details. This represented a 3rd place code lived to load elements of a level.
So after refactoring all this - all loading is done in the LevelLoader now!
Having achieved this I then added several new features which I demonstrate in this video:
- ability to have an in-game preview window
- ability to toggle to a full screen gameplay mode
- ability to drag & drop monsters in to the game
- ability to toggle a skylight for ease of editing or previewing actual dungeon lighting conditions
- new create level dialogue with configurable elements
- a new player arrow icon - with a emissive texture to make it easy to see regardless of lighting conditions
Other work I did that is not shown:
- refactored the save/store/loading of levels into the local users directory structure ; this ensures users can save their levels to disk where they have permission ; it also gives a default place where I can look for levels to load that the user has created
- added ability to set custom save level names
- added loading dialogue that presents a drop down list of all levels available to load
- fixed quite a few bugs
- refactored the GUI to be more streamlined/minimalistic (more work to do here in the future)
So my next set of goals is to add even more functionality to the level editor; some of these additions should happen pretty quickly because they are just similar to functionality that I've already demonstrated here. Other items of course are more unique and will require specific work to implement.
Thanks for reading, see you next time!
No comments:
Post a Comment