Fair enough, I can understand all viewpoints expressed in the thread so far (with the exception of TGS's 'nil' expectations for this game -- come on now!)
No game or engine screenies -- I'm still not graphically back to where we were previously (meaning I haven't brought all of the rendering and shader tech over to the new platform yet)...have actually been focusing a lot more on the gameplay side of things, and can I just say (I think I've already said this)...it's an absolute
joy writing gameplay code in augmented Python (yes, this was going to be revealed in the 'proof' anyway) as opposed to C++.
I use dropbox for my version control (wait, what?). Yeah, seriously, consider it: I have like 4 different machines at the moment, and I need code to be current across all of them. At the same time I need the ability to rollback. Dropbox makes both easy (you pay an extra $15 or something like that per year to get an entire year's worth of version history regardless of how many versions there are or how big the file is....that's kind of amazing). The moment I save a file it's as though I've committed a new version, which is immediately available on other machines. Yes, this is awesome for a solo developer. No, don't try this on a team or many people will be angry.
So for your 'proof' I just printed out two simple version histories, one for ltheory.py (the entrypoint that basically launches the game without doing much else) and one for pyengine.cpp (please DON'T start using the name 'PyEngine' to describe what LT runs on because that's a temporary name!!) which is the entrypoint for the 'compiled' part, which, as I've explained before, basically configures and sets up what you now know is a Python interpreter, and injects facilities for graphics programming as well as JIT magic for pulling any of the performance-critical python down to native. Those histories, or rather, a few pages of them -- dropbox does a scrolling load thing -- are attached. Incidentally I did edit them both earlier today, despite the fact that these two files don't change much in comparison to the directory structures (hence the gaps). Most of what I do now is adding components (all of which are part of a module), data structures that are part of gameplay, shaders, etc. So most of my change is actually adding to the directory structures (no, sorry, not going to give a dir tree! Too many secrets
). In some places I actually have code that automatically scans a certain directory to load assets (this makes both dev and modding easier! For example, to create a new component that can be added to an in-game object and give it some kind of behavior, all you have to do is write a new code file (yes, .py) in the component directory and, if you did things correctly, you'll be able to call object.add(MyNewComponent(blah, blah)) without changing code anywhere else!
I know a few of you will now undoubtedly have reactions to the fact that I've just revealed the game language to be Python, (yes, I'm sorry Flatfingers...I am...), but please keep in mind
- Huge, huge, huge amounts of thought went into choosing it over all the other options I had on the table, and after a lot of going back and forth, pro's and con'sing, running different tests, I was able to make this choice with full confidence.
- Performance-critical code will not run in Python, so restrain the knee-jerk "oh noes it's going to be slowwwww" reactions (I mean, I would have that reaction if a dev said he was using python for a serious game...until he mentioned native JITing )
- The 'magic' mechanism is of my own coding, this is not pypy or psycho or Cython, this is Josh + CPython. I chose this route because I believe it represents the widest spectrum of performance-devtime trading capability. None of the above, with the exception of psycho (which is now abandoned), could routinely perform as well as native code (Cython comes closest but it doesn't have as much runtime information to work with as I do ). On the other hand, since it's CPython, it's a full and complete implementation of Python 2.7 (yes, 2.7, not 3.*, another calculated decision), meaning no restrictions or quirks. So in your python functions, you've got as much 'expressiveness' as you can possibly have. In your python functions that are marked for native conversion, you've got as much speed as you can possibly have (although you do lose a bit of expressiveness, naturally).
Yes, I was waiting to drop the P-bomb because I knew I would need to provide some comforting words with it
So, those of you who plan on modding LT can run off and start learning Python (2.7!) now
And those of you who want proof that I work on LT, check the pdfs. If those aren't enough (because it's definitely worth my time to forge version histories??
), hang tight. I will try to get graphical 'proof' of the underlying progress as soon as I can
Once again, I really appreciate you guys being patient with me. It's been a longer journey than I ever imagined, especially in terms of my own state, but it
is converging