This is a developer guest post written by Freeverse’s Mark Andersson and details some of the design challenges in Freeverse’s upcoming Flick Baseball game. While the content is aimed more at developers, it also provides fans an early peek at this upcoming game.
My name is Mark Andersson, and I have been working with Freeverse for over a decade. I was the Lead Programmer for Burning Monkey Puzzle Lab, Burning Monkey Casino, Wingnuts, Wingnuts 2: Raina’s Revenge and Neon Tango. Most recently I’ve been working on games for the iPhone, and developing versions of Burning Monkey Puzzle Lab and Burning Monkey Casino.
In that effort big chunks of code came over from the original Mac versions largely unchanged, making development on the iPhone that much easier. You really can consider the iPhone platform to be like a tiny Mac, which is great for old-school Mac developers like me and the other Freeverse guys. The real effort goes into rethinking the interface for the smaller screen and the innovative control methods, and of course maximizing performance within the limitations of the hardware.
early development shot of Flick Baseball
My current project for Freeverse is an original, ground-up, iPhone game and the next title in the Flick Sports series: Flick Baseball. So when you’re not bowling or fishing you will be able to enjoy America’s favorite pastime in your pocket! (Hmmm… that didn’t come out quite right)… In this post I hope to give you some behind-the-scenes peeks at the game during development and touch on some hopefully interesting aspects of the process.
Scope of Gameplay
The first design challenge in Flick Baseball was trying to determine the right mix of game depth and complexity while keeping intuitive mechanics and “pick-up and play" appeal. It’s a tough problem, as baseball is a very intricate sport and that’s part of its appeal. We think we’ve charted a course that gives the player the maximum freedom in choosing how they prefer to play, but I’m sure we’ll be tweaking and making adjustments well into the testing phase.
Flick Baseball will begin with the ability to pick a pre-made team or to customize the names of the players, edit their stats and even design their uniforms. You can then choose to play a single game against any other team, play an entire season, or just skip the hard work of the regular season and enter the post-season race with your team in the wild card slot. If you go through the regular season you’ll be able to speed things up by skipping any games you feel like and letting the computer simulate the outcome.
We needed player-controlled batting, of course, but we also wanted to include pitching with some control over the pitch types. Your players will also have some individual statistics which may make them more able to get a hit or a home run, and we wanted to keep an element of strategic use of your lineup to try to get the best outcome possible. For example, if your pitcher gets up to bat you are likely not going to swing for the fences and instead may want to try a sacrifice bunt instead — especially, if you have a runner on base and an out to spare.
What we did not want to do is include the ability to control absolutely every aspect of the game, which would slowg down the action and sacrifice fun for realism. So, stealing bases, controlling base running and dictating the movement and action of the fielders was dropped. With only touch controls and limited screen real estate, keeping out clutter and unnecessary complexity is a top priority.
While I played a few baseball games, including some really awful ones (yes, Ninja Baseball Bat Man, I’m looking at you), I wanted to avoid playing every game available out there because I did not want to subconsciously copy from them. Also, their input methods were universally very different from what the iPhone offers and implementing D-pads and virtual buttons on the device screen was not an option we wanted to explore.
Prototyping
During initial prototyping, I worked on the basic setup and engine and used 3D animation built for Moto Chaser and Flick Bowling. I started out by implementing batting practice to get a feel for animation, timing and ball simulation.
The Sequencer
We decided early on that we wanted as many CPU cycles as possible dedicated to graphics and sound processing. So, we are not going to take all nine fielders and give them each complex artificial software brains so they can work intelligently as a team. Instead, we realized that you can figure out a set of possible realistic outcomes when a hit occurs. For example, one of these could be a line drive that goes over the shortstop’s head but drops down before the left fielder can get it, and results in all base runners advancing a single base. Others are even simpler, such as foul balls and home runs.
So with a large enough set of these outcomes you would be able to put together a realistic game. You will be able to pitch or bat and your inputs will determine the possible set of outcomes, but once the computer figures out how the play will proceed, a sequence of actions will take place that has been predetermined to some extent. However, there is still a real time simulation of the ball motion and the fielder actions. So it’s not a movie clip like in Dragon Slayer.
The way this works is that there is a sequencer that can be issued commands. These can be stacked up and then the sequencer will go through them and take the appropriate action, which is really delegating the command to the various independent controllers for the ball, the fielders, the runners and the camera.
So the sequence for an easy grounder to the shortstop who throws the ball to first to get an out might consist of:
1. Set the initial velocity and angle of the ball to go towards the shortstop but roll along the ground.
2. Tell the short stop to move to intercept the ball and stop it when it gets to him.
3. Tell the first baseman to start moving towards first base.
4. Wait until the short stop has the ball.
5. Tell the short stop to throw the ball to first base.
6. Set the velocity of the ball so that it arrives at catching height at first base.
7. Tell the first baseman to catch the ball.
8. Wait until the first baseman catches the ball to report the outcome and end the play.
Within this framework I ended up adding other niceties, such as being able to set a delay to wait before the next command is processed, as well as telling fielders not directly involved in a play to rotate to face the ball. If the command is not a time delay or waiting for a fielder, they are processed and removed from the queue during the same animation frame.
I have also been implementing a number of camera commands, such as moving the camera to another location, either instantly to simulate a cut to another camera or gradually as if the camera were on a giant moving boom. There are also commands to point the camera at any fielder or base or follow the ball and change the field of view to simulate zooming.
This can get complicated quickly if you want to be able to control everything, but the most important part is to make sure that things from the camera point of view look good and you can see the action.
In order to perform the simulation of the sequences in a controlled environment, I am working on the various controller objects using g++ in Unix and staying away from Xcode for the time being. I need to make sure the outcomes are working properly before trying to debug other aspects of the game on the device. So, for now I am simulating the game frame by frame and outputting visualizing objects in POV-Ray files. I am moving the camera around as it would be on the real device so I can get a sense for how things might look and how the timing is working.
In the following movie example, using little monoliths for the players, the batter hits the ball towards the shortstop, who fields the grounder, lobs the ball to the second baseman who then turns and quickly throws it to first base for a double play. There are about 30 sequencer commands right now to implement this sequence, although there are few extra ones to simulate a pitch right now. About a third are dedicated to camera movements and timing.
The red boxes are the inactive fielders, while green indicates fielders that are doing something, either moving, waiting for the ball, or just facing the ball in the case of the third baseman for example. The yellow boxes are the active runners.
That’s it for this edition, but feel free to ask questions and comment about anything you like. I’ll also be on the TouchArcade forums (username hellosh) so you can reach me there too.
