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.

  • SalsaMD

    Eagerly looking forward to this one...

  • SalsaMD

    Eagerly looking forward to this one...

  • Marlon

    I hate virtual sports games

  • Marlon

    I hate virtual sports games

  • Widget

    The game he was referring to was Dragon's Lair, the Laserdisc-movie-arcade game in the 80s, not Dragon Slayer.

  • Widget

    The game he was referring to was Dragon's Lair, the Laserdisc-movie-arcade game in the 80s, not Dragon Slayer.

  • SalsaMD

    @Mark (hellosh)

    How have you implemented fine user control over batting. For example swinging for a high vs medium vs low fastball? Also, how is the pitching controlled? Gestures for different pitches? Menu selections?

    Thanks

  • SalsaMD

    @Mark (hellosh)

    How have you implemented fine user control over batting. For example swinging for a high vs medium vs low fastball? Also, how is the pitching controlled? Gestures for different pitches? Menu selections?

    Thanks

  • Pingback: 篠原ともえブログのフリーダムっぷりを見直した。 iPhone おすすめリンクと世相読み 2009/3/7 ver 1.0 | iPhoneアプリ紹介-AppBank

  • @Mark (hellosh)

    Recently I've been doing some lower-level infrastructure work and moving the sequencer code into Xcode to run sample plays right in the simulator, so I'm taking a look at how those run and adding some of the animations of the players. We needed some lower fidelity models for the players far away to save some polygons so I've been working on that too.

    Fine tuning batting is something we're going to take a look at next week as I really get into that, but I'm not sure if we'll really be able to add aiming for the ball more than trying to get the right timing and the inherent skill of the player. You'll be able to make a choice of whether to do a more defensive grounder-type swing and a going for the fences type of swing. If you try that with your pitcher at bat chances will be higher that you'll miss completely.

    All batting and pitching will be done by gestures and timing will also have some effect for batting so you could swing early or late if you get that wrong. At least those are my thoughts right now and we'll see in practice how it shapes up and what is fun and easy enough to play. In any case we're trying to avoid a menu or button selection to specify the pitch as I feel that slows the gameplay down a bit and most people probably want faster action.

  • @Mark (hellosh)

    Recently I've been doing some lower-level infrastructure work and moving the sequencer code into Xcode to run sample plays right in the simulator, so I'm taking a look at how those run and adding some of the animations of the players. We needed some lower fidelity models for the players far away to save some polygons so I've been working on that too.

    Fine tuning batting is something we're going to take a look at next week as I really get into that, but I'm not sure if we'll really be able to add aiming for the ball more than trying to get the right timing and the inherent skill of the player. You'll be able to make a choice of whether to do a more defensive grounder-type swing and a going for the fences type of swing. If you try that with your pitcher at bat chances will be higher that you'll miss completely.

    All batting and pitching will be done by gestures and timing will also have some effect for batting so you could swing early or late if you get that wrong. At least those are my thoughts right now and we'll see in practice how it shapes up and what is fun and easy enough to play. In any case we're trying to avoid a menu or button selection to specify the pitch as I feel that slows the gameplay down a bit and most people probably want faster action.

  • http://www.spikereid.co.uk CommanderSpike

    Looks good.

    Interesting to see in such detail, what effort goes into a game which on the surface looks quite simple and fun.

    As a developer myself, I call for more blogs like this! Wonderful.

  • http://www.spikereid.co.uk CommanderSpike

    Looks good.

    Interesting to see in such detail, what effort goes into a game which on the surface looks quite simple and fun.

    As a developer myself, I call for more blogs like this! Wonderful.

  • Patrick

    What is it that makes g++ in Unix better than Xcode for this part of the project?

  • Patrick

    What is it that makes g++ in Unix better than Xcode for this part of the project?

  • @Mark (hellosh)

    In the end Xcode uses gcc and g++ for compilation, but being old school I like to fire X Windows and getting some terminals going and doing things directly in the low level Unix world.

    For me it's much easier to write a little dedicated program for something specific, compile it and run it and output whatever I may need at the time. Within Xcode and especially an iPhone project you have to create an interface to run a simulation and for many things this just gets cumbersome quickly. In Unix you can make shell scripts and batch things and pass arguments to programs much more easily.

    For example, for the movie shown in the post, the simulation outputs individual frames that are passed to POV-Ray to output the rendered images. Once they were working nicely, the same C++ objects were then moved into the iPhone project in Xcode with very few changes.

  • @Mark (hellosh)

    In the end Xcode uses gcc and g++ for compilation, but being old school I like to fire X Windows and getting some terminals going and doing things directly in the low level Unix world.

    For me it's much easier to write a little dedicated program for something specific, compile it and run it and output whatever I may need at the time. Within Xcode and especially an iPhone project you have to create an interface to run a simulation and for many things this just gets cumbersome quickly. In Unix you can make shell scripts and batch things and pass arguments to programs much more easily.

    For example, for the movie shown in the post, the simulation outputs individual frames that are passed to POV-Ray to output the rendered images. Once they were working nicely, the same C++ objects were then moved into the iPhone project in Xcode with very few changes.

  • fg

    I hate to ask, but is there a target for release? I've been eagerly anticipating a baseball title as the MLB season approaches.

  • fg

    I hate to ask, but is there a target for release? I've been eagerly anticipating a baseball title as the MLB season approaches.

  • slappy

    Very nice... glad developers are really enjoying working on the iPhone/Touch platform.

  • slappy

    Very nice... glad developers are really enjoying working on the iPhone/Touch platform.

  • SalsaMD

    @fg

    You can pick up the lite, or $1.99 version of Baseball Superstars.

    I don't expect Flick Baseball to be out before the all star game...

  • SalsaMD

    @fg

    You can pick up the lite, or $1.99 version of Baseball Superstars.

    I don't expect Flick Baseball to be out before the all star game...

  • xVariable

    Those ground textures look pretty low-res. I really hope textures will improve for the final release...

  • xVariable

    Those ground textures look pretty low-res. I really hope textures will improve for the final release...

  • xVariable

    Baseball Superstars is primitive. Try the lite version before buying.

  • xVariable

    Baseball Superstars is primitive. Try the lite version before buying.

  • Vende

    I couldn't get into baseball superstars either. This looks cool though

  • Vende

    I couldn't get into baseball superstars either. This looks cool though

  • MacTheSpoon

    Wow, this is such a cool post. Thanks so much for sharing, Mark (hellosh)!! Really fascinating to get a window into coding and the development process.

  • MacTheSpoon

    Wow, this is such a cool post. Thanks so much for sharing, Mark (hellosh)!! Really fascinating to get a window into coding and the development process.

  • @Mark (hellosh)

    Thanks, MacTheSpoon! We will definitely be revisiting textures and seeing how we can improve things as they are indeed fuzzy when viewed close-up. You'll also notice that the batter's boxes are ridiculously sized and in the screenshot from the device the baselines are about 15 feet long instead of 90 feet, so they would be even worse if scaled properly. Better ground textures and stadium are definitely in the program.

  • @Mark (hellosh)

    Thanks, MacTheSpoon! We will definitely be revisiting textures and seeing how we can improve things as they are indeed fuzzy when viewed close-up. You'll also notice that the batter's boxes are ridiculously sized and in the screenshot from the device the baselines are about 15 feet long instead of 90 feet, so they would be even worse if scaled properly. Better ground textures and stadium are definitely in the program.

  • max

    mark is hot

  • max

    mark is hot

  • johnathon4

    yes, he is

  • johnathon4

    yes, he is

  • Greg

    Nice to see a dev trying to to tackle a genre as demanding as baseball. There's a lot presumptions from causal and hardcore sports fans on sporting games. Flick Baseball actually sounds more like a stand alone title than minigame with it's seasons and stat tracking. I look forward to this

  • Greg

    Nice to see a dev trying to to tackle a genre as demanding as baseball. There's a lot presumptions from causal and hardcore sports fans on sporting games. Flick Baseball actually sounds more like a stand alone title than minigame with it's seasons and stat tracking. I look forward to this

  • migs!

    in the screen shot of the batter...he is holding the bat WRONG!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! AGH!!!!!!!

  • migs!

    in the screen shot of the batter...he is holding the bat WRONG!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! AGH!!!!!!!

  • jdmoney

    YES right hand on top.

  • jdmoney

    YES right hand on top.

  • @Mark (hellosh)

    Yes, the bat holding is wrong. I noticed this late last year, but thanks for reminding me as I've got it on the to-do list now. I've switched to the proper hand for following its movement and will need to move the other hand to the correct side in the animation sequence.

  • @Mark (hellosh)

    Yes, the bat holding is wrong. I noticed this late last year, but thanks for reminding me as I've got it on the to-do list now. I've switched to the proper hand for following its movement and will need to move the other hand to the correct side in the animation sequence.

  • fg

    The All-Star game is tomorrow, will we see Flick Baseball then as well?

  • fg

    The All-Star game is tomorrow, will we see Flick Baseball then as well?

  • Pingback: ‘Flick Baseball’ Review – It’s Finally Here | Mobile Press