Solar Plexus Preview!

[Jess Ragan]

Whoohoo! Here's a preview copy of my game, which I've dubbed "Solar Plexus". I estimate it as being 85% complete... all that's left is to add sound and playtest it thoroughly to check for bugs.

 

I'm really happy with my game... not just because I made it, but because it's actually fun to play. It starts out slowly but builds up in speed as you collect more and more fuel pods. Collect enough and the game slows back down, but the "panic level" rises, causing the bouncing fireball to grow in size, then split apart. I've only been able to make it to the third panic level myself... how long can YOU last?

 

When it's finished, I'm going to talk to Albert to see if he'd be willing to distribute it through the Atari Age store. It's not quite professional quality, but I personally think it's good enough to justify a cartridge release.

 

JR

solplex.bin

[supercat]

I'm really happy with my game... not just because I made it, but because it's actually fun to play.  It starts out slowly but builds up in speed as you collect more and more fuel pods.  Collect enough and the game slows back down, but the "panic level" rises, causing the bouncing fireball to grow in size, then split apart.  I've only been able to make it to the third panic level myself... how long can YOU last?

895456[/snapback]

 

Cute title screen, given the kernel restrictions, though an ASM one might be better.

 

The game concept is amusing and somewhat playable, though when the target is distant and the fireball is timed to hit it at the same time as a ship on optimal path, there's not really much the player can do. I would think the game might be better if it used both missiles as targets and offered a few variations:

1. Both missiles always on screen, and can be gotten in any sequence.
   
2. Both missiles start out on screen and can be gotten in either order, but first one gotten won't reappear until second is gotten, whereupon both will reappear.
   
3. Both missiles appear on screen, but player can only usefully grab the one that matches the player's color. Grabbing that will cause the fireball-colored one to become the player's color while a new fireball-colored missile reappears (thus giving the player a heads-up as to where the next missile is going to be).
   

Otherwise, a few more that might improve gameplay:

• Visible screen borders, so as to allow the player to better judge where the fireball will bounce. Perhaps setting COLUBK to something other than black would accomplish this.
  
• Diagonal moves and/or accelleration.
  
• Some penalty other than sudden death for using more than the optimal number of fuel. I think a game called Roadblasters used a good scheme: the player has a 'normal' tank and a 'reserve' tank. At each stage, the normal tank gets filled but the reserve tank does not, though goodies are available to boost it slightly.
  

Despite the game's simplicity, it does have definite charm.

[Jess Ragan]

Thanks for the thoughtful response and advice. Actually, you CAN accelerate in the game... just hold down the fire button and your ship doubles in speed.

 

As for diagonal control, I'm not going to add it for two reasons. The first is that I want Solar Plexus to play like Solar Fox... in fact, the original working title for the game was Solar Cub, a reference to its more limited scope. The second is that it would require more code and more graphics, and as it stands now I've only got a couple of kilobytes left.

 

Your other suggestions do have promise, though. Originally, the fuel pods were supposed to be randomly scattered throughout the screen, but this resulted in the player touching them the moment they appeared, resulting in undeserved points. Trying to fix the problem resulted in an infinite loop, although if I gave it another go I could probably find a way around this.

 

I was thinking of doing SOMETHING with the second missile... perhaps use it to illustrate the thrust from the ship when you hold down the fire button and activate the retro rockets. It could also make a pretty good obstacle for those players who feel that the game isn't difficult enough, or a bonus item to add variety to the game. There's enough space left to include a few more gameplay elements like these... I'll have to brainstorm a little to figure out what would work best.

 

I'd LOVE to do an ASM title screen. I played a handful of official 2600 games after thoroughly playtesting Solar Plexus, and was stunned at just how good some of those screens looked; particularly the ones in later releases like Crystal Castles. I'm just not sure HOW I could do this. Either it would have to be explained to me or color layering will have to be included in a future Batari BASIC release.

 

JR

[supercat]

Thanks for the thoughtful response and advice.  Actually, you CAN accelerate in the game... just hold down the fire button and your ship doubles in speed. 

 

Well, by "accelleration" I was thinking of Spacewar-style, but thanks for telling me about the fire button. Makes the game much more playable.

[kisrael]

