Greetings everyone; I’m Schmendrick, and this is my first post to the front page, here. Adept asked me nearly a month ago to make this post, but that cursed animal, “Real Life,” intervened, and I spent a ridiculous amount of mental energy at my day job tracking down a threading error (if you don’t know what that is, trust me, it’s bad). You may also have noticed that it’s been a while since Ravenger has posted; life seems to have come down on him even harder than it did on me. But we won’t let these setbacks get us down; we’re still here, even if we are a bit set back.

As noted in the post below, we’ve chosen two concept artists; one for the aliens and one for the hardware, and right now we’re still working with the second artist to come up with a good “look” for the Ironseed ship. Adept posted one of the sketch plates below; here is the other.

We’ve already got a few personal favorites, but we’d like to hear what you, the fans, think! Head into the forums, vote for your favorite, and talk about the ships.

The ships (click to enlarge):

We poured over +100 submissions and have finally made our choices. Pedro Medeiros will be our creature artist and Mark Taihei is our ship/tech concept artist.

Here is a recent render Pedro constructed for the Sengzhac:

First Sengzhac concept. Booyah!

You can see more of his work here:
http://saint11.carbonmade.com/

And here is a recent set of ideations for the ship itself from Mark:

Second page of ship ideations

You can see more of his work here:
http://iviarker.blogspot.com/

Thanks for being the first members of the new Ironseed art team. I’m looking forward to see what we can do together!

We’ve gotten at least 40 portfolio submissions. There are some real world class talents in here. I thought I knew for sure who we were going to choose… and while we’ve narrowed the tech/ship artist down to two or three candidates we’re still very much conflicted over the creature artists. The primary difficulty comes from the last minute decision to consider getting a 3D artist to completely model each species. If you’re not already aware, high detail models ARE REALLY expensive… but we want the art direction to be internally consistent and consistent with the vision we have for the game, so it’s something we’re considering. If we can find someone who is talented, but willing to work with us on price that may tip us toward 3D models… but its a tough call.

Feel free to comment if you guys have any feedback.

When you’re an Indie Dev shop it helps to have friends. I’ve got one who’s a crack Marketing maven and she’s agreed to help us out as much as time and patience permits. She’s doing research right now into when and where to start announcing the game’s progress and what not. These kinds of things take forever to build so I thought it made sense to attack the PR issue earlier rather than later. We’ll let you know where to look for the articles that get posted about us when the time comes.

We’ve had several replies to our posts about concept art needs on ConceptArt.org. We’ve got two or three great artists that we’ll be reaching out to soon. Should hopefully only be a couple more weeks before we have some first sketches of the ship to share with you. Unless their work turns out to be bollocks in which case we’ll reach out to more artists and do this all again.

It’s exhilarating to see the flurry of activity around this project.

It’s late and I’m hungry. Time for some fried chicken from KFC.

The 3D engine used by Ironseed uses a rendering method known as a submission model. The 3D engine itself doesn’t understand the organization of data, only how to render primitive types to the screen. This means that the user of the 3D Engine is responsible for maintaining and organizing the 3D objects in a way that makes sense to the user as well as optimizing and controlling which objects are sent down to the rendering engine to be drawn.

To do rendering, the user of the 3D engine needs to implement a Render Listener. The Render Listener is given to the camera to render. As the camera flows through its logic, it periodically makes callbacks to the Listener for data requests. So when the camera begins a render, it notifies the Listener to start adding objects to the camera’s render queues. This is where the Listener has full control over which objects and what order they are rendered in. In the case of Ironseed, the Listener iterates through the actors in the world, culls them by the camera’s view frustum and actor’s bounding box, and adds the resulting visible actors to the queues. After the queues are populated, the camera starts notifying the renderable objects to draw themselves. For Ironseed, this is another chance to apply custom rendering to the objects before Ironseed asks the assets to render. Ironseed will apply shaders and debug drawing as needed.

Many people assume that a 3D program just throws all the triangles at the video card and the hardware does the work.  In reality, the video card is fairly stupid and does exactly what you tell it to do, including bad things.  The card can do some simple optimizations such as clipping offscreen triangles and backfacing triangles.  It’s still better to have the engine decide that a model is off-camera and not even send it to the card.  Bounds and camera frustum testing can be expensive and there are many ways to avoid even needing to do the test.  For example, the world can be broken up into different areas and each area knows if it can be seen from the current area (this is done in a preprocessing step, not in-game). 

