next »

[burtonposey]

Hadn't seen this project before but just went through the posts and like the different character designs

Thank you very much! The concepts are being done by a friend who apparently has some mental tap into my brain because he's channeling my love of Mega Man and vinyl toys perfectly. I've been doing the modeling, unwrap, & rig on them and my lead artist is doing the textures.

We're taking it one level at a time, but I think our thinking is the later levels will have different and/or altered enemies that match the level's theme (a la Mega Man's stages).

[burtonposey]

For a while now, I've been working to find a solution to get my enemies flying in different patterns with the most minimal amount of overhead. Tonight I think I came across my final solution.

Background:
One of the more unique things about RLIC is it is happens around a planet. So it plays like a side scrolling arcade shoot 'em up, but when you get far enough horizontally, you are back at the start of the level, because the horizontal element is essentially a heading around the planet. It's kinda cool in theory. I have two functions that help me translate and orient any entity with certain properties with respect to a heading, a height, and the center of the world.

The Problem:
In practice, it's really difficult to program everything in the game with this consideration, especially when it comes to the movement of the enemies. In a normal, orthographic game, you'd lay out your cool bezier curves and be done. Simple enough. Now, wrap that around a planet and your ability to express those patterns easily becomes difficult because your curves don't respect the curvature of the planet.

The Solution, take one (path of least resistance, worst results):
I've messed around with many different methods to solve this issue. One of them involved not using animation or bezier curves and just trying to math the problem to death, without any visual construction. This has proved to not give me the flexibility I need to express the Galaga-like patterns I want (likely due in part from a lack of deep math knowledge/practice). I can't really make an enemy bob one second and then dive towards the player using math without spending half a day. I just wasn't getting cool enough motions with having them simply moving along sine waves.

Almost the solution:
Once I realized how much I needed to find a curve solution, I started tinkering with the idea of having proxy objects animate in cartesian coordinates, like a normal game would allow. Each robot would connect with a proxy object from which the robot would glean the position and compare it to the last position the robot had for the curve animation. Using that, I can calculate an offset, feed it into my aforementioned planet-centric transform and orientation functions, and get something that worked relative to the robot when it started sampling the proxy object. This is awesome, but I was worried about the overhead of having so many proxy objects animating. If there's 15 robots on the screen, I would need 15 animated proxy objects, I still felt like there was a better, more efficient solution.

The current solution:
Refusing to believe I had an optimal solution, I kept an eye out for a better way and kept poking around answers.unity3d.com and got an idea from a few posts that I could actually query an animation using a point in time and do something like the following:

Code:

AnimationState _animState = this.animation["TestAnimation_01"];
float length = _animState.clip.length;
float newTime = Random.Range(0, _animState.length);
_animState = animation["TestAnimation_01"];
Debug.Log("pre: " + transform.position);
_animState.time = newTime;
animation.Sample();

This code effectively takes the animation, Test_Animation_01, and pushes it to a particular time. Then, using Sample(), it forces an update. This might be obvious to some of you guys who use Unity, but I had no idea I could sample an animation from any point in it's duration! From there, I can simply return the transform.position of the GameObject this animation curve is attached to and the robot who asked for it can use it as it wishes.

The opens up the possibility that every robot that needs this pattern for movement in the entire level can sample this AnimationClip from a Manager, ask it what it looks like at a point in time, and free it up for another to use it. We now have n-1 less guys that need to be updating an animating Animation Component every frame.

Here's my little crude sandbox proof of concept for the "curve sharing". This is really crude and still a bit off of what I'll need in my final implementation, but wanted to post regardless it in case anyone had any need for something like this. So again, essentially there's one object with an animation definition and the others are simply asking the single instance to simulate what it looks like at a point in time with respect to when it was activated (waitTime).
web demo
curvesharing.unitypackage

That's about all I have for tonight. This is really going to allow us to be more expressive with how the enemies move, not to mention cut down on the time to tweak the movements.

[pwei]

Interesting project.

I'm not sure I really understand your curve problem.  When you say were you programming things with respect to 'heading, height & center', do you just mean polar coordinates (r,θ)? 

This actually seems fine, even with the curves you are talking about.  Instead of thinking about (r,θ), imagine you are playing a Galaga type game, but when you go off the sides you wrap.  This is a Cartesian coordinate system (x,y) that wraps on the x-axis.  It's easy to imagine how your curves move in this system right?  Now transform your coordinate system:

r = y + PlanetRadius
θ = x / max(x)

To get back from (r,θ) into screen space just do the normal polar coordinate transformation but also rotate the sprite by θ

Does this address your problem, or am I just confused?

[burtonposey]

Interesting project.

I'm not sure I really understand your curve problem.  When you say were you programming things with respect to 'heading, height & center', do you just mean polar coordinates (r,θ)? 

Polar coordinates are essentially what I'm doing, though I'll take another look at it. I actually started working from a Super Stardust HD algorithm I found and removed the 3rd dimension from it so the transforms are just played out on two dimensions, which is the space where my gameplay takes place, despite it being presented in a 3d manner.

My problem was finding a way to express the animations efficiently. One thing I've found about the animation curves is that they're not relative. So if I have an enemy doing animation A and then he switches to animation B, I need some way of saying, "Do that, but relative to where I'm at right now". This proxy curve stuff allows me to do that. I just calculate offsets based on where it was at time 1 vs. time 2.

[burtonposey]

Managed to get my robot animation stuff working quite nicely. I have a system that lets me lay one animation curve out for each type of animation needed in a level and have robots simulate themselves in the game world, relative to where they are. I'm not quite ready to show it off, so I'll just leave it at that. Should have something presentable and decent in about 3 weeks.

I also fixed an issue that I've had for several months. After our Kickstarter, I came to the intelligent conclusion that it would require a lot less overhead to move only the hero truck and the camera instead of everything else in the game world. The end result is visually identical, but I only have to move two objects with respect to the game world instead of N-2 things, . I had to break out the Law of Cosines to figure out what my turret angle needed to be and I also need to use Unity's WorldToScreenPoint to figure out if I need to invert my angle to a negative one.

Going to move back onto the enemies. I've got a big list of things to work on there, including but not limited to:
- creating firing mechanics for the turret type enemies (hovering, stationary guy - Scrambles)
- wire existing animations in for Scrambles (firing, reloading, defeated)

Just wired up all of the animations for Spinston for the first time. Here's a look at the capture process right now. I've go to programmatically pace the pull of the Citizen a bit. I'd like to time it with Spinston's actual spin so that the Citizen pulls up more when he's actually spinning and starts to lose pull/traction when he's winding up.

[burtonposey]

It's been a while since I've updated, but we've been really busy and hard at work on the game.

I managed to work an extra project to afford to bring on another artist so apart from creative oversight I can work on programming more which is where I'm needed the most.

We're planning on getting the game into a near-beta state around July 12. Still a ton to do, but it's all been a lot of fun since I've been able to focus almost exclusively on RLIC.

The game is still really performant, which makes me feel better about how many times I've gutted a few systems and gone back and re-approached them.

This weekend I'm working on wiring up the user interface systems to code. We're using NGUI now, though we did start with EZGUI. This was a great call and an easily affordable move as NGUI was only $45 and I found out that one license purchase covers my whole team. NGUI has a level of approachability that has made it easy for my new artist to setup the components in Unity so I can wire them up with the game systems. We still need to figure out exactly how we'll do the SD/HD atlas switching to accomodate retina/non-retina iPad displays.

I've got a lot to show, but I'd rather hold on to some of the cards in my hand. That said, here's our latest truck concept for the ice cream truck. This is a paint-over done over the 3d model, but the actual textured model looks every bit this good, .

[burtonposey]

Been stuck in gameplay GUI work for the past two nights. I think I'm about a day behind where I wanted to be, but I made the mistake (again) of not taking the time to quantify the needs for each component. At least I wrote a bunch of hooks for letting us scale and color everything when the values changed using the NGUI tweening api.

Definitely been going through about every emotion I can think of trying to get the game ready for beta. There's still a ton to do and it sucks that I end up feeling guilty about something as necessary as needing to get some rest.

Over the next day or so I'll be putting in the pause screen and level select screen, which is going to be pretty incredible looking. I feel like sharing the pictures of it, but I'd rather show the concepts with the in-game version, :D. My contract artist just finished bringing in assets from our comps for our menus and is moving onto remodeling the citizen buildings a bit to make them stand out in the foreground a bit more. They're also a lot more endearing. This is for the future sector (think themed Mario world) and I have been fighting to get the models a bit more whimsical and less technical and sharp. The solution was not a texture treatment but a retrofit of the mesh topology.

Hope everyone is well. Take care.

[burtonposey]

Been a bit burnt out lately. Had to take a few days and unwind. Our contract artist has been doing an amazing job and keeping the art moving ahead and our main artist is back from a vacation and on task once again.

I'm working on currency pickup and the logic to make it look interesting. I was working on UI for gameplay but got a bit burnt out after my two day task turned into a week and a few days. So I'll come back to that. One thing I caught us doing was designing for things that we didn't have a firm understanding of mechanic-wise. We run the risk of wasting creative time if our mechanics change and the UI conveys in a way that no longer applies. So it's good to be off of that for a few days.

Once I'm through with the currency pickup logic, I'll be implementing a score mechanic similar to Super Stardust HD where the player can achieve a multiplier that gets increasingly harder to surpass and will reset if the player gets stunned or a citizen is captured. I really enjoyed this mechanic in Super Stardust HD and I think it sets the bar for excellence really high and spreads the distribution of scores out nicely.

That's about all for now. Time for less talking, more doing. I'll leave you with concept 3d paint-over of the building look and feel for the future sector. The actual game textures look pretty dead on, so I'm thrilled.

[ink.inc]

Love the character models.

[burtonposey]

Love the character models.

Thanks! Sorry I didn't thank you earlier.

I've been doing a bit of everything and staying up a lot lately to get in 3-5 hours of extra work. I'm kinda numb.

Good team momentum
We had a great week this week and it seems that all three guys including myself who are working on the game really were encouraged by each others progress. It felt really good to have such a reciprocal sense of accomplishment. I can't say it's always felt that way, but I'm going to enjoy it and try everything I can to keep it going.

Enemy Wave System revisions
This week I've been shoring up deficiencies in my enemy systems based on feedback from my contract artist as he puts together the waves of enemies. I added a timeout to the enemies so they can just bolt from the level after a certain amount of time. If they do bolt, the player's multiplier resets to 0. Oh yeah, I added a score multiplier finally. It's a nice element that helps to spread scores out a bit.

UI
I've also spent a lot of time work on wave complete UI. The waves of enemies are like the chapters of a book and when you reach the end of one, you get assessed based on how fast you completed it. Programming it tends to be something that I get in and I can't find the motivation to get through it or I realize that I've got logic that goes behind it that isn't there yet. I tend to bounce in and out of working on it as it isn't my favorite thing to do. I'm just focusing on putting the numbers in there and I'll worry about the fluid presentation of the numbers (number rolls and tweens) once we're sure this is what we want to show.

Weapons
I'm working on rewiring the weapon systems. Right now it's very embedded into the Hero/Truck itself. What it needs to be is a snap-on sort of behavior where it just mounts and then it does it's own thing apart from the truck, though it does move with it since it's a child object. Got the final version of the truck rigged with suspension and a weapon mount. Got the default weapon textured, rigged, and imported into the game. We also modeled and textured a second weapon, the Rocket Pop Launcher. It looks a-mazing if I do say so myself. It's some of the best texture work my lead artist has done to date!

Game currency pickups
I have currency pickups working in the game in a primitive state. When the player gets within range of the currency, it flies towards the truck. I'd like to have them move towards the truck along slightly differing arcs, but I haven't resolved how I'm going to do that. Right now it's more A to B. I also textured and set up the material shader for the pickups too. I'll divulge the name a bit later. It's got pretty cute reasoning behind it.

I'll post some pictures later today to correspond with #screenshotsaturday. Right now I'm shaking I'm so tired, so I'm off to bed. Thanks for following along! Night

[ninja]

Can you get more screenshots up please.  I would love to see more on what this game looks like.

[Seiseki]

This looks awesome!
Love the design and art direction!

[burtonposey]

Thanks! guys

This looks awesome!
Love the design and art direction!

Can you get more screenshots up please.  I would love to see more on what this game looks like.

It really means so much to wake up after working so hard on it to see people are liking it.

You want it, you got it! Here's screenshot of what I've been working on today and last night. It's the second weapon we have ready, the Rocket Pop.

It's almost only exists visual right now, but the Rocket Pop will be a homing missile type weapon as far as I have planned right now. I've got some logic for locking on to multiple targets you touch on, but I'll need to address how those missiles steer in a more interesting fashion. I've got it all rigged up, but I need to rework my weapon system to be independent of the truck altogether. It will just snap on and listen for the touch events as it needs to. This will open up the ability for many types of weapon mechanics and the truck doesn't have to dictate how to interpret all of the touches and how they should be used.

In other news...
We also made a loading screen today for the game. It looks really slick. We also finalized the look for our sound sliders for our menu dialogs.

Thanks for following the progress. I really enjoy showing it off.

[burtonposey]

Things have been a bit crazy with some outstanding contract work, but the art guys are holding the fort while I'm in Contract Crazytown.

One guy is currently working on particle effects for the projectiles and getting used to the Unity particle system and the editor in general. He's got a really strong 2D design background with motion graphics and 3D particle effects experience on a commercial computer animated motion picture. So now is really about him getting more comfortable with how a game engine imposes certain limitations (no huge transparent particles, lack of alpha blending modes with a performance penalty, etc.).

My other contract guy, Michael Stanley, is working on environment buildout and the construction of our sector map screen. It's definitely a strong homage to the Starfox map, but with equal parts whimsy and a crisp aesthetic. Definitely expect to see this shared in here over the coming weeks.

In other news, Becca and I are going to PAX for the sole purpose of getting our game in front of anyone who will play it. I'm going to schedule some meetings or lunches or drinks or whatever I can with whatever game journalists will give me a few minutes. I'm really looking forward to getting the game in the hands of a bunch of gamers. If you're going, let me know.

Alright, talk of fun things is over, I must return to the contract work dungeons for the final battle!

[TacoBell_Lord]

The art style in this game is so minimalist, the colors are sweet to. *Tracking*

[burtonposey]

It's been too long!

I just got finished working an 80 hour week on another project. It was beyond brutal physically and even emotionally. All I could think of was getting back on the game and giving it the love it needs and deserves.

The good news is I'm back!  The great news is I'm pretty much completely done with contract work for the next few months. The artists on the team have been making great strides in my absence and now I'm trying to get our changes all merged together. We're learning some hard lessons on syncing up stuff without Unity's Asset server or SVN. I"m giving SVN a shot right now (importing my files to the repository as we speak). Hopefully we can find a system quickly that we can use effectively.

Lots of stuff to do this week. I'll be playing catch up and working on the Map menu, the weapons system, and the main menu. Right now the weapons system is very statically linked to the truck itself, so I've got to decouple that and create a system that will setup a weapons loadout from a weapons selection screen.

Our main focus is to get the game ready for PAX and even more immediately is to get it in the hands of our music and sound guys to see what they can help us accomplish by the end of the month.

I'll definitely have some concrete stuff to share this week once I shake the remaining cobwebs from this past week. Take care.

[burtonposey]

Robots Love Ice Cream @ PAX Prime 2012 Postmortem

We just got back to Atlanta Tuesday evening from showing Robots Love Ice Cream at PAX Prime. We managed to sneak in a free day in Seattle to take the city in. I wish Atlanta had the weather of Seattle. It already feels stuffy and too hot back in the ATL.

PAX was so much fun. At the last minute, Kickstarter was able to provide us a space to show off the game at their Kickstarter Loves Games booth. We had 900 buttons printed up (300 for each design/team member going), along with a bunch of sticker and some of our limited edition posters that we were selling.

We had three iPads (two iPad 2's and one new iPad) for people to play the game. I'm glad we brought three because we were constantly managing our batteries since they were on all of the time, either being played, at the main menu, or the sector map. I hadn't had a lot of time to optimize the code for the iPad 1, so I made a conscious decision to leave it at home.

I'm going to break up these updates to avoid inundating one post with so much information. Today I'll cover our art feedback, or what I'll refer to as "what we got right", .

Creative Praise
We got a ton of incredible feedback for the game. As far as the art, people loved it. It was really humbling and gratifying to hear almost universal praise for the art style and approach. We even got a few unsolicited comparisons to our inspiration games, which made us smile ear-to-ear.

We've got a lot more work to do on the creative. It was really great to see how excited people were over what I would consider about 65-70% complete art assets. We had some people pick it up and say, "wow, this is going to be huge", or "wow, this doesn't look like any other iPad game I've ever scene. I love the look of it". Like I said, it was really humbling. Still, we realize we have a ways to go before our vision for what it can be is fully realized.

Tomorrow, I'll post on our gameplay feedback. The picture at top is a promo picture we posted when we announced our PAX trip. We had a lot of these ready, but due to lack of any cell or wifi connectivity and the fact we didn't plan enough ahead, we still have yet to post more than this one. We'll likely do that over the coming weeks.

[burtonposey]

Here's the second installment of the PAX postmortem...

Here's a snapshot of the current UI setup. Explanations below the image:

In the top left, you have the radar, this shows you where the enemies are around the perimeter of the planet. In the top middle, you have your current multiplier (visual is placeholder) and the current planet score. Just below that you have the citizen count for the level. The objective presently is to defend the citizens of the planet. On the top right, you have the top score for this planet, and below that you have the current currency count for your game.

On the bottom, you have the truck movement circle. If you press the white circle and drag out to either side, your truck will move in that direction. The further out you drag, the faster your truck will move in that direction. While dragging, if you swipe down, your truck will go into cruise control. If you swipe up, the truck will jump. If you let go and you aren't jumping or cruising, the truck slows to a stop.

Gameplay Feedback and Tweaks
As far as gameplay was concerned, we got to see a lot of what works and doesn't work with the gameplay. Our firing mechanic for the default weapon is essentially like Missile Command. You tap on a spot to fire and a projectile goes there. Simple enough. But with the spinning of the planet occurring, and the fact that unlike Missile Command there is no detonation, the margin of error is a bit small. Instead of the projectile terminating at that spot, we are going to opt to continue the trajectory until it hits either an enemy or the atmosphere, which is the level's boundary. It was a simple fix to do yesterday and it killed me that I couldn't fix that while I was at the show.

UX with respect to weapon firing mechanic
One great piece of a feedback (of many) we received from a fellow game developer was the idea to have a singular interaction mechanic with respect to firing projectiles. Have that one mechanic (likely to be simply touch and hold/drag) do different things with different weapons. That way the player masters the mechanic fairly quickly and they got lots of cool feedback dependent on the weapon they've selected.

Movement Controls
Another big thing was the movement controls. To have only 4-6 people ever play the game before this weekend, we figured it would be eye opening in terms of how other people interact. Boy, were we right. We have a distinct, white circle with an icon of the truck in it at the bottom of the screen. This is how you move the truck backwards and forwards. It works like a throttle control on a boat or a turntable speed slider.

We're going to look at having the fluid, non-stepped slider become a slider with 9 steps. 0% in the middle and then 25%, 50%, 75%, 100% in each direction. The player previously used the This will get rid of the cruise control mechanic we currently have. When the player lets go, they'll always continue to move at the speed they let go at. This will be more akin to a side-scroller. Our ultimate goal is to have the player able to relinquish control of the movement if they wish and play the game more like an auto-scrolling side scroller. Jumping under this paradigm would likely be just tapping on the truck circle.

The cruise control was something people really liked and I was pretty proud of that reception. The issue was that even though people liked it, far too many people were slamming the truck movement circle outwards and, since the natural motion of our finger is an arc, sometimes they were engaging cruise control when they did not mean to. This resulted in a lot of extreme movement past their intended destination. It was a little painful to watch at times, hehe.

Radar
Next thing is the radar. I think people rarely noticed it was actually there unless we told them. Some sort of visual notification of events happening on the other parts of the planet is pretty critical. Imagine playing a game and you go to the other side of the planet and it says, "you probably should have been here.... someone really tore this place up while you were away". It wouldn't seem very fair.

To address this, I'm currently considering dropping the radar altogether and moving to a system that is anchored on the left and right of the screen. Players will see a triangle/arrow indicator for each enemy and the indicators will rise up on the screen the closer the player is to the same heading. The indicators on the left will be more closely accessible by moving to the left and the arrows on the right are enemies more easily accesible by moving to the right.

I'm hoping to address almost all of these issues over the weekend. I think the UI looks pretty nice and slick, but it should operate as such as well and we need to put a little more thought into it. We had a lot of people just get it, but that was without a tutorial and us showing them in person. The final release won't have that luxury, so it has to be really easy to get with little explanation.

Thanks for following along!

[Xienen]

Heya Burton, it's Dayle(from SIEGE).  Just wanted to say it was nice to meet you(though apparently you were at my Break Blocks presentation  ) and best of luck with RLIC.  I know that you guys are probably in a better position than we are, at present, but if there's anything we can do to help, please don't hesitate to ask =)

[burtonposey]

Ug, it's been a while. Forum said over 120 days. Anyways...

Things are still moving with the project. Still lots of ups and lots of downs. Everyone involved in the project has been doing work outside of this project near-fulltime since I last wrote, so it takes a lot of digging deep to get some hours in.

Since late January-early February we've been really focused on making sure the game is fun at it's most basic level and trying to figure out why we felt the game wasn't fun in the first place. A chief concern of mine has that the game doesn't have enough depth. To fix this, we've been trying to get the speed of creation of a level into a more manageable timeframe. The placement of an enemy group is a series of state behaviors and they're all driven by a handful of properties and a few movement methods that utilize those properties. Long story short there's no expression in planning a level out this way. It's near-impossible to see how two groups of enemies will fly about one another if you're driving the whole system with mostly logic and not having any way to really understand the visual aspect of the game, especially before you run it.

So lately I've been working on a new system for pathing enemies. After all the game is a shmup at heart, so cool movement patterns are pretty integral. We also want it to feel like a shooting gallery where the player always has some action on the screen to shoot at and fanciful movement patterns will only make this more exciting and memorable. When it's done, the new system be about 90% animation curves, 10% logic. This will allow us to express in standardized animations how far an enemy will and we can piece segments together like a formula or a chain and build effective and easily tweakable movement patterns.

I've got two new classes that are ultimately going to be driving this movement on a given enemy.

• AnimationStep - defines a curve, scale weights for X and Y axes, and a repeat count, so this step can repeat for X amount of times, no times, or infinite times
• AnimationStepSequence  - manages a series of steps in order, always loops if the last one isn't infinitely looping

Anyways, just wanted to get back in the habit of posting again. We're making a really strong push to get something submitted to IndieCade in time for the late submissions on June 30th. Going to be a busy month!

Take care all.