Jump to content
British Speedway Forum
TheSmiler

Speedway Promoter Game?

Recommended Posts

 

Good to hear of yet more examples of Speedway games being done both historically and currently. At this time though, there continues to be the lack of a free open source program that a developer community of Speedway fans can steadily make better and better over the years, and that's a gap I would like to see filled.

 

 

A couple of questions if I may:

  1. What programming language and version was the source code written in?
  2. I'm guessing the legal proceedings were due to intending to use real rider names and team names, rather than the very idea of selling a game that allowed players to pretend they were Speedway promoters...?

Transcribe the source code from a ring binder...? :o Well, you never know! I work full-time, have a wife and responsibilities at home, but contributing to an open-source Speedway project appeals to me if I'm confident I can deliver. Roughly how many sides of A4 is this printout?

 

Getting even a transcription of raw code in an old programming language version into a shared GitHub repository could be that key first step in getting a project under way - if you are formally willing to hand over your intellectual property to be, say, GNU General Public License and someone is willing to really do the transcription rather than just mull it over on a forum.

 

Yes you make a very good point about the advantages of a web application for the mooted project. The only question mark for me is around hosting. In my job in the IT department of a large company, if I need servers for a project, I just fill in a sizing form and infrastructure teams allocate the hardware; there's a monthly operational cost to run them but I'm a technical role that doesn't have to worry about such costs. In the wider world, there is the prospect of paying for hosting space, especially if the game becomes popular with several users.

 

You probably know more than me about web hosting in the wider world - is there a free platform offering that can handle maybe 50-100 (non-concurrent) users? I note for example the Free Heroku offering goes to sleep after 30 minutes of inactivity, and I'm guessing this game isn't going to be so amazing that people keep playing it all night to keep it awake. The Heroku Hobby offering looks about the right size for a niche application like this, but costs $7 per dyno per month.

 

Of course, the project could provide instructions to the user on how to run it on a local host. Thus the first release could be a web application from day 1; with the issue of external hosting to provide mobile access, human v human gameplay, player score charts etc., a consideration to address a little later.

 

I wouldn't worry about hosting. That can be bought for a few quid a month and needs to be chosen after you've decided on your technology and approach. Fr example, .NET will need a different host (Windows) than php (Linux).

 

In my opinion, your first decision has to be whether you go for a single or multiplayer game.

 

The advantage of single player is someone can play a whole season in one day, against computer opponents. The meetings can also be "real time" meaning the player can choose to substitute riders, double points etc. similar to what you do in Flying Shale. The main downside is that you can only play with yourself(!) which I think in this day and age of MMOGs is a big drawback.

 

Compare this to a multiplayer game, where you'd play in a league alongside other real players. Fixtures would have to be scheduled, like in the real league, at a fixed time (say 7pm on a Sunday). The somewhat takes away from the real time element, as not all players will be available at that time, so you are dependent more on managers submitting their instructions in advance. You may also have to use a bit of artistic licence, as speedway management is fairly basis (no real squads, very basic tactics etc.) in order to make it interesting.

 

The other benefit of multiplayer, is that all players would choose their own team names and you'd need an infinite pool of riders, so there would be no point in using real names, therefore avoiding an licensing issues.

  • Like 1

Share this post


Link to post
Share on other sites

I prefer my software on the pc, bought with a single one-off payment rather than constantly being charged 'in-game' or monthly.

 

The current online with 'in-game' purchasing will be seen through eventually.

TBF, you're out dated there. Thats just not how you buy games and software any more. As a developer I love this, keeps making me/us money but as a purchaser of software it drives me mad. It also tends to make it harder to get dodgy copies.

Share this post


Link to post
Share on other sites

TBF, you're out dated there. Thats just not how you buy games and software any more. As a developer I love this, keeps making me/us money but as a purchaser of software it drives me mad. It also tends to make it harder to get dodgy copies.

Fine, I'm outdated. I'm also outdated in musical tastes and popular TV. I have no interest in celebrity gossip.

 

I have no problems at all with this. I vastly prefer choices carefully taken rather than following the herd.

 

Often what is 'popular' is in fact a case of people meekly accepting what is on offer. Of course businesses and developers want to charge regularly rather than just take one payment. Just because others accept this I it doesn't mean I have to.

 