Your other suggestions do have promise, though.  Originally, the fuel pods were supposed to be randomly scattered throughout the screen, but this resulted in the player touching them the moment they appeared, resulting in undeserved points.  Trying to fix the problem resulted in an infinite loop, although if I gave it another go I could probably find a way around this.

I gotta say, there are worse things in the world than "undeserved points". It's a little bad if the player can't see what just happened, but given that they just touched one fuel, they probably would barely see it.

 

thoroughly playtesting Solar Plexus, and was stunned at just how good some of those screens looked; particularly the ones in later releases like Crystal Castles.  I'm just not sure HOW I could do this.  Either it would have to be explained to me or color layering will have to be included in a future Batari BASIC release.

I was pretty happy how the JoustPong title screen came out. The code for that would be pretty easy to extract, maybe I should do that for people. (and I've been skimping on that update to playfield pal...

 

Though it's not good if you're almost out of ROM, big cheesy graphics like that are some of the biggest ROM sucks. (Though a "couple of K" left? You should be starting with like 4 only!)

 

But frankly, I think your title screen looks great. On Z26 at least...I thought "wow, it has a cool electric-y flicker, and it's pretty high-rez" forgetting that was because you were having to flicker sprites just to display all the letters. I think it fits in well with the overall aesthetic of the game, better than a big PF graphic one would.

Edited July 21, 2005 by kisrael

[s0c7]

Just gave it a whirl. Took me a few tries to get the "feel" for it. But after that, it was quite fun. Very unforgiving for the uncoordinated though ( ). On 2 occasions the score semi-corrupted on me (see screenshot). It's not something I can replicate, and it could be the version of z26 I'm running or a bB bug or who knows what.

Edited July 21, 2005 by s0c7

[chad5200]

Nice job! Any chance of posting your .bas file?

[+batari]

Nice job!  Any chance of posting your .bas file?

896175[/snapback]

If you do, I can help with the score issue above and either recommend a fix to your code or expose a bug in bB

[supercat]

But frankly, I think your title screen looks great. On Z26 at least...I thought "wow, it has a cool electric-y flicker, and it's pretty high-rez" forgetting that was because you were having to flicker sprites just to display all the letters. I think it fits in well with the overall aesthetic of the game, better than a big PF graphic one would.

895628[/snapback]

 

I'm not a big fan of big single-color PF graphic title screens. But a kernel option to replace specified rows of the PF and everything else with a 48-wide vdel sprite or a 96-wide flickersprite might be cool, especially if the data was 7 or 13 bytes wide to accommodate colors.

[+batari]

I'd LOVE to do an ASM title screen.

895529[/snapback]

I've taken this code from the title screen of the 2005 Minigame Multicart, and converted it to work with bB. The code doesn't look much like Basic, as it's almost entirely asm and data statements, but it will work by simply pasting at the end of a program. Of course, the GFX now say "Solar Plexus" which was created with Eckhard's PCX2GRP utility. I didn't create the text either, it's just a Windows font scaled to 48 pixels wide.

 

Feel free to use this in your game, or others may modify the data statements with their own GFX data to create their own title screens. Note that this asm is its own mini-kernel. To call it, simply put "gosub titlescreen" in a loop somewhere without calling drawscreen in the loop.

 

It should compile in Alpha 0.2. But it does screw up the "bytes free" and claims 5 bytes, which is bogus. It will actually just reduce your bytes free by around 350-400 bytes.

title.bas

[Jess Ragan]

Nice job!  Any chance of posting your .bas file?

896175[/snapback]

If you do, I can help with the score issue above and either recommend a fix to your code or expose a bug in bB

896182[/snapback]

 

Sure... let me just paste it in this post. All right, there we go! Now, don't anyone get any wacky ideas and start releasing suspiciously familiar games like "Solar Nexus", "Solar Lexis", and "Solar Austin Texas"!

 

Just to let you know, the points earned for each fuel pod collected don't even come close to complying to the BCD numeric format (you get ten points, multiplied by the amount of fuel remaining). I'm not even sure how I'd be able to pull that off... it seems like as the score continues to rise, it would be inevitable to run across a BCD incompatible number.

 

JR

 

P.S. Oh yeah, one more thing. Here's the latest version of the game in binary format.

 

1 rem smartbranching on
2 rem Solar Plexus
3 rem by Jess Ragan, for Batari BASIC
4 rem
5 rem initialize all variables used in the program
6 rem x/y is ship position, a/b is fireball position
7 rem v/w is ship direction, c/d is fireball direction
8 rem t is fuel gauge, u is game timer, l is level
9 rem
10 goto 5000
20 score = 0
30 p = 0 : q = 2 : e = 0
31 rem set up screen; character positions
32 rem fuel pods will be included next
33 rem
35 x = 90 : y = 45 : v = 0 : w= 255 : t = 24 : u = 0 : f = 0 : n = 0
36 a = 25 : b = 50 : c = 1 : d = 1 : l = 1 : j = 140 : k = 60
40 COLUPF = 128
50 COLUP0 = 84 : player0x = x : player0y = y
60 COLUP1 = 68 : player1x = a : player1y = b
65 missile0x = j : missile0y = k : missile0height = 2
70 scorecolor = 15
75 for i = 0 to q : e = i * 2 : pfpixel e 10 on : next i
80 pfhline 8 10 24 on
81 rem choose animation frames
82 rem ship animation depends on current direction
83 rem
90 if w <> 255 then 110
100 player0:
%10000001
%10011001
%11011011
%11111111
%10111101
%00011000
%00011000
%00011000
end
110 if w <> 1 then 130
120 player0:
%00011000
%00011000
%00011000
%10111101
%11111111
%11011011
%10011001
%10000001
end
130 if v <> 255 then 150
140 player0:
%00011111
%00001100
%00011000
%11111111
%11111111
%00011000
%00001100
%00011111
end
150 if v <> 1 then 170
160 player0:
%11111000
%00110000
%00011000
%01111111
%01111111
%00011000
%00110000
%11111000
end
161 rem fireball animation is next on the menu
162 rem fireball animation dependant on the 'n' timer
163 rem
170 if n > 4 then goto 200
180 player1:
%00000010
%11001110
%01101100
%01111000
%00011110
%00110110
%01110011
%01000000
end
190 goto 210
200 player1:
%00011000
%00110000
%00110110
%00011111
%11111000
%01101100
%00001100
%00001000
end
201 rem joystick movement determines ship's direction
202 rem
210 if joy0up then v = 0 : w = 255
220 if joy0down then v = 0 : w = 1
230 if joy0left then v = 255 : w = 0
240 if joy0right then v = 1 : w = 0
241 rem screen borders stop ship from advancing
242 rem
250 if x < 20 then x = 20
260 if x > 160 then x = 160
270 if y < 10 then y = 10
280 if y > 80 then y = 80
281 rem screen borders reverse fireball's direction
282 rem
290 if a < 20 then c = 1
300 if a > 160 then c = 255
310 if b < 10 then d = 1
320 if b > 80 then d = 255
321 rem move onscreen characters
322 rem ship is propelled forward at a constant rate
323 rem
330 x = x + v : y = y + w
340 for i = 1 to l : a = a + c : b = b + d : next i
341 rem holding down fire button activates retro rockets
342 rem this doubles the speed of your ship
343 rem
350 if joy0fire then x = x + v : y = y + w
351 rem it's the final countdown!
352 rem the 'u' timer advances.  When it reaches ten
353 rem 'u' is reset to zero and the fuel gauge shrinks
354 rem
360 u = u + 1 : n = n + 1
365 if n = 10 then n = 0
367 e = 5 - p : e = e * 2 : e = e + 9
370 if u > e then pfpixel t 10 flip : t = t - 1 : u = 0
371 rem watch your fuel gauge.  Keep it replenished
372 rem by grabbing fuel pods.  If you fail to 
373 rem collect a pod in time, you will perish!
374 rem 
380 if t = 7 then 1000
381 rem set player sprites, then draw them
382 rem
390 COLUP0 = 84 : player0x = x : player0y = y
400 COLUP1 = 68 : player1x = a : player1y = b
401 rem time for some blinking fuel pod action!
402 rem
410 missile0x = j : missile0y = k : missile0height = 2
420 NUSIZ0 = $00
430 if n < 5 then 450
440 NUSIZ0 = $10
450 gosub 3000
491 rem check for collisions
492 rem
500 if !collision(player0,player1) then 1000
510 if !collision(player0,missile0) then gosub 2000
520 drawscreen
521 rem you go back, Jack, and do it again
522 rem wheels turnin' round and round
523 rem
530 goto 90
995 rem ship destruction sequence
996 rem the ship cycles through colors then
997 rem vanishes from sight.  You have three
998 rem lives; lose them all and the game ends
1000 for t = 1 to 5
1010 for i = 16 to 30
1020 COLUP0 = i : scorecolor = i : player0x = x : player0y = y
1030 COLUP1 = 64 : player1x = a : player1y = b
1040 gosub 3000
1050 drawscreen
1060 next : next
1070 if switchreset || joy0fire then 1200
1080 COLUP0 = i : scorecolor = i : player0x = x : player0y = y
1090 COLUP1 = 64 : player1x = a : player1y = b
1100 gosub 3000
1110 drawscreen
1120 goto 1070
1191 rem subtract one life from player's stock
1192 rem if all lives are lost, the game ends
1193 rem
1200 player0x = 0 : player0y = 0 : player1x = 255 : player1y = 255
1210 drawscreen
1250 e = q * 2 : pfpixel e 10 off
1260 q = q - 1
1270 if q = 255 then 5000
1300 goto 35
1991 rem when the ship touches a fuel pod,
1992 rem the player's fuel supply is restored
1993 rem and points are awarded depending on
1994 rem what fuel is remaining.  The next pod
1995 rem is placed randomly on the screen
1996 rem
2000 i = t - 6 
2010 for t = 1 to 5
2020 i = i * 5
2030 next
2040 score = score + i
2050 t = 24 : pfhline 8 10 24 on
2060 rand = a
2070 if j = 40 then j = 140 : goto 2090
2080 s = 0 : j = 40
2090 k = rand
2100 if k > 70 then k = k - 70 : goto 2100
2110 k = k + 10
2120 f = f + 1
2130 if f = 3 then f = 0 : l = l + 1
2140 if l = 4 then l = 1 : p = p + 1
2150 if p = 6 then l = 5 : p = 5
2160 missile0x = j : missile0y = k : missile0height = 2
2200 return
2991 rem panic factor
2992 rem this determines the size and number
2993 rem of the fireball(s) attacking you
3000 if p = 1 then NUSIZ1=$05
3010 if p = 2 then NUSIZ1=$01
3020 if p = 3 then NUSIZ1=$02
3030 if p = 4 then NUSIZ1=$04
3040 if p = 5 then NUSIZ1=$03
3050 return
4991 rem this is the title screen
4992 rem pretty snazzy, huh?  Yeah,
4993 rem I thought so, too
5000 x = 72 : y = 35 : a = 72 : b = 45 : u = 0 : i = 0
5010 COLUPF = 0
5020 COLUP0 = 30 : player0x = x : player0y = y
5030 COLUP1 = 46 : player1x = a : player1y = b
5035 missile0x = 0 : missile0y = 0
5040 scorecolor = 0
5050 u = u + 1 : if u = 3 then u = 0
5060 on u goto 5100 5200 5300
5100 player0:
%00001110
%00000010
%00000010
%00000010
%00001110
%00001000
%00001000
%00001110
end
5110 player1:
%10001110
%10001000
%10001000
%10001000
%11101000
%10101000
%10101000
%11101000
end
5120 x = 72 : a = 72
5130 goto 5400
5200 player0:
%11101110
%10101000
%10101000
%10101000
%10101000
%10101000
%10101000
%11101000
end
5210 player1:
%11101010
%10001010
%10001010
%10000100
%11100100
%10001010
%10001010
%11101010
end
5220 x = 88 : a = 88
5230 goto 5400
5300 player0:
%10101010
%10101010
%10101100
%10101100
%11101110
%10101010
%10101010
%11101110
end
5310 player1:
%11101110
%10100010
%10100010
%10100010
%10101110
%10101000
%10101000
%10101110
end
5320 x = 104 : a = 104
5330 goto 5400
5400 COLUP0 = 30 : player0x = x : player0y = y
5410 COLUP1 = 46 : player1x = a : player1y = b
5420 NUSIZ0=$05
5430 NUSIZ1=$05
5440 drawscreen
5450 if joy0fire then i = i + 1
5460 if switchreset || i = 7 then 20
5470 goto 5050

solplex.bin

[+batari]

Just to let you know, the points earned for each fuel pod collected don't even come close to complying to the BCD numeric format (you get ten points, multiplied by the amount of fuel remaining).  I'm not even sure how I'd be able to pull that off... it seems like as the score continues to rise, it would be inevitable to run across a BCD incompatible number.

...

2040 score = score + i

Yes, it's definitely due to this line of code. While it's not terribly hard to convert decimal to BCD, in this case, I think all you really need to do is just fix up "i".

 

That is:

 

2039 temp1=i & 15:if temp1>10 then i=i+6

2040 score=score+i

 

I *think* this will guarantee that the second hex digit of "i" is always 0-9, but I haven't tested it.

[supercat]

2039 temp1=i & 15:if temp1>10 then i=i+6

2040 score=score+i

 

I *think* this will guarantee that the second hex digit of "i" is always 0-9, but I haven't tested it.

896312[/snapback]

 

How about doing something like:

; To add 'i' to score:
t=t+i
; Elsewhere in the frame loop
if t>0 then t=t-1:score=score+10

This should work for adding any number of points up to 2550, with the caveat that adding too many points too quickly could cause overflow in 't'.

[Jess Ragan]

I tried Batari's solution and it didn't seem to work. I don't think Supercat's will work either because the score is calculated only AFTER a fuel pod has been collected, and it's not just t, but rather t - 6 (to make up for the position of the fuel gauge onscreen), times ten.

 

Having looked through my code, I did notice an error that I made, although I don't think it mattered all that much. I was multiplying i by 5 rather than 2, but since any multiplying over 2 automatically defaults back to 2 in the current version of Batari BASIC, the compiler didn't see a difference.

 

So, what's the secret to BCD/decimal conversion? It looks like I'll need to know to fix this bug.

 

Thanks for all the help, by the way!

 

JR

[+batari]

I tried Batari's solution and it didn't seem to work.  I don't think Supercat's will work either because the score is calculated only AFTER a fuel pod has been collected, and it's not just t, but rather t - 6 (to make up for the position of the fuel gauge onscreen), times ten. 

 

Having looked through my code, I did notice an error that I made, although I don't think it mattered all that much.  I was multiplying i by 5 rather than 2, but since any multiplying over 2 automatically defaults back to 2 in the current version of Batari BASIC, the compiler didn't see a difference.

 

So, what's the secret to BCD/decimal conversion?  It looks like I'll need to know to fix this bug.

 

Thanks for all the help, by the way!

 

JR

896541[/snapback]

Some simple math is all that's needed to convert. if "i' contains a decimal number, in C, I think all you would need to do is i=i/10*16+i%10 or something like that. I tried converting this to bB, but for some reason I couldn't get it to work. When we get full divide and multiply functions in there, it will be simple.

 

By the way, did you see/try my title screen ASM code posted above in this thread?

[Jess Ragan]

Saw it and tried it. It's pretty cool! I just need to adapt it to my game, although right now I'm concentrating primarily on sound, which is an especially harsh mistress.

 

JR

[supercat]

I tried Batari's solution and it didn't seem to work.  I don't think Supercat's will work either because the score is calculated only AFTER a fuel pod has been collected, and it's not just t, but rather t - 6 (to make up for the position of the fuel gauge onscreen), times ten. 

896541[/snapback]

 

Sorry, I hadn't noticed 't' was used for something else. Well, pick some variable that isn't (is 'g' free?). In the frame loop, if it's not zero, add 10 to the score and subtract 1 from it. Otherwise, to add some value (times ten) to the score, just add it to the variable and a few frames later it will be added to the score.

[+batari]

2039 temp1=i & 15:if temp1>10 then i=i+6

2040 score=score+i

 

I *think* this will guarantee that the second hex digit of "i" is always 0-9, but I haven't tested it.

896312[/snapback]

 

How about doing something like:

; To add 'i' to score:
t=t+i
; Elsewhere in the frame loop
if t>0 then t=t-1:score=score+10

This should work for adding any number of points up to 2550, with the caveat that adding too many points too quickly could cause overflow in 't'.

896371[/snapback]

I didn't realize how this would work at first, but now that I understand, it's pretty nifty! It will give a cool effect of counting up your score by tens over several frames instead of adding to it all at once. Maybe a little sound while the score is adding will make the effect even better.

[supercat]

I didn't realize how this would work at first, but now that I understand, it's pretty nifty!  It will give a cool effect of counting up your score by tens over several frames instead of adding to it all at once.  Maybe a little sound while the score is adding will make the effect even better.

896644[/snapback]

 

I suspect that the reason a lot of games have scores that count up quickly is to avoid having to do any 'real' binary to BCD conversion. This approach can be used very nicely whether adding by ones, tens, or some other increment (multiple variables may be used if counting will be by various different increments). It can also be useful for implementing score multipliers (if scores will be multiplied by 1x-9x, simply add the unmultiplied score to 't', and then each time 't' is decremented add the multiplier to the score).

[Jess Ragan]

Oh, that's an interesting idea. It would add activity to the screen, which is sorely lacking at the moment. Let me give this a whirl and see what happens.

 

JR

[Jess Ragan]

This works beautifully, but there's an odd quirk I encountered whenever I use frame counters. If you're counting down with a frame counter, be sure it ends at one, NOT zero, or it will go on and on forever. For instance, using this:

 

if s > 0 then score = score + 10 : s = s - 1

 

...will result in a score that continually adds for the rest of the game. However, using this:

 

if s > 1 then score = score + 10 : s = s - 1

 

...has the intended effect of adding to your score only until the s variable is depleted.

 

One new problem I've encountered is that you start out with a score of 10, which I'm currently trying to fix. Still, this is a lot better than dealing with goofy corrupted scores.

 

JR

 

EDIT: Got it. You just make the score 999990 at the start of the game. No fuss, no muss!

Edited July 23, 2005 by Jess Ragan

[supercat]

This works beautifully, but there's an odd quirk I encountered whenever I use frame counters.  If you're counting down with a frame counter, be sure it ends at one, NOT zero, or it will go on and on forever.  For instance, using this:

 

if s > 0 then score = score + 10 : s = s - 1

 

...will result in a score that continually adds for the rest of the game.

 

If it does, then bB is broken. If score is 1, it should get set equal to zero. Once it's zero, it shouldn't get decremented anymore. Only way I can see that happening would be if bB is messing up the comparison and treating ">" like ">=" or something.

[+batari]

This works beautifully, but there's an odd quirk I encountered whenever I use frame counters.  If you're counting down with a frame counter, be sure it ends at one, NOT zero, or it will go on and on forever.  For instance, using this:

 

if s > 0 then score = score + 10 : s = s - 1

 

...will result in a score that continually adds for the rest of the game.

 

If it does, then bB is broken. If score is 1, it should get set equal to zero. Once it's zero, it shouldn't get decremented anymore. Only way I can see that happening would be if bB is messing up the comparison and treating ">" like ">=" or something.

896788[/snapback]

There was a previous report of > actually behaving like >=, and it seems that this reinforces that claim. I'd call this a confirmed bug. This has been added to the todo list. While I'm at it, I'll also support all comparisons (>,<,<= and >=)

 

This sort of thing makes me realize that it is not practical to have 100% reverse compatibility - as I'm sure people would rather have the language function correctly.

[supercat]

This sort of thing makes me realize that it is not practical to have 100% reverse compatibility - as I'm sure people would rather have the language function correctly.

896797[/snapback]

 

In doing comparisons, it would be good to be willing to 'swap' the operands if need be to improve code. For example:

; if a>=b goto foo
   lda a
   cmp b
   bcs foo
; if a<b goto foo
   lda a
   cmp b
   bcc foo
; if a<=b goto foo
   lda b
   cmp b
   bcs foo
; if a>b goto foo
   lda b
   cmp a
   bcc foo

 

Oddly, I've seen a number of C compilers for various micros which, rather than swapping arguments, will use two branch instructions even when swapping arguments would cost nothing. Not quite sure why.

[+batari]

In doing comparisons, it would be good to be willing to 'swap' the operands if need be to improve code.  For example:

; if a>=b goto foo
   lda a
   cmp b
   bcs foo
; if a<b goto foo
   lda a
   cmp b
   bcc foo
; if a<=b goto foo
   lda b
   cmp b
   bcs foo
; if a>b goto foo
   lda b
   cmp a
   bcc foo

896848[/snapback]

Yeah, I suggested swapping operands as a workaround in the helpfile to get by the lack of <= or >= comparisons, not realizing that > was actually >=. But of course this workaround won't be needed anymore once I fix the compiler.

 

But thanks for posting this, I'll go ahead and use the logic here so I don't need to think about what the compiler should spit out.