The second major issue with letting the card blindly render is transparency.  It’s generally better and faster to render front to back.  Anything occluded by the objects in front will not even be drawn.  For transparency, it is necessary to render back to front so that the transparent object blends with the objects behind it properly.  The engine needs to be capable of determining the order to render objects for maximum efficiency.  The 3D card will properly determine the depth so that one object is behind another but not the proper order.  My 3D engine uses the render queues to group the objects together.  The normal objects are rendered first, then the transparent objects sorted by distance, and finally the objects that want to be rendered on top like debug and UI.

I feel like I make no progress and then all of a sudden a ton of stuff gets done. I guess that’s the nature of iterative design. I’ve got to make another refactor pass over the engine and that’s always tedious but necessary. As I do more of the screen, patterns emerge. For each pattern, I go back and clean up the engine, making it tighter and more powerful. The next few screens go by in a flash and then more patterns emerge. There’s work being done all the time but the number of lines and completed screens don’t reflect that. I estimate several more months to complete the first version of the rewrite. It really depends on how much time I decide to spend on things like planet generation and experimenting with scripting. It’s hard not to stop and try to make some of the graphics better. I know it’s a lost cause but I just can’t help adding a shader here or some effect there. Every now and then I do run into problems converting the old 2D stuff to 3D. It takes some creativity sometimes to replicate some of the palette effects and manual video memory manipulation in 3D. For example, fading in and out is now a post process effect instead of setting palette colors. Lots to do but it’s fun!

So I finally upgraded the forum.  It had been 3 years since I allowed new users because we were totally overrun by spam bots.  I finally updated the forums and migrated all the previous posts to the new setup.  Let’s hope we can stay up and accept new users for a lot longer than the last time.  If anyone wants to volunteer to kill bot users if we start getting overrun again let me know.  I can use the help.

More to come.

Hopefully this will explain the scripting architecture a little better:

Ironseed is built on several layers, giving us more flexibility and abstraction.  Nothing talks directly to the implementation, only though interfaces.  We can easily swap out one engine for another if we want to later on.  The diagram isn’t 100% accurate since there’s a lot more going on here than can fit into a simple picture.  The actor component system is very similar to Unreal’s system but with a number of changes.  The concept is the same however since it really is a good idea to associate graphics, sound, physics together into a single unit.  Ironseed itself is broken down into data manager, ship, UI handling, and contexts.  Data managers deal with the static data like the 30 odd crew members, descriptions, portaits, and initial stats.  The ship object is your basic save game with all the instance data such as the crew members you’ve chosen and their current level and experience points.  The UI handlers deal with mouse and keyboard input and window management (mostly handled by Qt).  And finally contexts are various mini worlds in the game.  Each screen is a little world with current state.  Only one context receives input and draw requests at a time.  And finally, there is the scripting engines handled by Golem and a new-undetermined scripting engine.  I’m personally leaning towards AngelScript at this time.  The scripting will be built on top of Golem and the ship/data managers.

In an ideal world, there will be no code in the contexts.  The contexts will be a combination of layout scripts (XML), golem scripts (called from the game logic scripts), and game logic scripts.  The game logic scripts will be able to manipulate actors in the world, run animations, play sounds, access data managers, etc.  Complex animations will be golem scripts.  Any long running operations will also be golem scripts – I don’t want the scripting to block.

As much as I hate scripting, scripting gives us so much more power.  We can reload a context layout on the fly, modify scripts, run scripts from a console, whatever, while the game is still running.  So compile, link, execution time unless we need to add some new data manager or engine code.  I’ve already got the rewrite version automatically reloading the layout XML and recompiling shaders whenever the data files are modified.

As I mentioned, there will be a console window to execute script commands, reload scripts, and view script debug logs.  There is also a “debug buddy” window.  The debug buddy provides additional game control and diagnostics.  You’ll be able to jump to any context, edit the ship and events, enable/disable features, and anything else I can think of to add.  You shouldn’t have to watch the intro every time or navigate through the menus to get to a context you’re testing.  That can be disabled for debug mode.  Debugging is going to be a major focus and rapid prototyping.

Just to be clear, there are really two projects in place right now. I’m working on rewriting the original – same art for the most part, same game play. The difference is the game will be running on a modern engine and proving out tech for the next one.

My goals for rewrite:

• Prove game engine, 3D engine tech
• Test my resolve to writing a game on the side
• Provide a base Ironseed game that can be modified and enhanced with new ideas
• Experiment with new tech and game writing techniques
• Restore the original game running on Windows XP and above and not require DOSBox
• Something to do while Adept is busy designing and generating content
• Use 3rd party software (LGPL, BSD, MIT) where appropriate – focus on gameplay

Adept is focused exclusively on the new version.