I’ve made the initial environment push to Section-1-Procedural. I’ve only left a few tools here besides the “security camera handler” and the base hangar environment. There are triple-quoted sections where I have implemented the procedural code initialization, but I have left all this code out for now until we can discuss where it goes in and how.
Update:
Thank you very much! 
Today I’ve been thinking about other ways to improve the movement behaviour, but I haven’t got any good results yet; I’ll keep working on it.
Joined! Thank you for setting this up!
Thanks for joining. Feel free to take your time with whatever you guys are working on; we’ve covered quite a bit of ground on Section 1. I think we’ll have clocked in several more months of development once the demo is close to finished.
Update:
I added four kanban-style projects to our GitHub group with initial to-dos. Now that we have this in place, I’ll try to keep the number of updates I make here down so we aren’t getting double-notified about stuff.
I have a question: How do I upload files to the repository?
The drag-and-drop web-interface indicates that “push access” is required, and when I attempt to push via command-line, I’m told that permission is denied.
As it’s the first time I join a GitHub organization, that’s what I’d like to know, too. Should we just fork the repo and create pull-requests? As long as we can discuss new ideas and content there as we add it, that’s fine (because wading through the posts in this thread is becoming a bit uncomfortable).
For example, I’d like to add a new “experiments” folder where we could put e.g. code snippets for showing proposed implementations of bot movement and the like. (My new version of the latter seems to work pretty well, by the way. )
Indeed, perhaps once we’re properly set up on the GitHub repository we should consider using this thread for high-level discussion and for showing our progress, with low-level specifics handled on GitHub.
This sounds great. I just gave Write privileges to members, so that should clear up any Push issues you may have been having! Sorry about that.
Also, good to hear that there has been some progress on the procedural code.
Sounds good!
Ah, excellent, thank you for that, and not a problem!
All right, I’ve just pushed an initial update to Section 3. (The first-person segment.) You should find it here:
This just a sketch, please note! There’s a fair bit yet to be done, both on the mechanics and the art. (For one, the current assets are all placeholders.)
Specifically, I realised that I had a nascent, set-aside first-person shooter project that I was willing to donate a modified version of. I spent some time simplifying it and developing it a little further, and the result is what I’ve now uploaded.
What it includes:
This commit also demonstrates a suggestion that I have for the section in question:
As a showcase section, I presume that this first-person experience is going to be fairly short–nothing like a full first-person-shooter. As a result, we perhaps don’t have the space in which to slowly develop the player’s arsenal. Furthermore, as a showcase, I imagine that it’s a desirable that the section be immediately cool.
Therefore I suggest that we skip over the traditional starting pistol, and move directly to more-interesting weapons.
Specifically, what I have in mind is what I’ve included as the starter weapon in the shooter-sketch that I’ve uploaded: a sort of low-power, high-rate-of-fire shotgun.
Sounds interesting! I’m not sure precisely what I would like to do on the space station section. It is indeed, likely to be somewhat short, but also the largest segment of the 10-minute demo (10 minutes nearly speedrunning it, without hanging around too much, let’s say).
I did get the following error when trying to run your submission:
from PlayerWeapons import RapidShotgunWeapon, BlasterWeapon
ModuleNotFoundError: No module named 'PlayerWeapons'
I am wondering if you will be providing .blend files for the project? It will be difficult to provide any assistance, including integration, if the original files are not present.
Ah, right you are! It looks like I deleted that file by mistake–sorry about that! ^^;
It should be there now!
I don’t think that I’ve given it much thought, to be honest. The assets included in this section-3 sketch are just stand-ins, and I haven’t really contemplated the making of final assets overmuch, I think.
But as to those stand-ins, I think that I included egg-files, which should be convertible to bam or some other format, I think.
As to PAnDA, I’m not yet sure–it’s something that I’m considering, at least!
Got it running! These look like nice mechanics for the FPS segment. I am open to doing Section 3 with the built-in collision system for the FP character. It seems possible to use Bullet for some bits of the space station environment and the built-in system for others (like the character and hallways).
Maybe we should do a little concept art for the station. There are a lot of possibilities there. Do we want an industrial, realistic look, or something rather more stylized (purple metal for instance).
It’s up to you of course. I have no issue respecting the artwork of original authors, even if I have “editorial” access to it. Indeed, I’ve done this professionally! No worries though, either way.
Thank you!
I tend to default to the built-in collision system when I don’t have a strong reason to switch to Bullet.
However, it likely wouldn’t be hard to convert the current code to Bullet, I imagine!
It might be worth settling on an overall artistic direction, I think.
For myself, I still like the science-fantasy approach: a mix of magic and machinery; of crystal and runes with circuits and moving parts.
That’s how I’m currently approaching PAnDA: beneath the black-and-white outer cover, brass moving parts can be seen, while various areas sport pale crystals. Such crystals again make the automaton’s eyes. And of course quite prominently visible is a large crystal sphere in the hollow of PAnDA’s “belly”.
So that’s the aesthetic that I submit for consideration: brass and crystal and circuit-lines that incorporate runes, and so on.
Of course, if others prefer pure sci-fi (or pure fantasy), then we can go that way indeed!
That’s fair. It’s something that I want to think on further–and in any case, PAnDA is still some way from being done!
I have a few thoughts here. One, is that I would be 100% satisfied with a good implementation of sci-fantasy aesthetics. I’m afraid we don’t have enough time to make a compelling, sterile, space opera I am also, a designer, not really an artist, though I can fake it. : /
Well, the Star Trek ships did sort of run on crystals! I can’t help but to think of a futuristic version of Dishonored 2 reading your descriptions.
The hangar environment we’re starting with is basically just science-fiction. The starship is a rocket-powered spacecraft in it’s initial model form. We could change this to incorporate both worlds – a loud, colorful rocket powered takeoff and some integration of magic like FTL based on crystals. Aiming for fun-to-play, of course.
In all fairness, this is one thing worth mentioning: standard sci-fi would likely be easier.
And indeed, if we want to keep the current (non-stand-in) assets as-is, then we’re currently leaning towards sci-fi.
I haven’t played Dishonored (1 or 2), myself, but from what I’ve seen it’s likely not far off, indeed.
The main thing here is the matter of consistency–the aesthetics should be consistent throughout. So in general I would suggest that there be elements of whatever aesthetic we choose in pretty much everything. (Save anything intended to stand out as different, of course.)
So, let’s say that we wanted to go for “iPod-style sci-fi”: all clean white and smooth curves. We could still have a gritty hangar–but we might want some terminals with that white aesthetic (but perhaps smudged due to the environment), and there might be cable conduits in a similar style running along the walls.
In the case of the aesthetic that I proposed, I think that crystals are likely the easiest touchstone for the fantasy side–imagine a row of them along the rocket-ship, trailing coloured light. Conversely, circuitry and brasswork would be a good touchstone for the science side–imagine a magic wand with brass moving parts and glowing circuit-lines trailing around it.
(This is part of the approach that I have in mind for weapon-models: Think technological-looking weapons, with odd forms and glowing circuits and crystals.)
(Also, TV Tropes has an article on “science fantasy”, including a neat page-image!)
Hilarious and also – let’s not. To be more specific, your descriptions are so accurate to be amusing – and I don’t think it’ll be too much of a burden to incorporate a more visually complicated style.
Your mentions of brass, metals, crystals – I think would be a good fit for our current Metallic PBR system.
I was wondering about that. There is a case to be made that too many art styles (IE, one for each Section) would be time-consuming for us and inconsistent for the player.
I feel we should clarify the issues here:
We need to practically pick an art direction for the demo. I’ll be clear for the sake of professionalism and admit I’m not too keen on medieval fantasy. I have played through Dishonored 2 three or four separate times, and I think that the game is graphically way up there. So it’s not that I’m totally against a medieval-cyber-magic aesthetic, it just doesn’t come naturally to me from the perspective of a designer.
I recognize this could be a make or break issue for the success of the demo. If we’re not excited about a shared aesthetic idea, that’s potentially not good.
My hope is to unite the two aesthetics in way that isn’t offensive or ludo-logically inconsistent to either core aesthetic. I think I’d draw the “fantasy” line at dragons, as in, I don’t think it’s possible to merge a sci-fi SSTO ship and a dragon. It’s too far in both directions, I fear. A single stage to orbit spacecraft has to be designed to a very specific standard in order to make it to orbit. The aesthetic of the SSTO craft is defined by its compliance to the extreme atmospheric conditions of space traversal. An artistic spacecraft, maybe with non-rocket propulsion could fit – but this would lack some of the drama and gravitas of a powered rocket launch, I imagine. No engine sounds, no rocket flare, no realistic climb to space. It would be a different demo. I didn’t necessarily intend for my first starship model to be used in production, but it was of course a reflection of what I thought of the original demo plot inspirations.
I’m not really an artist. My game design inclination is to make a mechanically satisfying simulacra of a possible real-life situation. This makes me a simulation programmer, or a designer. With this recognition I may not be able to tie-break an aesthetic clash; I can see the value for certain people in both aesthetics. I’ve seen Richard Garriot argue that sci-fi was too hard to implement back in the Ultima days, so they went with medieval fantasy. This may or may not be the reality of the thing. A modern sci-fantasy demo could indeed be the coolest direction we could go in – though, we have to agree what that means. A large spacecraft flown by a robotic panda, materialized out of pure energy by drones, and then taken to a space station overrun by robots is already pretty fantastical from a certain perspective.
That’s fair!
Agreed, I believe: I do think that it’s important that we pick an aesthetic that we all enjoy.
And to be clear, I do like sci-fi aesthetics. (And fantasy aesthetics, and sci-fantasy aesthetics. So I may be the easiest to please of the group.)
Regarding PAnDA, let me note that it wouldn’t be hard to make a “pure sci-fi” variant, I daresay. I’d simply strip off the crystals, recolour the brass to steel, re-texture the central sphere, and replace the crystal eyes with LED-like hemispheres, I imagine.
(I’d still make my sci-fantasy version, I daresay–but I’d simply leave that as either a suggestion for a general sample-character (like Ralph), or if not desired there, as a model available in my own “sample-model” repository.)
You say that, but Michael Swanwick had dragon-jetfighers that actually worked really well. (And which were at times mildly horrifying. Let’s just say that they were not nice.)
Similarly, the Discworld novels give us a (swamp-)dragon that rearranges its own innards to produce a rear jet-thruster, by which it flies under power, as I recall.
I honestly don’t think that there’s any fantasy element that couldn’t be incorporated. It’s just a matter of how it’s done.
Not necessarily. Well, the “realistic climb to space” bit, perhaps–but then I suspect that eventually humanity will find technological means better than the “apply as much force as we can” approach to getting off-planet.
More to the point, magic can provide quite a bit of drama and flare, and there’s no reason that using it to launch couldn’t require a lot of energy.
In short, a magical launch could be just as ponderous and impressive–it might simply use different effects. (Or the same effects, but from a different source.)
It’s fantastical in the way that high sci-fi generally is, but it’s not really “fantasy” in the usual sense, I’d argue.
Too strongly worded on my part maybe – it’s definitely possible to do such a thing, it’s art after all, but the dragon would rather distract from how I view the drama of a spacecraft (which, I acknowledge, is a personal taste sort of thing). Still, nice references, point taken. Here’s another example of a fantasy starship – Yggdrasill | Hyperion Cantos Wiki | Fandom
Good to know! You have presented your case more in the fantasy direction, but maybe that’s to balance Epihaius and I seeming to lean towards more conventional sci-fi.
I wonder if differences in art styles are partially why the Panda community hasn’t made a collaborative demo like this in the past. I’m committed to seeing the project through, but aesthetic differences in taste like this are tough! It’s hard enough for a regular studio to stay interested in a project they’re being groomed, paid, and managed for – leave alone an international team of indie devs with differing art styles.
Still, I think we agree on the overall goal here, which is to exercise the engine and show it off as a way to signal to new developers and artists that “Here lies opportunity to realize your creative vision”.
That’s fair. And indeed, I suspect that a degree of compromise between our varying tastes is likely to be called for.
That is very cool indeed! Thank you for that!
(I’m reminded of the movie The Fountain, which includes a more fantastical version of that, which is being flown to a dying star that’s about to go supernova.)
Indeed, that is likely. (Well, that and the fact that my general leanings are much more towards fantasy than sci-fi.)
It’s possible–but it’s also possible that it simply hasn’t often been suggested before. And further, that collaborations like this can be somewhat fragile: without the additional ties that other types of project may have, there’s a significant risk of contributors losing interest and drifting away.
Indeed, I do think.
[edit]… Actually, that spawns an idea: Perhaps we can have our cake and eat it too.
Consider: What if each section of the demo (perhaps barring the first two) is separate from the others, each in its own little pocket setting. Instead of simply moving in the ordinary manner from one to the next, perhaps the protagonist hopes through portals from one to the next, with the implication being that they’re stepping from one world to another.
That would allow more freedom of individual aesthetics–and also perhaps make for a showcase that better communicates that a variety of visions can be depicted in this engine.
I’d like to think this is the case.
Even in creative domains, most people show up to work for the paycheck. Conversely, some of the best work and physical contributions I’ve ever seen were by volunteer communities. I wouldn’t put volunteer work at a lower expectation level, necessarily – I certainly don’t mind volunteering a few thousand hours a decade.
This may, indeed, be what’s called for. The project scope immediately inflates, but this idea of a “many worlds” version of the demo seems appealing.
To add to this a little – we already have several quite separate ways of developing programs.
These would be difficult styles to integrate cleanly, I think we can all recognize that. .egg doesn’t support the way textures are handled by simplepbr, for instance, and we’d need to compromise on that if we wanted .egg to work with, let’s say, my environments .
Beyond this, it may be a better showcase of the engine if we just show a myriad number of ways to achieve the same basic game, instead of pouring all our resources into a single aesthetic.