The Orbsphere universe is based on a notion I’ve been kicking around for what is now over a decade. The first primary (and solid) features started to exist around 6 years ago, and have been clarifeid with some pretty critical thinking.
In terms of a strategy game, it’s still on the cards. There’s something based in the universe which I’m pressed to do (or test) first.
The current strategy model is trending towards 2D-top-down hex-tile-based non-military expansion. Oh, right, and planets in space. Not planetois, just, pretty simple stuff for now … but, again, I’m pressed to try something else first ;)
I found my year 8 maths exercise book, which brings back the original Orbsphere design specifications from a decade ago (yes, I kept the book because it has the design specs, not because I like introductory algebra). It may not sound that exciting, but for a game that was originally designed to be a webgame, a lot has changed in rethinking and desk checking.
The biggest problem I have now is that I’m still not a programmer, and 3D graphics seems to be a bit of a “must”.
A lot of secrets to be held, but the notion of a scripting engine may be out the window due to another potential avenue of expansion (one that removes the conflict between modding and DLC, but still keeps the game open enough that it’s not a huge problem).
More to come later :)
Due to my experiences with Tropico’s engine, I’ll probably be moving to Lua.
This isn’t to do with replicating their code (honestly 99.99999% of it has no place in my code base), but it opened my eyes to concurrency and the notion of “open buildings”. While the games are fundamentally the same premise (city-builder/simulation/strategy), the substantial difference arises in scale, and in that Tropico allows you to tune into people.
I have some plans to handle “people to leader” communication and various other things, but I will not be rendering the people. Sorry for those who were interested from an early, early, early discussion, but it’s expensive to process, render, and compute, rather than generalising it a bit more.
There are other realisations, like that I wish I could ban certain people using their DNA because they complain too much or otherwise demand features for other games that by no means fit, but the obvious solution is to make it singleplayer only, and to hand control of their own destiny over to them in a way which is simple enough for them to be able to use it without a functional frontal lobe, but complex enough to let me make the game.
Back on track for mass-modding, but the shape has changed with some 3D experiments. As usual, don’t expect anything too flashy for a long time.
Preliminary tests on mod code turned out successful today. It has been the better part of a week spent on moving code to Python, with the majority of that overcoming strange build issues (OpenSSL was the latest victory, yielding access to ssl and hashlib).
The potential success may yield a lot more … I’ll keep updating, but development will likely hit a wall as a few interfaces will need to be rewritten to take sane Python binds, and that’s fairly tedious code (they were previously coded to take a set number of resources, and the mod codebase doesn’t tie you down on resources, so it needs reworking).
Over the last 2 days (~30 hours), I have pulled out all of my manual loading code from the C++ code. I have, in its place, embedded LibRocket’s Python, Boost::Python, and some of my own binds. This has set me back in that I have lost the ability to switch contexts (‘screens’ in my code) for now, but I have changed up some of the workflow:
- Contexts are created in Python and then located in C++ (the opposite direction never seemed to work for me in Python, and this way I can be sure that Python is pulling a valid reference);
- Documents, Fonts, Cursors, etc., are now to be loaded, hidden, shown, etc., in Python (by the ‘loader.py’ file within the mod);
- The core mod’s UI files are now within the core mod’s folder;
- Localisation and images will remain in the assets folder;
- I have created a ‘mods-shared’ folder for shared assets (e.g. the fonts that ship with the game, which are Apache 2 Licensed, will live in ‘mods-shared/fonts’).
There remains a substantial amount of work to complete this overhaul, but it will mean unparalleled (I hope?) modding potential, using only Python and an image editor (and some HTML/CSS style coding for the UI).
The scripting language is Python 2.7.2. Whether I continue with Python 2.7.2 or move to Python 3.2.x is a matter for consideration (just to be sure that Python doesn’t update away from what I want, you understand). Python is integrated in a way that would make it a terrible idea to swap out the dll or so file… sorry, but there are some changes that will happen that will be problematic, and I need to update too much.
I’m now porting a lot of my core code to Python, and adding binds for the core engine. Why? It makes my life easier, and exposes more of the game to modders.
What I’ve done since the last updated:
- Pushed Python into the engine, thrown out the V8 test code;
- Started scripting the first test AI for same-game concurrency;
- Started making room for additional features (a mixture of DLC and free updates);
- Started contemplating how per-achievement code can be realised through Python binds (seems to be quite easy);
- Read a bit about binding boost::Python in LibRocket to enable direct UI to game code binding (to bypass a whole host of internal nightmares) — and seriously considered it!;
- Moved more and more of the base engine to conceptual Python for modders;
- Added modding launch support to the CLI (which will remain disabled until I iron out the remaining bugs).
So a day on, this is what I hope modders will get from the game:
- The ability to edit the UI’s look, feel, including images, positions, etc. (except for the system render location, which will remain in the middle — sorry);
- The ability to edit commands (by writing wrappers in Python and executing them in the UI);
- The ability to edit, delete, update, tweak, every core aspect of the experience (including buildings, tech trees/research, resources), but not game modes (i.e. excluding planet counts in a system, and game modes, which are too heavy in calculation and update);
- The ability to add local achievements for the mod you’re creating (but not modify the core achievements, which remain locked down, if all goes well).
This should make it fairly easy for modders to sink their teeth into a different kind of game, but at the moment it’s still wishful thinking.
Orbsphere has seen some pretty exciting updates, and some pretty exciting changes in the development plan.
The following image is the latest mockup:
There are some modifications made to that, and the whole thing is sprite-based, so that I can keep my dream of running things on lower-end PCs alive.
I feel it has a nice mix of shine and function without too much compromise.
At the moment I am planning on some modding features, primarily so that it makes my life easier, but also so that modders can sink their teeth into something if they’re interested. Notably, the game is still single-player only (with a possible multiplayer expansion if I can get netcode playing nicely).
Available Modding (currently):
- User Interfaces are entirely modifiable (thanks to LibRocket);
- Images (spritemaps) are entirely modifiable.
Things I would like to expose (on the wishlist, or in progress currently):
- Further customisation to spritemaps;
- Resources (purely for modders, so that they can add/remove things);
- Custom (Mod-Specific) Achievements (this is ambitious);
- Custom Artificial Intelligence.
That said, there are a lot of things left, that I won’t explain until things are either further along, or more stable.
Having thrown in the towel to do some testing, I’m finally getting back to the final concept.
This version will be a great deal more complex than Prelude, but properly a lot uglier to make it run on an EEEPC, even with the AI (should I ever get around to that :P).
Due to a bunch of issues with the current engine, I’m forced to write my own.
This will cause several delays and I’ll be putting Orbsphere proper aside while I work on the new engine for another game (the underlying bits are much the same, and it’s very modular).
Anyway, the good news is it should be on Desura soon:
In the meantime, check out the main site for a download link — that’s right, Orbsphere: Prelude is free.
I had an issue with large integers recently. I’ve since patched it to allow for a new maximum score well beyond the previous arbitrary limit of 1,000,000 (limited for reasons I couldn’t fathom). The existing patches didn’t work me, so I devised something a little more creative, and the new maximum score will soon be: ((10^3,999,992) - 1). I could probably increase this a bit (to ((10^39,999,992)-1)). Notably, the current maximum score is 1,000,000 (though it recalculates), which only left the population bugging out on extended beta tester saves.
This new patch will roll into play for all large numbers (even numbers that really should never get that high), and will require some significant rewriting of display and storage functions to ensure that the data is not lost on save/load.
The code used in this patch has been tested, and only works for simple adding and subtracting (notably the overhead for multiplying anything past a googol would be fairly substantial and I’m not looking to set systems on fire!).
Edit: Okay, it turns out that I could push it to ((10^59999988)-1) if I’m prepared to make changes. That should be enough of a hint to those who want to know what I’ve done ;)