Ports Ahoy! The Age of Trade is best described as a tycoon game. Buy ships, draw out trade routes, and build up your empire! The game was made by the 5 of us here at Literal Games: 2 programmers, 1 artist and 2 music/SFX. This was our second Ludum Dare as a group, and I think we came on leaps and bounds since last year!
I was the main programming force behind the game, and I think now is a good time to reflect on what did and didn’t go well.
WHAT WENT WELL:
Doing an hour’s planning before bed
Being in the UK, the theme was released at 2am. We stayed up until the theme was released and spent an hour throwing down ideas and words that came into our heads. Then, with all those ideas and concepts buzzing around our heads, we went to bed and slept on it. The result was, in the morning, a group of people well rested, ready to make a game, and with lots of good ideas.
Concept Art!
Settling on an theme early
After breakfast, we managed to decide fairly quickly on a trading game. At first we were going for space – then someone suggested boats and we were all quickly on board. That meant that, even without a solid game concept, most people could get to work. Our artist made some boat concepts and our sound guys started working on some naval music.
Setting a schedule
Before we even started we had decided on a rough schedule – Day 1 was basic gameplay, Day 2 was extra features and Day 3 was polish and bug fixes. I’m not going to say that we rigorously stuck to that schedule but it allowed us to know when things were taking too long.
Debug mode showing connections
Writing decent code and knowing my base code
If I do say so myself. Even though I’d never done a game like this before (I’d never implemented zooming in a game before!) because I’d written the engine myself and knew it inside out, and had been working with AS3 so long, I knew exactly how I wanted to attack this game. I had a few problems with maths of zooming and positioning, but it all worked out on the end. The code I wrote the first two days was surprisingly clean and clear and allowed me to add features and functionality quickly and efficiently – like the debug mode we used to remove connections that went over land!
Having a GREAT BIG whiteboard
We took the whiteboard that usually resides on my wall down and used it for everything – planning, concept art, feature list, bug list, doing maths, listing out ports, and more. It was so useful being able to explain something to others by quickly drawing a sketch, or feeling the satisfaction of (literally) wiping off a bug. It kept us organised and on task.
Planning on the whiteboard!
Deciding who was cooking what when
If you’re working solo, you probably don’t realise that working in a team has some disadvantages – we had to feed 7 (the 5 of us, my girlfriend and my brother) people in my house for 4 days! But we had meal plans set out and dinner ended up being a stress free welcome break for everyone. Another good idea was having a takeaway on the last day – everyone managed to keep working and got a nice meal!
Streaming/Blog posts
We had a stream up last year, but it didn’t really take off. We had a couple of regulars last year, but this year we had loads of people who stayed and some who even came back again! We had two followers on Twitch at the start of the Jam – and now we have 23. Having people talk to us in the chat and interacting with them was so much fun, and hearing people compliment the art and the concept in the blog posts we did kept us on task and excited about working. Our artist made loads of graphics for the stream like borders for the webcams, splashes, and a countdown that I made, which I think contributed greatly to the look and feel of the stream. Making GIFs and writing blog posts gave us a quick break and broke up the monotony of doing the same thing for many hours a day, and having new people come and watch the stream after reading the posts was always nice.
GUI and the upgrades screen!
Polish
Our motto for the weekend was “Simple and Polished”. Looking at previous games, the ones that did well were the ones that kept to that idea. We’ve had so many comments about how polished the game is, so we definitely managed at least half of our goal! Simple… maybe not. Simple things like tweens, things fading in and out, drop shadows on EVERYTHING, and well designed GUI meant that the game feels very polished. I think something that really shows this is the upgrades screen. Clicking the shipyard button doesn’t just pop up the upgrades screen – it slides out, and not just that – it also bounces. That took an extra minute to add in, but adds so much.
Music and SFX
Our two sound guys did such a great job. The music has received so many great compliments. It fits the game perfectly, with seafearing riffs and maritime instruments giving the game the perfect feel. The vast array of sound effects they created from nothing but their mouths and what was lying around my house, I think, is extremely impressive. If you want to hear the finished tracks and some in progress tracks, check out our SoundCloud.
WHAT DIDN’T GO WELL
The concept
We said last time we entered Ludum Dare that we would never again do anything that needed balancing. Somehow, we forgot that. The game is not balanced at all – a few good trade routes in Europe and you can buy all the upgrades – you don’t even have to cross the Atlantic, which was supposed to be the main point of the game! The type of game also meant that there was lots of GUI involved, which hampered progress for both me and the artist.
This is what pirates do.
Endgame
On the last day, with about 6 hours left, we realised – there’s no way for you to lose or win the game. We quickly decided that you could win by discovering every port and lose if you lost all your money, but neither of those things are really feasible. There are too many ports to make it fun or viable to catch ’em all, and with the balancing issues we had you never really have to deal with ever getting close to losing.
PIRATES
We struggled a lot with how to do pirates. We decided at the beginning that they shouldn’t be visible so you had to watch where your ships disappeared to find out where they were. However, whilst we were playtesting on the last day, we realised it didn’t really work – but what to do about it? We left it, but we have had comments about how annoying and nonsensical pirates are. Yarr…. we know. Pirates invading ports was added in quickly as a last minute thing, but doesn’t occur often enough to have an impact or for most people to even see it!
Drawing trade routes!
Interface
As we all knew how to control the game, we never realised this was a problem. People didn’t understand how to make trade routes! All we said in the help was click and drag. I watched a livestream of someone playing our game, and they tried to make a trade route to Rotterdam to start with. They dragged straight from Bristol to Rotterdam, which I’ll admit, makes sense, then were very confused when it didn’t work. Maybe the waypoints aren’t visible enough or we need to explain it more, but it is definitely a problem. In a similar vein, Privateers needed more explaining too. No-one realised you could move privateers once they were in the ocean, and the idea that you can’t move then into ports unless there are pirates attacking is very unintuitive.
“Vector” graphics
The amount of scaling and zooming in the game means that vector, rather than bitmaps would be preferred – even the art style, mainly block colours and straight lines are perfect for vectors. Except… neither me nor the artist knew how to make or use them. So we ended up having to deal with huge bitmaps and spritesheets, which was less than desirable. It also means that the game takes up almost 300MB in RAM! I also didn’t realise it doesn’t run at a steady 60fps on any low spec computers. Work could definitely be done on that!
The game at the end of Day 1!
Time management/Feature Creep
I said earlier that we didn’t stick to the schedule. At the end of the first day we were on schedule – just. The core concept of the game was finished (just). The second day, however, was a bit of a shambles. Lots of polish that could have been saved for the final day was done, when really I should have been focusing on making the gameplay engaging and other basic things. Hell, I didn’t even make ships turn around until almost the end of the last day. And feature creep was definitely an issue – with about 3 hours left on the last day we decided we should add wealth to ports. It turned out okay, and was definitely a huge improvement, but it so should have been done a lot earlier.
Multiple Programmers
I’ve never had another programmer help me in any game before. We set up git and did use it, but finding things for our other programmer to do was hard, and transferring assets and keeping folder structure means we lost time when he did start to work on things. We should have been working on everything together from the start, and comments were few and far between in my code which was definitely a problem. This is definitely something that went very wrong and could have fixed many of the problems caused by not having enough time.
CONCLUSION
Wow. This has turned into a mammoth post. All in all however, I think we’ve all improved hugely since our last Ludum Dare. We’ve learnt new lessons, and reinforced what we learnt last time (DON’T DO ANYTHING THAT NEEDS BALANCING!). Thanks for reading if you’ve got this far, and I’d love it if you gave the game a try if you haven’t already.
The finished product! Click to play the game.
