Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[skateblind]

Project Name: Serious F1

Type: Formula 1 Racing

Language: AMOS Professional

Team:
Skateblind - Concept, Programming, Graphics
Hungry Horace - Concept, Programming, Graphics, Guidance
Mihcael - Car Graphics

Inspiration:
Indy Heat


Sensible Software


Concept:

I started programming this game after playing Indy Heat with some friends and wanted to create something similar, but with more detail and variety. A few weeks or months later an online friend called Hungry Horace told me about a similar game he wanted to create, which would be a cross between the game Indy Heat, the sport Formula 1 and using a similar style to the game developers Sensible Software. I loved this idea and told him I would like to work together with him on this project. This is how Serious F1 was born.

Aims:

Before I had decided to create Serious F1 my aims were to create a top down racing game where you could see the whole track/map on one screen with 32 colours. This was fine for what I was planning, but when me and Horace spoke about how Serious F1 should look, we decided that big race track would be best, but this required 8-way scrolling. I then spent the next few weeks trying to program this, but with the programming language AMOS Professional, it was harder to do than first appeared. I did eventually get a few different types of scrolling working, but none of them were fast enough or smooth enough. We did get an offer from someone to create some code in a different language that would give AMOS Professional the speed boost we needed, but they have been so busy with real life and their own personal projects that it has been put on hold for a while.

This is when I decided to continue with the game but only using a single screen or a limited version of 8-way scrolling. When the game is complete, we will start a second version or sequel of the game with more features and a large 8-way scrolling race track, but it may mean we have to use a faster programming language to create it.

Original version:

http://www.youtube.com/v/osq9vccOQec&hl=en&fs=1 

In the next diary I will show some video of the current version and will discuss how we implemented the turning and moving of vehicles. Don't expect much, it is still very basic, but it has some solid foundations to be a great game.

There is a copy of the very first version attached to this post for you to laugh at. Just extract into a folder in WB and run the program file, it works on an A1200, but should work on most other systems too. Enjoy!

[Lonewolf10]

Downloaded and will play it tomorrow.

Did this ever get finished??

[Hungry Horace]

it did not, but it was close to inspiring me to do something similar. I began work on a driving engine that would be used for the ill-advised and not very friendly titles "retards in a field"....

https://www.youtube.com/watch?v=FzjIkXJZj7Y

(original MSX version appears not to be on youtube any more)

After deciding that this was not a very advisable venture, i began improcing the driving engine and was considering trying to make a game a bit like Indy Heat or Super Off Road with it.

[Lonewolf10]

It has a 'Super Sprint' feel about it to me

[Hungry Horace]

i've decided to dig out that code i spoke of.

I am currently re-colouring some half-size versions of the cards from the unreleased "Big End": http://hol.abime.net/5558/screenshot

For test-tracks i'll probably used something from Indy Heat.

[Hungry Horace]

Been thinking about the potential for this game a little bit more... I have some neat ideas regarding it- using 28 years of F1 history and using the top four teams of each year as the available cars in this game......

It would need a lot of graphics and tracks and things but it could be pretty good.  I will try and focus on building a full race-game engine first before going too deep on all the surrounding elements!

[Hungry Horace]

OK guys....  Here is one for you.

I have my cars moving around, all good.  Firstly i'd like to address interaction with the scenery before i move onto bob-to-bob collision and then zones for tracking your way around the course.  (and finally AI!!)

So my first thought is ... how the hell do i do the double layering of my background, so that  the cars travel 'behind' certain objects?  I assume it is something similar to what is done for parallax scrolling but;

 - I do not need to move anything!
 - I want to minimise any 'speed' loss as a result of what is used.

I have used a copy of the first circuit from Indy Heat for now, and i have created a second copy of the image for all of the "in front" items.


Any help appreciated, and happy to upload my current code if needed!



edit: i feel like SET BOB and it's mask options should let me do this, but i'm damned if i can work out how....

I have created a 2 colour mask image I hope to be able to use but the documentation on SET BOB is sparse and I am thinking I may need to trawl through some examples downloaded from this site!!

Anyone had any experience with this kind of thing?

Edit 2:
It didn't even occur to me I may be able to use hardware sprites if I am only using 4 cars in 16 colours (and may come with some nice advantages) , since my cars are very small.

I have no idea if this will make my mask problem easier or harder to solve though....

[Hungry Horace]

i have my cars running around now and colliding with borders.

I would be happy to share the dropbox development folder for it with anyone interested in trying to improve my main game-engine code!!

[Hungry Horace]

I am now positive that it would be great to get the hardware sprites "hidden" (I.e. Not drawn ) in certain locations.

I have an idea how, just no idea of how to implement it.

This is Assuming that I need a bitplane specifically as a "mask" one could merge two iffs and only display the planes 0-3 for the main track, then use plane 4 as the mask.

[Lonewolf10]

Sounds like this is coming along nicely

I like the idea of cars going behind scenery  (bridges?). You could use a dual-playfield - back one for the background and foreground one for the objects you wish the cars to go behind. Assuming that AMOS allows us to set sprite priorities so that they can go behind the foreground playfield.

[Hungry Horace]

Sounds like this is coming along nicely

