[GENERAL]Ah, MMO's. Addicting as hell. I'll be blunt and honest with ya, I haven't touched Sill development since my last blog post back in April (surprise surprise)...Luckly, I am in a slum moment when it comes to playing LOTRO (or any mmo for that matter), so I got some time/motivation today to work on Sill.
[SILL]Not much new, but I finally got those INI functions in. I essentially covered the basic INI support documented here:
http://en.wikipedia.org/wiki/INI_file I originally was planning to add all the extended support listed, such as nested sections and multi-occurrence parameters...but in the end, it was becoming way too complex to, not only build, but to use. So I scrapped my entire old system and went back to the basics. (or the motto, keep it simple, stupid) I got the entire support running in about 5 hours.
So....according to my original development log schedule, this means my API is essentially ready for some type of beta phase or public showing. However, I'm going to hold off on all the 'pre-beta/public beta' stuff. Why? Basically, Sill is still a little rough/difficult to use for my desired target audience and I'd like to have my first beta phase to be somewhat pleasant to new users.
Right now, the function based setup is rather straight forward and is working well, but the setup of objects and events, when it comes to larger projects, is just a plain old mess. To add a new object requires a user to update 3 different cpp files (header for global prototype .cpp usage, .cpp for actual declare and .cpp for the actual event functions) before an object resource can be used (assuming a multi-cpp project)...this means anytime a new object is required, the programmer has to do a lot of back tracking...I need to find a way to make this easier.
One thing I have been seriously considering (but not moving forward with) is to make a GUI editor program which does a lot of the hard work for you (such as when adding resources). Something along the lines of Game Maker, but without the interpreted design. Instead of compiling an EXE, the editor would output everything as .cpp files, which could then be passed to a command-line compiler.
Pros:
*I could design the editor to be very user friendly, customizable and with enough effort, seamless to the user so they don't need to know what a 'compiler' is or all the delicate workings of raw Sill C/C++.
*It would promote faster development since a lot of the low-end code would be taken care of. Adding an object would be simple as two clicks, rather then manually editing 3 different files.
*Could add in background optimizations, and other features, to the program down the line.
Cons:
*It puts a lot more work on me, delaying not only the release of Sill, but my own games I'm creating using Sill.
*It requires that a 3rd party compiler be bundled with the editor (for a seamless setup).
*Multi-platform support (such as Linux and Mac ports) would be severely hampered/delayed and would require separate builds to maintain.
*It may actually end up being more confusing to the end users. The editor may obscure some of the finer inner workings of Sill that developers might need to know or work with in advanced projects. Also, if I can't seamlessly compile the outputted .cpp files, users may not understand what they need to do to actually get their game to compile/work after pushing the 'export' button in the editor.
So far, the cons are just too heavy. The amount of work required to make a seamless solution to a Sill style editor is just too great, not to mention I have absolutely no experience using command-line compilers/linkers, etc. This is why I have been trying to come up with a solution using C/C++ directly, so that I can avoid having to do all the extra foot work of a conversion layer (simple GUI to raw code), while advanced C/C++ users would still feel right at home using Sill as their development platform.
Anyway, I'll end my recovery blog post on that note. Maybe tomorrow I'll get some focus on where exactly I want to head with this project.
~Brandon
Dilber MC Theme by HarzeM