I find it rather sad how conformity is so dominant today - that the greatest fear is to think for oneself and to challenge what is being blindly accepted by others.

 

Like many trends the current fashion will not last. People will eventually realise they are being ripped-off. I have a good stock of very useful software and am very well-equipped to ride out this rather greedy phase in I.T.

Edited by rmc
  • Like 1

Share this post


Link to post
Share on other sites

But I doubt games are going to move from being online based. Maybe billing mechanism will change, but online vs offline there is only one direction that is heading.

Share this post


Link to post
Share on other sites

The source for 5-1 was written in VB6, there are approx 250 pages of A4 printed single side - it is not logical for someone to transcribe this as it is outdated before you have even started.

 

In regards to the current popular subscription / in game transactions model - the reason it is now adopted so widely is because it works so well for the majority of people involved. Developers get a regular income which enabled them to stay in business, and make more money generally. Players get to "buy in" at a much lower cost than traditional models, they get more support from the developers as the developers are still around and not on holiday after one big payday, also more content and development is provided by the developers as they continue to support the games that continue to provide them an income. Its a great system, just some people don't like it.

 

As long as a game is not "pay 2 win" then I think its a fantastic model. I don't go in for subscriptions generally, but to be honest this would be a good model for this type of game as it would nicely cover the server costs to keep the game online. Once the subscriptions stop coming in, then the game is dead and you can shut down the servers. Also as long as there is subscriptions coming in to cover the servers, then you can keep them running - therefore the game will only die when people stop playing. Perfect IMO.

  • Like 1

Share this post


Link to post
Share on other sites

Like many trends the current fashion will not last. People will eventually realise they are being ripped-off. I have a good stock of very useful software and am very well-equipped to ride out this rather greedy phase in I.T.

I prefer to have my own copy like you, but there are genuine reasons to move to a subscription model. One is that Internet-based programs need continual updating to fix security flaws that keep getting discovered, as well as support technology changes like IPv6 and encryption, and the other is that can make the initial purchase cheaper which means a consumer is more likely to try out a program in the first place. The downside is they may simply drop it as well, so it's all swings and roundabouts.

 

In the 'good old days', you'd be paying 200 or 300 quid for office suite software, and 20-50 quid for a game. Nowadays you can buy an app for 3 or 4 pounds, and even Office 365 is only something like 60 pounds for a year's subscription. So you'll get 3-4 years use before you're out of pocket compared to the standalone version, and by then you'd usually need to think about upgrading the software anyway.

 

Of course, there is some software that still works and is even still useful after 10+ years, but that's the exception rather than the rule.

Edited by Humphrey Appleby
  • Like 1

Share this post


Link to post
Share on other sites

...

...

...

 

Q. Are any organisations/individuals reading this post willing to offer up previous code/algorithms to a hypothetical new Open Source 'Speedway Manager' project?

 

A. Not necessarily 'reading this post', but: there is a project called 'Speedway Meeting' which was published some years ago. Based upon a very quick glance, we're looking at VB5 or VB6. Now, taking this and 'converting' it to a leading open source technology like Java or Ruby is not gonna be simple - even before you get into considerations like spending any of your hard-earned cash on proprietary software that claims it helps you convert old VB code, and charges you the likes of £10 per 10,000 lines of code converted and whatnot. But, I think the key point is that the author of the project has obviously put a lot of work and a lot of thought into what they've done (even if they put somewhat less work into inline code commenting - and I'm not having a pop, author, if you're reading this - I'm grateful for your contribution - I'm simply making an observation about the understanding I have about the 'Speedway Meeting' code base as of now), and thus, my own concerns about what mathematical formulae to use are alleviated, because someone has had a crack at this before me, and made their work available.

 

I suggested a 'Speedway Manager' project should start by standing on the shoulders of giants - well, we have a set of formulae/logic, and comments from the author openly stating that someone converting 'Speedway Meeting' to a non-proprietary language like C would be a welcome contribution. For me, either Java or Ruby is the way to go for this particular project, with no disrespect to the mighty C intended. I will take a look in the days ahead and see whether I can feasibly reverse-engineer what has been done so far into Java and/or Ruby.

 

If I can set up and open-source a bunch of Java/Ruby classes containing that logic, it might get the ball rolling on a project where other contributors can do us in an ideal world some nice graphics, or at least some nice clean HTML5/JQueryUI etc. front-ends.

 

