For once, after not doing something, I decided that I was going to make a game. For some odd reason, I've always wanted to play a soccer game, so I started on it. I plan on making it a 2 on 2 soccer game, so probably not professional soccer...
So here is all I have right now, but I was wondering if I should add animation to the actual player itself. (Right now, it is kind of boring...)
Is this going to be one of those platformer type soccer games? because thats really cool :)
And yeah, you should add player animation :)
Eh, I'm not really sure yet. :-\
Because I could not figure out a way to have 4 players on a 2D screen, I decided that I would completely change how the game looked. I changed the view to an above view. The first time, it worked... But after the third or fourth time, the program slowed down a lot, and when I got to the edge of the field, some of the lines started to disappear. Also, I noticed that there are random copies of the playing field out of the map...
:.SOCCER
:
:[7884848484780000]->Pic1
:
:48->X
:32->Y
:
:Repeat getKey(15)
:ClrDraw
:Pt-On(46,30,Pic1
:Rect(X+100,Y-40,1,80
:Rect(X-100,Y-40,1,80
:Rect(X-100,Y-40,200,1
:Rect(X-100,Y+40,200,1
:If getKey(1)
:Y-1->Y
:End
:If getKey(2)
:X+1->X
:End
:If getKey(3)
:X-1->X
:End
:If getKey(4)
:Y+1->Y
:End
:DispGraph
:End
Quote from: SiphonicSugar on September 24, 2015, 09:31:12 PM
Eh, I'm not really sure yet. :-\
Because I could not figure out a way to have 4 players on a 2D screen, I decided that I would completely change how the game looked. I changed the view to an above view. The first time, it worked... But after the third or fourth time, the program slowed down a lot, and when I got to the edge of the field, some of the lines started to disappear. Also, I noticed that there are random copies of the playing field out of the map...
:.SOCCER
:
:[7884848484780000]->Pic1
:
:48->X
:32->Y
:
:Repeat getKey(15)
:ClrDraw
:Pt-On(46,30,Pic1
:Rect(X+100,Y-40,1,80
:Rect(X-100,Y-40,1,80
:Rect(X-100,Y-40,200,1
:Rect(X-100,Y+40,200,1
:If getKey(1)
:Y-1->Y
:End
:If getKey(2)
:X+1->X
:End
:If getKey(3)
:X-1->X
:End
:If getKey(4)
:Y+1->Y
:End
:DispGraph
:End
First of, use Line() for drawing lines. Second of, those getkeys() could be optimized.
:.SOCCER
:
:[7884848484780000]->Pic1
:
:48->X
:32->Y
:
:Repeat getKey(15)
:ClrDraw
:Pt-On(46,30,Pic1
:
:VLine(X+100,Y-40,80
:VLine(X-100,Y-40,80
:HLine(Y-40,X-100,200
:HLine(Y+40,X-100,200
:
:X+getKey(3)-getKey(2)->X
:Y+getKey(1)-getKey(4)->Y
:
:DispGraph
:EndThe weird "copies" occur because when you pass 256, the 8 bit number overflows back to zero, so you basicly end up at the beginning of the map, and vice versa, if x goes below zero it overflows to 255.
Oh, okay.
Somebody said that you should use Rect( to draw things...
Looking VERY cool! Maybe you could use pixeltest to check for boundries? I'm not sure about the lines, though.
Quote from: Unicorn on September 25, 2015, 02:45:01 AM
Looking VERY cool! Maybe you could use pixeltest to check for boundries? I'm not sure about the lines, though.
The most efecient solutionn i know of would be to surround the ketKey()-s inside a min() and max() statement. Maybe you could ask Runer112 or Hooloovoo about a better one ;)
:max(min(X+getKey(3)-getKey(2)->X,80),0)^^r
:max(min(Y+getKey(1)-getKey(4)->Y,200),0)^^r
(Note that the max statement ends with an radical 'r' above it.)
Quote from: c4ooo on September 25, 2015, 10:49:04 AM
:max(min(X+getKey(3)-getKey(2)->X,80),0)^^r
:max(min(Y+getKey(1)-getKey(4)->Y,200),0)^^r
I may be wrong, but shouldn't the ->X and the ->Y be at the end of the lines instead of inside the min() and max()?
Quote from: ben_g on September 25, 2015, 12:33:35 PM
Quote from: c4ooo on September 25, 2015, 10:49:04 AM
:max(min(X+getKey(3)-getKey(2)->X,80),0)^^r
:max(min(Y+getKey(1)-getKey(4)->Y,200),0)^^r
I may be wrong, but shouldn't the ->X and the ->Y be at the end of the lines instead of inside the min() and max()?
O lol your right :-[
I forgot to move it :P
But how would I make it so the X value is not allowed to go over 112 and it is not allowed to go under 0? Same for Y: not allowed to go over 59 and not allowed to go under 6.
Also, the VLine and HLine thing did not really work... The map did not look anything like how it should have. I changed it back to Rect (hopefully temporarily) because I wanted to change the size of the map.
I can't help due to not doing Axe, but I prefer the game being top-down view like in the 2nd screenshot, since it could allow you to make something closer to popular sports games at some point. For example it could be 2 vs 2 with the goalie controled by some basic AI.
Yeah, I noticed that a wouldn't be able to add more than two players on the first way, so I decided to make it an above view.
I have most of the actual soccer ball part planned out... I think. So that is good news! :w00t:
Have you gotten any luck with collision detection?
Quote from: SiphonicSugar on September 25, 2015, 09:24:45 PM
But how would I make it so the X value is not allowed to go over 112 and it is not allowed to go under 0? Same for Y: not allowed to go over 59 and not allowed to go under 6.
Also, the VLine and HLine thing did not really work... The map did not look anything like how it should have. I changed it back to Rect (hopefully temporarily) because I wanted to change the size of the map.
But isnt your x range 0-80 and your y range 0-200? To do what you want you will have to change the getKey() statements. The bigger, inner number is the max and the zero on e outside is the min.
How did the HVLines look? Can you provide a better description?
I decided to change the size of the field, but I will get to that later.
Here is what it looks like with the VLine and HLine...
Well actualy there are several things wrong :-\
First of my code for movment is slightly bugged and will not prevent you from going bellow zero (and underflowing to the max cord).
Second of, the way the cordinate is calculated is wrong, and i failed to see it. Instead of doing "X_Render_At = X_Position + X", it should be "X_Render_At = X_Position - X". (notice the subtraction)
The last problem is that all drawing commands in axe accept signed bytes, meaning that instead of being a number 0 to 255 the number is -127 to 128. This way it will be hard to render such a long field, without using hackish clipping. (Basicly axe is thinking you want a line from 32 to -24 instead of 32 to 232, for example.
Ile see what i can come up with :P
Okay, thanks!
Also, how did you learn so much about Axe?
Quote from: SiphonicSugar on September 29, 2015, 08:00:45 PM
Okay, thanks!
Also, how did you learn so much about Axe?
Well, i just spent a lot of time making demo games. Eventually, i started to have a basic understanding of how the language works under the hood, and knowing about the architecture of the CPU and the rest of the calc helped. (well.. i actualy know next to nothing about the architecture of the calc itself) But by being aware of the z80 architecture, i basicly understood about how the CPU is 8 bit (but contains 16 bit instructions) and the limitations it imposed and how to do bitmath etc etc... It still took me some time to grasp consepts such as signed numbers etc etc..
But, rant aside, it seems i got some working and optimized code for a 80*120 field :D Also keep in mind that although i know alot of axe concepts, people like
@Runer112 know more ;) Basically this is the code i came up with:
.FOOTBALL ;)
[78848484847800]->Pic1
48->X
32->Y
Repeat getKey(15)
ClrDraw
Pt-On(46,30.Pic1
max(min(X+getKey(3)-getKey(2),76)^r,3)^r->X
max(min(Y+getKey(1)-getKey(4),196)^r,3)^r->Y
48-X->S
128-X->T
If y<33
HLine(32-Y->N,S,T
End
VLine(S,N,min(232-Y,127)^r->O)
VLine(T,N,O)
HLine(O,S,T
DispGraph
End
I may have made an error or two in copying the code, but it should work. Also note that this code uses the N,O,S and T vars. :thumbsup:
Hmm... Pretty advanced stuff ya got there! ;)
I'll learn to work with it!
I tried to compile it, and it gave me the error "WRONG # OF ARGS"
It went down to the first max( command... so I suspect that the second one is like that too.