Autumn
Info
Autumn was a roguelike game about a hacker named(?) Autumn trying to to escape from swarms of hostile robots. Also, somehow a Tofuman was involved.
- Made with: Unity
- Repository: Time-game
Background
This was an interesting project because it was probably the first one that I decided to step away from due to lack of commitment. A lot of reasons contributed to it, and I feel bad about having left it. Because of this project, I'm pretty cautious now saying that I'll join projects in the future without being sure of my availability.
First, I think I'll talk about my personal role inside of this project. This project was a year long VGDC project starting from Fall and ending in Spring. My role this time around was definitely different than what I've done on previous projects. I contributed a lot less to this one than I could have done due to a variety of conflicting activities I was involved in. To be honest, I wasn't even sure if I wanted to do a VGDC project this year.
The biggest reason was that I was in a Capstone course during this period. Ideally, most of my free time should be focused on that. However, I feel like I owe a lot to VGDC. I've been on a project with them pretty much every single school quarter thus far. And because I'm an officer of the club, I felt it was necessary to join a project to continue my personal tradition.
Out of all the project pitches that quarter, I really didn't have a strong preference for a particular one. Ideally, I think I wanted to perhaps do a networking project since that's something I was most interested in at the time. Nick's, another officer of the club, project fit my criteria the most, and it seemed the most fleshed out and well organized.
But in the end, I decided that what I wanted to do was take more of a mentorship role and help start up a project rather than furthering my individual interests. I knew I was going to be wrapped up in other things already, so I wanted to lighten up my schedule a little bit. The plan was to help jump start a project and get it going smoothly and then maybe contribute a little bit here or there.
Part of my decision came the fact that as a club this quarter, we wanted to slowly grow new teams and make sure they didn't become overwhelemed early in the year. Throwing people into the fire was something we did in the past of VGDC, for example, where we would always by tradition hold a game jam in the fall quarter.
What often ended up happening though was that a lot of new members would end up getting extremely frustrated and scarred even from their tough experience as they floundered around not knowing what they should do. The club would lose a good deal of potential members after these jams too.
This year, we decided we would not hold a game jam in fall quarter. Instead, we hoped to slowly ease players into game development and give them at least a quarter's time to develop their skills. At first, I was somewhat put off with the idea, mainly because I'm a huge, huge fan of game jams and was sad to not see one this quarter. But after working with the Autumn team and seeing how the club did that quarter, I'd say we definitely made the right choice.
In fact, I'd go as far to say that we should do more in fact to promote this gradual teaching environment and help teams as much as we can. I feel that it's really important that every team has a mentor/experienced figurehead, who's there to promote discussion, guide the development process, and share tools and ideas to the group. Without this mentor, teams can struggle to figure out what to do, break the ice, or just in general get anything going.
One thing I tried to push for next quarter/year was to make sure that new projects always had experienced project leads that had already worked on plenty of projects in the past. This quarter we selected project pitches based on game type and game idea. This involved widdling out projects that were too out of scope, including many 3D games.
While this was definitely an important constraining criteria, I wanted to put more emphasis on the team leaders themselves, to make sure that these leads know what they're doing. And if not the leaders, at least let there be dedicated mentors to help the whole progress along.
In my experience with Autumn, I think I did a fair job giving everyone a good push forwards. The first thing we did was organize communication. We had a great ice breaker dinner session during our first meeting where we just did mostly small talk and introduced ourselves to one another. We organized Facebook contacts quickly and got off to a great start getting everyone on the same page.
We used when2meet for all our scheduling needs, probably by the way the greatest online scheduling tool I've used. A friend, Sean, from VGDC introduced me to it and it's been really awesome to use, much easier to navigate than some comparisons, whenisgood and Doodle for example.
when2meet
With that, we decided a time to meet on the weekends where we could get together and have a two to three hour work session. Later in the quarter, we felt it was important to have additional meetings, so we broke up into two teams and met with our smaller groups once more during the weekdays.
I'd say only around half of the group or less show up for the meetings, but overall, we still communicated pretty well and remained in contact. I think we lost a total of 1 or 2 members over the quarter. Out of a dozen, that's pretty good, and I'm more than happy with how we worked this quarter considering the past teams I've been on.
I've said some points already in past posts about team sizes, but for this project, having a dozen or so members did kind of overwhelm us. Programmers were the large majority as always, and because we couldn't break people off into tasks easily, we had potentially two or three programmers working on the same issues. Having a lot of people was pretty fun though, and I think for the most part this group held it together. A few of the members were already previously good friends with one another, so having established friendships helped things along.
Alright. Now let's get into the thick of the things. Starting the quarter off, we went pretty slowly. I introduced everyone to Git and Trello. Git led into expected problems. Almost everyone didn't have experience with it, so it was a tough learning process. But it didn't become too big of a problem.
I think everyone was pretty vocal about getting help for it, and for the most part we didn't run into big catastrophic problems with it. We decided to use Unity, which can get kind of finicky. We did get some random merge conflicts on our main Unity scene from time to time.
As for Trello... it's been kind of rough to get everyone to use it. Especially for the early stages, we really didn't have too many detailed tasks to put up, so it's somewhat been abandoned. Despite that, I think some of us still actively use it, which is good. It's a great way to keep track of tasks.
Task management was a surprisingly difficult thing to do. Even that quarter, a lot of us ran out of things to do, and we weren't sure what to assign to one another. Sometimes the responsibilities were lopsided. One person may have a bunch load more work than another; someone may have finished their tasks too quickly or too late; etc.
We decided to use Unity because we wanted to use this project to be a learning experience for it. A few of us had some experience with it already, but I was not one of them, which I hurt us a little bit. I was going to look up tutorials and stuff, and I even assigned tutorials as our tasks, but I... I just I don't know, kind of never got around doing it. So it was tough to give any advice to any of the team because I really didn't know how to navigate Unity at all.
But it was really nice to see a few of our programmers step up to the plate and guide the project in my place. They picked up Unity pretty quickly and got started with tasks immediately. It seemed like though the members were mainly first and second years, they knew their programming and game development to a pretty good extent already, so that sped things along for us.
I gave as much advice as I could for art, since that's where most of my knowledge was. We decided to use a pixel art style. This surprised helped us out more than we realized. The barrier of entry to pixel art was a lot less than standard art because all it required was a mouse rather than a drawing tablet. We ended up having something like 3 and a half artists on our team since someone just decided, hey, I want to do X or Y, and just did it.
Now to start talking about the game design itself, I feel like I singlehandedly pushed the game into a direction that it maybe wasn't meant for. What we ended up with was I think something pretty interesting, but forced on my end. Originally, the game was called Project Time Game. The pitch was that you ran around for about ~30 seconds avoiding enemies before a powerup would spawn. Once picking up the powerup, you could use it to deal with enemies.
The pitch reminded me of a similar game that was made in VGDC in the past, DayBreak. DayBreak was a really well rounded idea. In the day time, you broke down tombstones, and at night, ghosts from the tombstones would come out and attack you. Different ghosts would spawn depending on which tombstones you broke down. If you got hit with too much damage, you lost. It was an interesting idea that I maybe wanted to tackle at some point, so that's why I chose Time Game as one of my preferred projects.
DayBreak
For the first couple weeks we tried to constrain our ideas down and solidify our game design. The first thing I suggested was that we make an art style similar to Nuclear Throne, simply because of the fact that it was easy to implement. Nuclear Throne is a top-down camera view game, but the characters were displayed moving in profile.
The top-down view was important because it fit the original pitch. The 3/4 profile view was important because it helped conserve art assets, something I knew always doomed some projects. Artists would only have to make one direction's worth of art, and moving animations would be less of a pain.
Nuclear Throne
We decided to follow in Nuclear Throne's style as well and do pixel art, which, as mentioned before, helped make the art process easier. For these reasons, art was not a major concern for the future. We played around with some setting ideas, one of them being a sci-fi idea about fighting against robots. Some of us felt that was too generic though, so we weren't exactly sold on that idea. It wasn't until later when we thought of other mechanics that we ended up going with sci-fi.
We thought about maybe specifying sci-fi even further and eventually talked about robots. The process was something like, okay, what would be an interesting skill that you could do every ~30ish seconds against robots? How about hacking? You had a hack ability you could use to take over enemies and use them to fight. That seemed pretty cool, and I think the team liked it. Our team lead was particularly excited in that, he went right to work creating some concept art of our main hacker character, even giving him a name and a name for our group/project, Autumn.
To be honest, I don't think the name fitted very well. We didn't incorporate anything else with Autumn, so it's just kind of this odd part of the game standing on its own. I liked the name that someone else brought up, I think it was Cyberfall. But I mean, it's a minor issue.
And on the topic of things that didn't fit, I must talk about Tofuman. What is Tofuman? Well, to be honest, I'm not even sure myself, but from what I understood apparently he's supposed to be the main character's sidekick. And there were different versions of Tofuman too, like a stinky tofuman or sticky tofuman that gave you different skills.
I'm not really sure how he got into the game, but I think there was just one person on our team, Brendon, that randomly made him. I don't know why he wanted it in the game, but he definitely wanted it in the game. So now we had to somehow fit Autumn, Tofuman, and hacking together and make something coherent.
Tofuman
Back to more of a reality, after thinking about what we had at the time, I think there were a few things I wanted to spice up. I didn't like how it was simply a just-keep-dodging-until-your-power-was-back-up kind of game, where you really didn't have any capabilities to fight back other than running around doging. So we played around with a couple ideas.
Someone suggested you have some skills that allowed you to pushback/defend against the enemies but not actually damage them. Temporarily, we went with a basic sword slash that knocked enemies back. Your Tofuman sidekick, I believe, would also eventually fit into some kind of a defensive role.
Another thing we wanted to add were gates. Gates would block your way and you would have to expend your cooldown to open them. However, that seemed a bit too harsh thinking about it, because then you wouldn't be able to defend easily against enemies. So after some time and giving it some thought, I suggested instead of using time as your resource, we could use something like an energy gauge instead.
Example of our current gates
The idea was that killing enemies or opening some chests would drop energy that the player could pick up. This gave players another objective outside of mindlessly killing and avoid getting killed. Once they reached a certain amount of energy, they could expend it to hack into an enemy, gate, drone, or chest. Health and energy would regenerate over time. This kind of threw away the idea of time entirely, but it still had a similar kind of limiter on your skills. We decided to go with energy over time.
Some of this energy inspiration came from Risk of Rain, where players picked up experience boosts and coins to level up or buy items, respectively. I condensed the two ideas down to a single energy bar that one could use. We actually took a quite a bit from RoR overall. Namely, we were probably going to closely copy its UI to display health, energy, and skills.
Risk of Rain
I think with all these ideas set within the first couple weeks, we had a good idea of what to achieve going forwards. Again, I probably brute forcibly pushed a lot of these ideas, but there didn't seem to be backlash or criticism from anyone. Our first couple meetings were spent with me pretty much doing all the talking. I felt like I was suffocating most of the discussion, and people may have had their points left out or not addressed.
What eventually opened us up was having work sessions during our meeting times. These sessions really helped bond our team together and invited more discussion between us. We would break off into our own smaller groups and have some time working on our individual tasks or just talking about random things in general. I highly suggest having work sessions in general. It's just tremendously helpful for getting people to know, work, and interact with each other.
After the first couple of weeks went by, my own productivity dropped off significantly. I was always around to help if we needed some tips on making sprite sheets or if we needed some help in thinking of ideas or some advice with Git, but I didn't actually contribute anything too significant afterwards.
I did some environment assets, i.e. tiles for the background, gates, and walls. And I did a little bit of programming for the Camera in the game, with what I learned from Tatami, but that's honestly I think pretty much it. If you can even count it, I did some last minute bandaid work to put gates into the game.
The others put in the main character, hacking, a ranged enemy, menus, UI, random enemy spawning, and levels. There were definitely a lot of rough edges, but for our first quarter goal of a prototype, I'd say we did pretty good. Later goals included putting more enemies in, fixing hacking to be more smooth, and push back animations.
I took a look at level design to help us out. We decided to use Tiled and Tiled2Unity to make our levels. Actually making the levels wasn't too bad since the editor was fairly simple to use. Transferring it over into the game, however, seemed to have problems. At the time, we were using some weird, arbitrary scaling amount to position the level correctly. We should try and get it to be pixel perfect, especially since we were using low pixel count art.
And this basically concluded the first quarter of the project. Much of the writing above was adapted from an old post that I made to cover this period. The second quarter is now a much more of a hazy memory for me. During this period, I remember I started to take an even more backseat role in the project as I was consumed with other activities. Eventually, by the start of the third quarter, I formally announced that I would be withdrawing the project.
A lot of things were going on at the time. The most pressing was finishing up my capstone project that wasn't going as smoothly as I liked. This required most of my free time, fixing and adding features. On top of that, during this period I started up an osu! club on campus that took a huge amount of time to manage. I had to plan weekly meetings, talk with officers, and of course play a lot of this game as well.
Because of that, Autumn's second quarter saw little to no work from me. I want to say progress in the group as a whole kind of slowed down as we saw people come and go and myself not playing a more dominant role. It kind of sucks leaving in a somewhat sticky situation, but since I barely contributed anything for so long, I decided it would be best for me to make a clean breakaway from the group.
Eduardo, the leader, seemed understanding to my situation, though he didn't say much about it. He was stuck in an awkward spot where I felt like he was somewhat powerless in helping the project situation. He looked like he was losing control over the group because of his lack of experience and coordination.
One reason why I wanted to make sure future groups have competent group leaders was because Eduardo would probably have a lot of trouble getting a group going by himself. He had the support of his friends in the team, of course, but he was not a programmer himself and was not used to tools, whether that'd be for programmers, designers, artists, or administration, that were frequently used in projects. Having a mentor figure like myself helping out I think alleviated some of the problems, but I can't be there to help 100%, and it's up to the group lead to handle these situations.
I think we did alright in Autumn though. Brendon, Eduardo's friend and one of the programmers, got a pretty good grasp of Unity and was pretty vocal in discussions. He, Arielle, and Nina handled programming to a good degree. The other sections needed more help, but since we had so many people, there were always people spilling over here and there to compensate.
When I left, I was prepping a ton for the new Spring quarter. There was a lot I wanted to do for the new osu! club, my #1 priority then. Autumn was in a somewhat shaky place, but they seemed like they were capable to keep on working.
Everyone was pretty nice and docile to work with. There weren't really any people with poor attitudes, so we rarely butted heads, except for maybe Brendon on making sure Tofuman somehow made it into the game. I hope everyone on the team found the project educational and fun to work in and got good takeaways from it.