I like the idea of cars going behind scenery  (bridges?). You could use a dual-playfield - back one for the background and foreground one for the objects you wish the cars to go behind. Assuming that AMOS allows us to set sprite priorities so that they can go behind the foreground playfield.

any help on this would be apprecaited!!

the main Dual PLayfield command only seems to allow for two 8 colour screens to be overlayed?

my other thought was to have a small number of bob's which covered items like bridges etc, but i do not know if it is possible to have these "in front" of my hardware sprites.   this might become "essential" anyway, if i wish to have an animated pit-crew.... i am not sure if this means, long-term i even have to switch back to using BOBS for my main cars (this would be a shame, given how fast the hardware sprites can be!)

[Lonewolf10]

any help on this would be apprecaited!!

I'm up to my neck in my own (ASM) game.

the main Dual PLayfield command only seems to allow for two 8 colour screens to be overlayed?

I don't think I have ever used the dual playfield commands, so I'm not sure if that is configurable in any way. Sounds like it will use the 3 even bitplanes for one playfield and the 3 odd bitplanes for the 2nd playfield.

my other thought was to have a small number of bob's which covered items like bridges etc, but i do not know if it is possible to have these "in front" of my hardware sprites.

Bobs are blitted objects onto the bitplanes. If AMOS allows us to choose which bitplanes the sprites appear behind (and infront of) then it could be doable with clever colour selection. They wouldn't necessarily need to be Bobs either, they could already be drawn onto the level.

[skateblind]

I've been thinking on how to implement the AI drivers and cannot really figure out a streamlined approach that won't cause amos to slow down from the checks/calculations.

Best idea I can come up with is having a preset racing line that the AI may or may not deviate from depending on certain checks. You can include collision or overtaking checks, but it will slow everything down imo.

Thoughts?

[bruceuncle]

Stuffed my back, so tapatalk it is.
Two things to consider for AI in a game.  One is the physics, the other is the 'intelligence'.
By physics I mean that the viewer expects to see stuff in the right place at the right time and looking/behaving like it would in the real world.  In Amiga/AMOS terms that means sprites, bobs and background being in the right place and having the right image.  So it breaks down to X/Y position and correct image for each component of the simulation. That's the easy bit as we've mostly all done that sort of design and programming before.  That side of the sim clocks along in sync with the Amiga's 50 fps 'heartbeat'.  So the code aims for fastest possible physics calculations to keep a smooth visual flow.
The 'intelligence' side of the sim has to align itself to the 'realism' of how things behave.  It's a mistake to assume that this has to follow that same 50 fps beat.  In the real world, most people average a 600 millisecond reaction time.  That's 30 frames to  react.  A good F1 driver may get that down to 10 to 20 frames - still oodles of time to work out AI calcs for the sim.
If you design data structures for each object that contain movement vectors and image info (eg.  dX, dY & image-num) the object can update itself every frame unless told otherwise.  In other words its behaviour is not dependent on an AI update each frame.  The AI doesn't (always) need the same rate of update to meet 'real world' expectations.
If you arrange your object data structures in the traditional list, the one you iterate through each Vbl, you can include an update timer in each one: decrement a counter in each data structure until it hits zero.  This allows you to do the physics side of the sim for each object once every frame and the AI calcs only once every few frames when its timer 'fires'.
How much time each object needs between its AI updates will depend on what it represents in the game. 
You could also add rules that only one AI object update is allowed per frame to avoid a whole heap of them occurring together.  Any whose timers happen to fire in the same Vbl just get deferred until the next Vbl.  Eg. The counters fire when they get to zero or go negative, but if an AI update's already happened in a Vbl, ignore any others until the next one. 
That's the concept. I'll try and explain it better when I can get back to my PC.  Tapatalk is still like trying to reply through a keyhole for me.  So hope this makes some kinda  sense

Sent from my Lumia 800 using Tapatalk

[Hungry Horace]

yes, i get the idea about only doing one AI update in a frame, and the timer thing for each is quite nice... that's some pretty neat stuff you've mentioned in there bruceuncle.

I intend to program purely as a multiplayer game, and when AI is added it will simply replace the 'input' value (i.e. joystick inputs), with the AI one where needed. This will insure the 'physics' is totally correct, as i will be making sure this is all correct prior to even attempting the AI.

Frequency of AI updates may dictact intelligence quite nicely. There's no real need for full racing-lines to follow, although i will use something similar to make the car head to the next 'zone' when judging it's next move (which is required by the normal players anyway to ensure we 'count' our way around the track anyway, without going backwards!)



I've been forced to take a bit of a break by my wife atm, on account of needing to do some decorating! (meaning my spare time is generally not laptop based, so i have been watching a few old Grand Prix's as research!)   However, i am considering a lot of the time what's next for the game....

I would like to nail the following in roughtly this order, but i dont have any 'need' to do these myself, and am more than happy to share my code/dropbox folder for anyone to contribute code. Once these are done the basic game-structure is in place and everything else is just data, graphics and menus. (the latter of which i enjoy coding anyway as its so much easier!)

 - General Physics / car handling (could be improved from where it is)
 - Imroved graphics drawing, hopefully with 'overlay' areas as discussed.
 - collision detection with walls / slow areas (gravel traps)
 - zones / track markers / lap monitoring
 - collision detection with other cars
 - CPU / AI