Castle Mooch

Posts Tagged ‘slamball’

Slamball is a management game, inspired by my exposure to the seminal Football Manager and various other more involved but less fun games over the years. A big part of these games is the management of your team’s finances, and that’s why Slamball needs an economy.

My game won’t be particularly complicated with the financials, but there will need to be enough aspects to it that it adds to the challenge. The player will have to manage a squad that collectively can only be paid a certain amount of weekly wages. Then there will be the buying and selling of players, and finally the training of players. I’m still toying with some other aspects, such as being able to upgrade a team’s stadium, but pretty much that’s the extent of the finance possible in the game.

So what makes it difficult? Balancing, that’s what.

If the economy isn’t handled correctly then the game could quickly lose its challenge as the player becomes super-rich, buying all the best players and training them all to within an inch of their potential. The other way is that the player can never generate enough income to progress in the game. So, the economy has to be balanced such that it’s always a challenge to play the game, but that the player has a chance to win.

In order to get this balance I started by looking at how I would calculate a player’s wages based on their statistics. From that I could work out how much an “average” team would cost to run, and therefore I’d be able to calculate the income required.

This wasn’t the best way to do it.

I then scrapped that approach – but kept the formula for calculating wages – and instead looked at income, i.e. the areas that the player would receive money from within the game.

There aren’t many areas, basically gate receipts, selling players, and prize money. But once I’d worked out these things I was able to more accurately set the “cost” of other things to try to keep a balance.

Right now I’m happy enough with how it will all work. But the real test will be when the game has been coded and I’m able to actually test the economy. In fact, the more testers the better, so if you’re reading this and have an iPhone running iOS4, then you may get a chance to help.

Aside from the economy I’ve been busy (re)learning iPhone development. I’ll have more to talk about on that score next time, as I start to build the user interface and integrate the SQL data access bits.

With a bit of help from the super coder behind Touch Cricket I’ve managed to get SlamBall communicating with the SQLite database I’ll be using for the game’s data store. I’m going to explain a little more about how I’ll be implementing this and why I’ve made some of the design decisions.

The database serves two purposes: firstly to store support data for the game, e.g. generic fixture lists, team data etc; secondly to persist the game’s state, i.e. save the user’s game.

To do this I’ve chosen to use two types of tables. One set will store data that doesn’t change and that can be used to “seed” the save-game tables. This will include things such as the generic fixture list data, the default team data, default admin data (current season number and week number etc). The second set will store the data that is, in effect, the user’s save game data. This will be fixture lists with results for each season (so as to have a history), ever-changing team data, player and player history data, league tables and so on.

The first set of tables will allow me to easily reset the save-game tables whenever the user wants to start a new game.  It’s the save-game tables that have proved more of a challenge.  Although they are, in most cases, an almost exact copy of the base tables they are derived from, the nature of saving data has given me pause: The basic problem is one of SQL updates.

I may be worrying about nothing given the tiny amount of data my game will utilise.

A SQL Update is a potentially “expensive” operation in terms of performance, i.e. they can be slow. You may be updating records on multiple tables, using complex joins, and once the data is written there may indexes to recreate or update. All this takes time, and although SQL is optimised for this sort of thing, I don’t want my game to take an age to save.

I believe I have two options: Either I update on a row-by-row (RBR) basis whenever the uses chooses to save, or I update in a more set-friendly manner and update a whole table at a time.

RBR would involve iterating through all my game’s objects and running an update query. If I have one thousand players in the database, then that’s one thousand update operations every time I save.  And that’s just one table.

The set-friendly method would involve a third set of tables that mirror exactly the save-game tables in terms of structure. Whenever the user loads a saved game, I’d populate this third set of tables with the data from their save. This set of tables would then be updated on an RBR basis as the game progressed. The key difference between this and the RBR mentioned above, is that I would only perform updates as data changed, e.g. if a player scores a goal, I’d update the history table. In this way I’d still have many updates to do, but I’d be doing less of them than a full RBR in one hit. Then, when it came time to update the actual save-game tables, I would just update the whole table in one Update statement using a Primary Key join and a LastUpdated column to ensure a net-change, i.e. only altered records would be updated.

In theory, the one-off big update should perform better than many single updates. However, until I start to load/save real game data I can’t be sure if the set-friendly method is actually a necessity or merely overkill.

A third option is to force an auto-save onto the game and just implement the RBR of the set-friendly approach, but without the need for the big update at the end, i.e. the incremental updates will serve as the actual saved game. This is very appealing as it would simplify everything and make the game more challenging as it would prevent people from re-loading after they’ve lost a match!

I’ve nearly designed the database itself now, so I’ll be taking a closer look into the implementation of my save-game routine in due course. The next part of the development I want to talk about is the game’s economy: Income, expenditure, and the cost of everything.

The new development is development itself. When I talk about development I usually mean “dev”, as in computer programming. Or coding if I want to make it sound cooler than it actually is. I’m starting up some dev work again and when the mood takes me I’ll be blogging about it here. My first project is going to be an iPhone version – and possibly iPad too, but let’s crawl first – of my old Amiga game, SlamBall.

SlamBall is essentially a management sim, based around a fictional game that is part football, part rugby, and with a smattering of Speedball thrown in too. I’ve chosen this as my first foray back into dev because I know the game well and it’ll therefore take away one aspect of game creation, that is the creating of new ideas.  In other words, it’ll make the dev easier given that I need to re-learn the iPhone dev skills I last used over a year ago.

To get the project off the ground as quickly as possible I’m going to implement the game using standard iPhone design patterns, e.g. task bars, table views etc.  I won’t be doing a graphical version.  Again, this is to help me get to grips with dev again without having to worry about learning how to actually implement graphical stuff on iPhone.  Once I’ve done that, and if the game is good enough, then I’ll probably take the time to convert it over to a nice graphical style.  With the help of a friend.  Yes, you.

To this end, I’ll be designing the data structure for SlamBall and using the SQLite engine to implement it.  SQL is second nature to me now, so it’s the best choice for me. I’ve discounted Apple’s own CoreData this time as again I don’t want to get bogged down in learning new tech, especially when it’s not really necessary. Plus, SQL is cool, awesome, wicked, and splendid.

To help implement the database in SQLite I’ll be using SQLite Manager by SQLabs. It’s a GUI for dealing with SQLite and will make the process much easier and quicker. I can build the database quickly using the tools provided, and also easily test new SQL scripts that will be required within the SlamBall code for creating data etc.

That’s it, that’s what I’m up to. In the next post I plan on going into a little bit of detail regarding how I’ll be using SQLite as my game’s data store and some of the design decisions I’ve made along the way.