As always, I can't promise this will happen anytime soon as life tends to get in the way. I just thought it was worth a post given that this thread has been silent for a while, and that we do have some openly-volunteered formulae to give a starting point.

 

The author of the Visual Basic project 'Speedway Meeting' is very welcome to comment here and/or PM me.

Share this post


Link to post
Share on other sites

The author of the Visual Basic project 'Speedway Meeting' is very welcome to comment here and/or PM me.
Well I wrote Speedway Meeting which was originally written on a ZX Spectrum and eventually ported to VB6, so the code base is quite old now. VB was chosen because of the legacy code and that it was easier to build a Windows UI that way.
The basic result generating algorithm is quite simple though, and it should be fairly easy to port to something else. Most of the effort went into calculating the various probabilities of particular events happening (which required going through a year's worth of Speedway Stars), and then tuning the algorithm to ensure realistic results. Even the tactical, R/R and reserve substitution 'intelligence' is inherently straightforward, and I can explain it if you want to PM me.
Most of the programming work actually went into the scripting language and parser, as well as making the user interface configurable for every type of meeting. I realised early on that the speedway changes its meeting formats almost every season, so there needed to be a way to easily create new meetings.
If I was starting from scratch, I'd do some things differently as really everything needs to be linked to a database so entire seasons can easily be run and league table and averages compiled. However, that wasn't the original design criteria and I was somewhat more limited by things like available memory at the time. Equally though today, applications are moving to smartphone and tablets, and whilst I've given it some thought, I'm not really sure how the UI could be transposed to them. One problem I encountered early on is because so many text input fields needed to be fitted into one screen, I needed to use a system that displayed widgets in the most compact way possible, which just wasn't possible with HTML at the time.
As to language choice, well of course things have moved on over the past 10 years so some C derivative may no longer be the best choice. Other languages and frameworks come-and-go whilst C is usually portable over the ages, but most of the effort is in the UI anyway so it's probably not a huge amount of work to transpose the underlying algorithms to whatever's the current flavour in programming.
Edited by Kevin Meynell

Share this post


Link to post
Share on other sites

 

...
The basic result generating algorithm is quite simple though, and it should be fairly easy to port to something else. Most of the effort went into calculating the various probabilities of particular events happening (which required going through a year's worth of Speedway Stars), and then tuning the algorithm to ensure realistic results. Even the tactical, R/R and reserve substitution 'intelligence' is inherently straightforward, and I can explain it if you want to PM me.
...
Equally though today, applications are moving to smartphone and tablets, and whilst I've given it some thought, I'm not really sure how the UI could be transposed to them. One problem I encountered early on is because so many text input fields needed to be fitted into one screen, I needed to use a system that displayed widgets in the most compact way possible, which just wasn't possible with HTML at the time.
As to language choice, well of course things have moved on over the past 10 years so some C derivative may no longer be the best choice. Other languages and frameworks come-and-go whilst C is usually portable over the ages, but most of the effort is in the UI anyway so it's probably not a huge amount of work to transpose the underlying algorithms to whatever's the current flavour in programming.

 

 

Thanks for the response. A key reason behind my interest in seeing if an open source project could be started up, is in capturing efforts made in the past in a non-proprietary format that can be kept readily usable. It sounds like you have put a lot of work into the calculations (a year's worth of Speedway Stars!), so it is great that you are making the work available rather than keeping hold of it as intellectual property.

 

I understand your comments about old-school HTML, which was simply awful. Nowadays, in addition to nice clean HTML5, there are excellent open source libraries available to help with screen design for tablets or smartphones - JQuery Mobile springs to mind as one very good option.

 

As to programming language: don't get me wrong, C is still a rock-solid choice and had someone already converted the project to C for us, we would be further forward in that the code base wouldn't be in a proprietary format that the vendor (i.e. Microsoft) decided to effectively cut adrift with the advent of VB.Net. My previous employer (a well-known airline) faced the challenge of converting its VB6 projects to VB.Net to keep up; and there had to be an entire porfolio project reference to cover this, as the conversion is far from straightforward. However, a web interface is inevitable, which is why the likes of Java or Ruby spring to my mind as preferable choices for the mooted project.

 

I hope to have a look at this as a pet project in the weeks/months ahead, albeit life has a habit of getting in the way. If I do get my teeth into this and get stuck or don't understand anything, thanks for the offer to PM you which I will certainly do if I need to.

Share this post


Link to post
Share on other sites

Paul, at some point over the next few weeks I'll try and dig out as many of my started and parked up/failed projects as possible for you. Most are in C#/VB.net but if you're only looking for algorithms for determining heat results, tape touching, falls etc then the language simply doesn't matter. When I do get the code up over to you, be prepared, it's of a shockingly bad for someone who is paid to write code for a living :D

 

As for calculating FXs, EFs, Rs, Ts, Fs I just used the speedway-stats.co.uk database and calculated the % of each of them events and simply took a random number from 1-100 and said if ti was less than the % of times the event happened in real life and if it was, the rider FX'd, EF's etc. I've always planned to extend this by working out how often each rider in real life has them events occur. That way, you could give each rider a rating for mechanical, stability,time keeping etc. I'd also do the same for health, form, moral etc. My preferred way of deterring finishing order is for each meeting to take a riders average and give them a "meeting form" up lift of between say 0-3 (so on that day, a 3 pointer could actually have the form of a 6 pointer) and then do the same for each heat, take the riders average+meeting form and add on a heat form of 0-3 so on a very rare occasion and 3 pointer could ride a simple heat like a 9 pointer. It tends to work well as each riders end the season on a similar average to that they started- which is how it should work until you start putting in attributes for things like form /moral as I mentioned and take into account improving riders etc but I've never really got that far.

 

The other issue I have is how to handle the AI for other teams, I can get them to sign 7 random riders up to a point limit but how do you handle dropping and signing new riders? What about riders quitting? I've just rarely got this far and never had a "Eureka" moment.

 

Weirdly, one thing I got spot on was arranging fixtures than stopped clashes with doubling up riders to the point I suggested if the BSPA wanted it, they could ask me about splitting it into an application (probably web based) for them - I had to end up randomising it so riders missed meetings.

 

Another thing Ive never worked out quite how to do is finances. Do players manage entrance fees? Do you include vat? Do players negotiate contracts with riders? How do you determine attendance? randomised? based on clubs league position? based on oppositions league position? based on location of the opposition? Mixture of the above? I just don't know where to draw the line with detail and finances will be hell-ish to handle I think.

 

As for UI, I've rarely got this far! The thing I such at is UIs, I can do functional but for games I'm really struggling here. I tend to just stick a load of standard text boxes, labels and buttons on a screen on the boring grey screen :D

Share this post


Link to post
Share on other sites

I think the best game on the ZX Spectrum was Premier Promoter, wasted many hours on that

Share this post


Link to post
Share on other sites

My question for a game like the one described by SCB is how much interaction is there for the player? For example,you don't pick a team, you have minimal ability to choose rider positions (if you follow the current rules) and there is also limited scope to drop and sign riders. If the outcome of races are decided on averages then largely the good riders will win (and get progressively better) and lower riders will lose.

Share this post


Link to post
Share on other sites

My question for a game like the one described by SCB is how much interaction is there for the player? For example,you don't pick a team, you have minimal ability to choose rider positions (if you follow the current rules) and there is also limited scope to drop and sign riders. If the outcome of races are decided on averages then largely the good riders will win (and get progressively better) and lower riders will lose.

While I agree on the surface, how much interaction was their in "Speedway Promoter"? It was crap when you think about it but how many spent many hours playing? The trick will be to play fast and loose with the rules. Have a points limit yes but have squads, allow managers to put their top 5 in any order. I made sure of having quite a few doubling up clashes to make guests necessary.

 

I've tried to build something that will simply let me run a season as a team and almost "model" a season (and Ive done that) what I now need to do it add some AI so riders quiting, performing different on tracks as they change, the AI for the computer teams. The first part was quite easy in the scheme of things, it all the AI I now need and it's a PITA!

Share this post


Link to post
Share on other sites

I've tried to build something that will simply let me run a season as a team and almost "model" a season (and Ive done that) what I now need to do it add some AI so riders quiting, performing different on tracks as they change, the AI for the computer teams. The first part was quite easy in the scheme of things, it all the AI I now need and it's a PITA!

The solution to AI is multiplayer!

 

This makes it a bit more of a role playing game, as fixtures have to be scheduled, but to me this is the way forward.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy