We’re still working out game play elements for the first two levels, so we’re not ready to release a demo to the public, unfortunately. I am thinking about doing a video showing off some of the levels and maybe teasing a little bit of the movement mechanic, but I think we’re still a bit away from a build we’d be comfortable having go out to the public, though.
April 18 Update
Man, these Saturdays come and go awfully fast.
As our hangar bay level started to get more filled up and and real feeling, we turned some of our attention to gameplay aspects of the level, and realized that we needed more; more areas to explore, more stuff to find, more things to do. We’ve decided to task-gate access to the upper hangar, which makes the hangar sublevel almost it’s own level, from a gameplay perspective. Originally, I was thinking we’d add a few corridors and causeways to help give the player a home-team advantage over the enemies boarding the ship, but our level design team fleshed out the entire area around the hangar bay, including offices, equipment repair bays, medical labs, multi-story med bay, and various storage areas, creating a maze-like area to explore.
When I say maze-like, I’m not exaggerating. The pictures below show only one portion of the new map section. You may noticed that the rooms have different color lights. We had to add color to our scratch lighting so we knew where we were. Absent props, signage, and textures, it’s hard to tell if you’re in the Med Bay or a storage room.
These new corridors and areas add so much to convey the feeling of massiveness we want for the Oberon, which makes me really happy. It also lets us wring a lot more gameplay out of this level but that, in turn, means I spent a whole bunch of time this week adding to the Hangar Bay level script.
http://0.t.imgbox.com/GVhAKmqm.jpg http://1.t.imgbox.com/2iN8Y12P.jpg http://6.t.imgbox.com/jZmrbqBr.jpg
After last week, the training area had been brought up to par with the old version, and we’ve started turning our gameplay eye towards that level. The obstacles and buildings in the range were proxies, and we’ve started turning those into more refined blockouts.
http://0.t.imgbox.com/B73LLwxn.jpg
I started rewriting the enemy AI this week, and we’ve got a pretty solid behavior tree for the basic enemy combat. The previous version was okay, but I learned a lot building it, and feel like I’m starting to have an inkling of what I’m doing. We’ve now got bots taking cover and firing from behind stuff, bots who will stand and fire, bots who will advance and fire. It’s also possible to scare a bot enough to make it flee. In the coming weeks, we’ll be building specific behavior on top of this basic combat three.
As always, we welcome comments, suggestions and criticism. Thanks for reading!
Kind of a late and short Screenshot Saturday update this week. This week was tough on the team because we had a few team members with personal matters that unexpectedly took them away from the project for part of the week, and also had some team members pulled away to help with client projects. That’s the nature of our project, and nothing out of hte ordinary, but it’s tough to follow last week, when things really started to come together, with a more challenging week like this one was.
Most of the progress this week was visual. The hangar bay is starting to get more refined, and really only needs texture work and props. Well, and more gameplay stuff, of course, but that’s actually coming along rather nicely with our new objective system, information codex, and inventory system.
We got our shield material working on device, thanks to some help from the forums here, and we have continued to make solid progress on our enemy AI.
One of the more interesting new architectural elements are the blast deflectors that have been recently installed in the hangar bay. These are modeled after the ones on Aircraft carriers and can be raised to different angles and elevations depending on the ship that’s trying to take off.
We have a new HUD system to help you find objectives and nearby enemies and it has greatly helped with the player’s sense of location (that’s “situational awareness” for you hardcore types ). The objective system is similar to, but simpler, than the one used in Deus Ex: Human Revolution, and we use much of the same code from our objective system for our enemy “radar”, which points to enemies within a certain distance of the player. The distance at which enemies are detected can be increased by finding gear power ups. Other power ups give you additional information about the nearby enemies or allow you to see them through solid objects or in darkness (though we’re still struggling with the best way to achieve those on mobile).
Of course, there’s a rumor that special Seditionist troops are equipped with some kind of scrambling device that prevents them from being picked up by your suit sensors, but I’m pretty sure that’s just a rumor. Probably.
As always, thanks for listening and we welcome any questions or comments.
–
(I guess that wasn’t so short, now was it?)
Sorry, we missed Screenshot Saturday this week, but we haven’t been idle. We just released the gesture recognizer code we’re developing as part of .
Hey, folks! Just a quick update to say that the team is still alive and well. We missed the last couple of screenshot Saturday updates because there hasn’t been a huge amount of stuff for us to show off.
This is our crazy time right now. Probably 75% of what our shop does is mobile related, and of that, probably 75% is iOS, so the time leading up to WWDC is always a bit crazy for us. We’ve had to temporarily divert most of our staff to other projects. It’s a bit of a setback, but it’s the nature of our project. I think everybody will be really excited to get back to it at the end of the month.
Our movement mechanic has evolved organically over the last year to the point where it works fairly well. But, when code grows organically, it’s typically not elegant. I’ve been trying to take what we’ve learned over the last year of refining the mechanic and apply it toward re-implementing the same mechanic from scratch in a new player controller, getting rid of all the detritus of failed experiments along the path to our final working control scheme. I’ve also been making performance tweaks and have moved several bits of more intensive code to C++.
I thought I’d give our first public sneak peak of the movement mechanic. This is a video I recorded off of my iPad playing a very simple test level that I’m using while I rebuild the control mechanism so as not to interfere with the production environments. This is very much a WIP video - the new player controller doesn’t even support shooting yet. The art is all programmer art and the level is just a simple room that lacks any of the polish of our game environments.
Let me set up the shot for you.
In the HUD, there are several rounded rects. These framed elements are items that you can interact with. Currently, orange rects are places you can move. You pan the view by dragging a thumb or finger across the screen. When the crosshairs are over an action item, its appearance changes if that point can be used. Usually, if you can see it, it can be used, but a few special move points that have additional requirements. Some require an unobstructed view, some require you to be right next to them.
Different action points have different “selected” appearances. For a movement point, for example, the orange rect turns blue, plus we add a winged foot icon and a ground marker showing exactly where you would move to if you selected the point.
While the crosshairs are over an active point, if you want to take the action, you just momentarily lift your finger off the screen. In the case of movement, you’ll begin moving toward the destination point immediately. Even though your player is moving, you never lose control. You can look around, fire, even pick another movement point or take another action while continuing to walk
Here are the basic types of action points:
That’s the basic list, though there are variations on each. For example, there are specialized move points for moving up and down ladders and stairs and “slingshot” move points that automatically send you to another move point when you reach them. We may add other action points as development progresses.
Here’s the video. We’d love to hear your comments and feedback.
Full res version for download:
Heya, folks! Checking in with another “ugly room” video as I work on rewriting the controls.
This video shows the progress made this week on our control rewrite. We’ve now got a Halo-style recharging shield (plus a damaging fire to run through so we can test it) and I’m experimenting with a new kind of pickup. Our old pick-up items were kind of UT-like objects that floated in the scene. As the game has evolved, it has turned more into an exploration and discovery game, and that style pickup feels out of place in the game now. This video shows one idea we’re considering - using pickups modeled after the ones in Bioshock (but, again, it’s all programmer art in the video… no artists were injured – or even allowed to help – with this video).
The turret continues to be an effective weapon against the Seds, but we’re back to being able to shoot at them. I finished the first draft of our swappable, configurable weapon system today. We’ve only built one gun so far, but it should be fairly easy to build many more different guns now, though I sitll have to figure out the best way to handle scopes on detachable weapons. I was thinking perhaps of using an array of camera components representing each zoom level, but I’m not sure that’s the best way.
The video was captured while playing on an iPad Mini Retina using only the touchscreen controls.
[video]]
Full res download: https://dl.dropboxusercontent.com/u/5075634/Pickups-Shields-ConfigurableGuns.mov