Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

Ryan Witmer

+AtariAge Subscriber
 View Profile  See their activity

  • Posts

    910

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Blog Entries posted by Ryan Witmer

  1. Ryan Witmer
    Haven't posted here in quite some time, because the stuff I've been working on has just been such a pain.

    The most difficult part of this project so far has been the collision code, and I totally expected that to be the case. I've made three attempts at coming up with a system for this, and they all reached a state where I thought they worked, but testing revealed serious flaws.

    I decided I needed to solve this once and for all, and came up with yet another system. There are two problems involved with collision: detecting that a collision has occurred, and properly responding to that collision. My new model properly solved the first problem, but totally fell flat on issue number two.

    Then, I found this formula on Wikipedia.

    Not the first one, with the trig functions, but the second one, expressed entirely in terms of vectors. This was the magic I had been looking for.

    Over the past week or so I've been implementing this formula. There were some bumps along the way, and quite a few mistaken assumptions, but I've finally got it working. I believe my collision code is complete.

    Is it perfect? No, it isn't. There are rounding errors and various other inaccuracies that are basically impossible to avoid on the 6502. Doing this kind of math on this chip was really hard, and I'm sure there are better ways to do it than what I did.

    But hey, it works! Or at least I think it does. I still need to do some hardcore testing to verify, but what I've done so far looks promising.

    Right now, I'm busy trying to flesh out the sound effects. Once I'm happy with that, I plan to make an alpha release. This release will include everything except CPU play, which is my final hurdle. I have to admit that I have no clue how to even approach this, but once I dig into the issue I'm sure I'll come up with something.
  2. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    Well, after a lot of work I may have fixed all the collision bugs.

    I've certainly fixed the worst of them, and my testing so far looks pretty good. The new shooting system works extremely well and I'm having a lot of fun just doing the testing.

    I've also gone ahead and added a few sound effects. Nothing serious, placeholders really, but they really make things more enjoyable. I have some tones that play when you select your shot mode, and an "ice roar" sound that I got by throwing values into the POKEY noise generator until I got something I liked. I also have a collision tone, but that doesn't seem to be working for some reason. Oh well.

    It always amazes me how much a little bit of sound can add to a game. It's sort of magical when a project that's been silent for over a year starts making beeps and boops.

    I feel comfortable now releasing a demo showcasing the new shooting system. There are some known bugs here, I've confirmed that the scoring algorithm isn't quite right, but it's pretty close. I also still don't have sweeping, despite what the text at the top of the screen says. The free-guard zone rule is also not present yet. These things are all next on my to-do list.

    So, here's the new demo. As always, the complete assembly source is included for anyone that's interested in it. Once I finally have sweeping, free-guard zone, and the scoring bugs fixed, I'll probably release a new one.


  3. Ryan Witmer
    Made little more progress, as evidenced by this screen shot:





    I now have end transitions fully implemented, apart from actually checking for the end of the game. On the scoreboard you can see a few new things.

    First, there are a couple of team indicators on the left side. The colors are subject to change, and may even end up customizable.

    Second, there is now a hammer display in the scoreboard. It follows all the correct rules, which is of course nice.

    At this point, it is now possible throw a full game's worth of rocks. Sweeping is still not present, and the ice physics are still completely wrong.

    The physics are my next big project. I'm totally scrapping the makeshift system I came up with and writing something totally new. The original system was based on tracking the number of frames required before a rock would move one pixel. This seemed OK on the surface, but I went into to testing it in detail, it really didn't work right.

    My new scheme is a little more based on actual science. I've been doing some reading on the physics of friction and I have a surprisingly simple system worked out that just might do what I want. Still need to code it up, though...

    This new system also allows the possibility of player selectable ice roughness. Intellivision Bowling does this with the lane slickness, and I wanted a similar option here. Now I think I can do it.

    My current aim to have the new physics system in place, along with improved rock collisions and a sweeping implementation before the Portland Retro Gaming Expo. I've been going to this show every year for maybe the last eight years or so. I would love to have a playable demo to bring to the show with me.
  4. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    I'm releasing what I call a "shooting demo" to get some feedback.

    This build allows you to shoot all 16 rocks in a single end of curling. The physics are in a first draft state, they basically work but still need a lot of tweaking.

    Shooting is performed in three steps:

    First, you set the aim. In the following screenshot, the aim is the arrow on the hogline. Use the joystick to move this up and down, then press the lower trigger to lock in your aim.





    Next, you set the weight of the shot. This is represented by the red gauge in the above screenshot. Moving the joystick left or right will adjust this value. When you've made your choice, once again press the lower trigger.

    At this point, the rock will begin traveling forward. Now you need to set the curl on the shot, and you need to do it before the rock reaches the line, or else you will lose the shot to a foul!

    In this second screenshot, the ugly thing to the right of the line is the curl gauge. Adjust this by moving the joystick up or down, and then press the trigger a third time to release your shot into the world.




    If you haven't curled before, some explanation of the physics may be helpful. A curling rock that is thrown too hard generally won't curl, the forward momentum of the shot overcomes any friction generated by the rock's spin. Also, a rock that is spun too fast won't curl. Counter to what you might expect, the best arcs come from throwing the rock with fairly light weight and a slow curl.

    Note that this game requires the analog nature of the stock 5200 joysticks. If you have a digital joystick setup, it will not work with this game.

    BUGS, ISSUES, AND GENERALLY INCOMPLETE STUFF:

    - You can throw all 16 rocks in the end, but there is no scoring or advancement to the next end in place yet. The game will set up a 17th rock, and will crash if you attempt to throw it.

    - If you aim hard up or hard down and throw the rock off of the sheet, the game will hang until you complete the shot by setting the curl. I plan to make a bunch of changes to the aim system to prevent this situation from even being possible.

    - There is currently no collision detection. If a rock hits a previously thrown rock it will just plow through and erase it.

    - Sweeping is not yet implemented. Once you throw the rock, you must simply watch it go.

    - Rocks that fail to reach the far hogline are not removed. This isn't as simple as the other boundary detection cases, since there is a rule in curling that says if a rock contacts a rock beyond the hogline, it remains in play regardless of where it ends up. I can't implement this rule until I have collision detection.

    - Those two blue lines behind the rock are a placeholder image for a curling dude. They track the rock correctly as it's thrown, I just need to come up with some real graphics.

    - I must emphasize again that the current rock physics are a first draft. They will improve significantly after more testing on my end.

    DOWNLOAD AND NOTES:

    Download link here -> rs_curling.zip

    The download includes the assembled 32KB ROM, and the complete assembly source to date. I don't know how useful this source is at this point, since the project is still very early and much of it is subject to change. People seemed enthusiastic about porting Ratcatcher to the Atari 8-bit line, and if anyone wants to do the same with this, they might be interested in playing with this code. Just don't count on any of it staying the way it is.

    Have fun!
  5. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    Well, look at this:





    I've got the rocks slowing to a stop now, and the logic correctly proceeds to the next shot. Here you can see a yellow rock that was already thrown, with a red one coming up behind it.

    Of course, the yellow shot would be removed in a real game since it didn't reach the far hogline, but I don't have that working yet.

    The next item on my checklist is to get the curl working. This refers to the spin you put on the rock, which causes it to "curl" in an arc. This allows curlers to place shots behind other rocks, and is a key element of the sport. This is something that really needs to feel right for this game to work.

    After curl is in place, I want to get boundary detection working. Currently, if a rock leaves the sheet it just goes cruising through memory until it hit something vital and crashes the program. Boundary checking also includes removing rocks that don't reach the hogline, and enforcing a foul if the shooter hasn't released the rock before it reaches the near hogline.

    When these elements are in place, it will be possible to throw a complete end of 16 rocks. Of course, there will be no collision detection at that point, and that's probably going to be the toughest part of this whole project.
  6. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    Well, I managed to put the handles on the rocks.





    Those two pixels were really hard to pull off, and I'm still not entirely satisfied with the routine I wrote to do it. This is now the third version of the rock drawing subroutine, and hopefully it's the last one.

    It now handles both player colors as well as eight possible handle directions.

    I think it's time to actually get the program to do something interactive. That means I need to start putting together the lower sheet display and figuring out how I'm going to represent the rocks in memory.
  7. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    After completing my first 5200 project, Ratcatcher, I've jumped right into another project.

    I grew up in the Buffalo, NY area and spent a lot of time watching Canadian television. Therefore, I grew up very familiar with the grand sport of curling. My wife and I played for a few years in a local curling club here in Seattle, so while I'm no pro, I do know quite a lot about the game.

    Over my many years as a hobbyist game programmer I've noticed that sports games seem to be quite rare outside of major studios. I've wanted to do a sports game for quite some time, but I wanted to do something a little off the beaten path.

    My first consideration was actually cricket. I went through a period of obsession with the game, and I still love watching it. Cricket games are basically unheard of in the United States, and an Atari 5200 cricket game would be a lot of fun to play. Unfortunately, I've never played cricket, I've only watched and read about it, so I didn't trust myself to do it right.

    Curling was option number two. I've curled before, I know how it works, I know the rules quite well. This is a sport I can do.

    But how to design it? Curling offers a few technical challenges on the 5200. First off, there could be as many as 16 rocks in play, plus all the rings, lines, and other markings. How in the world do I display all this stuff?

    I believe I can do all of the rocks as playfield objects and create the rings and markings with players and missiles. I've got a rough plan for this, but I still need to workout the details. Before that, I need a screen layout.

    My inspiration for the layout was Intellivision Bowling. A score is display in the middle, a "status display" of sorts on the top, and the delivery is on the bottom. I think this can work pretty well.

    So far, I've got the basic screen mocked up, but haven't placed any objects. Right now, it looks like this:





    You can see the nice score sheet in the middle, and the two ice displays. The next thing to get in place are the rings.

    I have a public Subversion repository at svn://averagesoftware-uniserver.no-ip.org/svn/rs_curling

    The source can be assembled with DASM, and anyone should feel free to follow the project.
  8. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    I've made some great progress recently, and I reckon it's time for a new demo.

    I've started working on the game configuration options, which at the moment means game length selection and multiplayer support. Here's the simple menu I put together for this:





    Here you can see the plethora of multiplayer options in the game. The CPU options are currently X-ed out, since I haven't done up the CPU play yet.

    In addition to the game length, the game also now detects the end of the game and also supports tie-breaker ends. When the game ends, right now it just hangs, but that's OK.

    I've also added left-handed shooters! Eventually, your team will be fully configurable but for now I've just made the third shooter on each team left handed. Here's a lefty in action:




    Also, sweeping is now fully functional. You sweep by wiggling the joystick up and down, using true Atari 5200 analog power.

    There are still some collision bugs and possibly some scoring bugs. I also need to tweak some of the ice physics a little, but at this point the game is fully playable. Here's a download, the complete assembly source is included, as always.
  9. Ryan Witmer

    Magical Fairy Force

    By Ryan Witmer,

    Been a while since I posted here. I've been suffering a bit of a creative block lately, but I've been forcing myself to keep moving forward on this project.

    I've got some really cool things going on now and some of the gameplay details are starting to become clear. Here's a current screenshot:





    A few things going on here. First, the orange diamond looking things are obstacles that move toward the player. I achieved this by getting vertical scrolling working on both playfields. Right now I'm calling these things "stars," but that's subject to change. The graphics are temporary, of course.

    I'm still not exactly sure what the stars will do, but I have the ability to spawn them at different rates and control the scrolling of each player's "star field" at different speeds.

    I've also added a health system. Those four red dots on each player's status area are health points. Collision with the wisp shots is currently implemented, and health is removed accordingly, although neither player can die at this point.

    I also have a nifty hit-invincibility blink that happens when you get hit. I may need to tweak the rate on that a little, though.

    Hopefully I can get this project moving a little quicker and have more updates and eventually a simple demo to post.
  10. Ryan Witmer

    Magical Fairy Force

    By Ryan Witmer,

    It's been slow going on this project lately. My real job's been busy and I've had the irresistible urge to play Ys VIII again.

    Despite this, I have made some progress, although a lot of it has been weeding out bugs in existing code. There are a few interesting new things in this screenshot:





    This first new bit is that the wisps now shoot at the player. You can see a few of those shots in this image, including one that's wandered to the bottom of the screen because I haven't yet clamped the shots to the playfield boundaries.

    There was a really nasty bug here that took me quite a while to fix, but I think I finally nailed it. As long as you left the wisps alone, everything went smoothly. As soon you started shooting the buggers, really weird things started happening with the wisps and their bullets. It turned out my wisp-spawning logic had some flaws in it which now have hopefully been remedied.

    Also in this image are a pair of suspicious black lines on the left side of the screen. This isn't the dreaded "2600 comb," those are markers that I stuck in to test my first attempt at vertical scrolling.

    I've been trying to figure out exactly how I'm going to have other things flying around on the screen. The player objects are all used up in the player itself, and the four missiles are used for the wisp shots and the player shots. That means I have to resort to the playfield if I'm going to have anything else on the screen.

    The problem with this is that the playfield is dreadfully slow. The solution to this is to make creative use of ANTIC's scrolling capabilities to simulate motion. This is a common trick in 5200 games, I'm pretty sure that the invaders in Space Invaders are just a static background that's being scrolled about. I learned how to do horizontal scrolling in RealSports Curling but vertical scrolling is a rather different beast.

    There's a easy way and a hard way to do it. The easy way is to simply do a memory scan reset on every line of the display list, and update the addresses as necessary. The problem with this is that it's very slow. In my case I would have to update as many as 276 bytes on a single frame to achieve this, and that's way too much time.

    Instead, I pulled off a sort of dynamic scroll which migrates a single wrap point through an in-memory display list. This pattern is used both on the top and bottom of the screen, the top scrolls up and the bottom scrolls down. Now that this is in place, I can have pretty much anything I want "raining down" on the players.

    I'm still trying to figure out what exactly will be placed on the background. In the meantime I might do some busywork like clamping those wisp shots.
  11. Ryan Witmer

    Magical Fairy Force

    By Ryan Witmer,

    Got a little bit more done on this. I now have the fairy power gauges created, and they properly fill as you blast wisps.





    The gauges are built from all four player objects, two of them comprise the black "empty" color and the other two are the fill color. I could get fancy and play with the player size registers to get away with using fewer players, but that's more complicated than it's worth. Right now, I don't think I need the players for anything else in the status bars. so I'm going to roll with it for now.

    Parts of the wisp code are terribly inefficient right now and I'll probably need to rework it at some point. I'm really starting to get worried about processor time, perhaps prematurely. I had this same problem with Ratcatcher and I made a lot of dumb programming decisions based on paranoia. I'm trying to restrain myself this time, and will deal with performance issues when they actually happen.

    A few days ago I watched a video of the amazing Space Harrier port for the XL. I had seen it before, but I wanted to watch it again to get a sense of how much on-screen mayhem was possible on this hardware. Space Harrier is probably my favorite game ever and I'm still blown away by the quality of that port. It makes me more confident that I can make this game do what I want, although I'm certainly not that great of an ANTIC wizard.

    It also helps to listen to the Twinkle Star Sprites soundtrack while working on this. If this game can be even half as cool it will be an achievement.

    The next thing I'd like to do is to get the wisps shooting at the player. I don't think this will be too difficult, but again, efficiency is key here, since I'm dealing with a lot of software sprites.
  12. Ryan Witmer

    Magical Fairy Force

    By Ryan Witmer,

    Back with another Magical Fairy Force update.

    I've gotten some new things in place, and some of the gameplay elements are starting to formalize in my mind. The first thing I got working was shooting. Each player can now fire, I used a pair of missiles for each player, so the projectile is four pixels wide. Looks great so far.

    I also started to add the first of the gameplay elements, I call them wisps.





    Those little white things near the center of the screen are wisps. They span randomly, but identically for each player, although inverted along the X axis.

    WIsps will shoot at you (they don't yet) and destroying them is very important, because it adds to your FAIRY POWER.

    Each player will have a gauge for their fairy power. When you have enough, you press the top trigger to expend some of it in an attack against the other player. These attacks will be character specific, and still need to be designed.

    If your fairy power gauge is full, pressing the button will perform some of sort super attack. This attack is also character specific, and I still need to design these.

    So the general flow of the game is to kill wisps to build your fairy power, then unleash it on your opponent until one of you loses.

    One of the key elements of Super Puzzle Fighter II Turbo and Twinkle Star Sprites is the idea that attacks against your opponent also serve as ammunition to be used against you. This is something I really want to apply to this game as well, but I'm still trying to figure out exactly how that will happen.

    I've also spent a lot of time lately playing Centipede and Millipede trying to get a feel for how the trak-ball should behave. One thing that has become clear to me is that my current trak-ball code sucks. It needs to be way more sensitive than it currently is, so I'll need to spend some time in front of the TV tweaking it.

    I've also finalized the character roster. I have eight characters planned, and I'm really hoping I have enough ROM space to cram them all in there.
  13. Ryan Witmer

    Magical Fairy Force

    By Ryan Witmer,

    So, here's the first screenshot of my new 5200 project, Magical Fairy Force.





    Not a whole lot to see here, but there's some important stuff.

    First, we have one yet to be revealed character. She'll get her proper coming out party when the game is further along, but for now you get this teaser image.

    Note that the character graphics are done by me at this point, and I'm no artist. I plan to eventually hook up with an artist that I've worked with before to get some much better sprite work done.

    The two players are made up of all four player objects to give them lots of color. One of the players is not visible in this screenshot, and that's the one I'm using for the cute fairy wings. The wings are drawn every other frame, which provides a really nice transparency effect. This screenshot happened to catch one of the frames without the wings.

    Something else you can't see is that I have successfully implemented trak-ball support. I still need to do a lot of tweaking of the values, but the work of detecting the presence of the trak-ball and interpreting its values has been completed. The game supports a trak-ball for each player, so if you own two of those bad boys you're in for a treat.

    The next thing I want to get working is shooting. This part is only going to be as complicated as I make it, so I need to experiment with a few things.
  14. Ryan Witmer

    Magical Fairy Force

    By Ryan Witmer,

    Now that RealSports Curling is "in the can" and headed for a PRGE 2018 cartridge release, it's time to move on to a new project.

    I've been thinking about this one for a long time, and I promised myself (and my wife!) I wouldn't start working on it until I finished RealSports Curling. First a little background:

    There's this wonderful Neo Geo game called Twinkle Star Sprites.




    Don't let the appearance fool you. Twinkle Star Sprites is a hardcore competitive shooter with tons of charm. You select from one of several characters and fight against the others by playing a vertical shooter game. It's as if Super Puzzle FIghter II Turbo had a baby with a bullet-hell shooter.

    The game got a fairly obscure PlayStation 2 sequel. The sequel has a very different look and feel to it, but retains the same core gameplay. I've messed around with it a little bit, but I think the NeoGeo original is still the better game.



    Now, I'm a huge Neo Geo fan, mostly for the fighting games, but also for quirky stuff like Twinkle Star Sprites. A port of the game to the 5200 would be pretty much impossible, even the mighty Neo Geo has trouble coping with the intensity of the game.

    Instead, I'm working on a game very much inspired by the legend that is Twinkle Star Sprites. I'm still ironing out the details, but much of the game is figured out, at least conceptually.

    The title, as indicated by the name of this post, is Magical Fairy Force. Like Twinkle Star Sprites it will be a competitive shooter that I hope will have some pretty intense two-player battles. The current plan is for something very much like Centipede, with one player on the bottom of the screen and the other at the top. If you've played Demons to Diamonds on the 2600, you'll get the picture.

    In fact, conceptually this idea was born as a four-player 5200 version of Demons to Diamonds. I wanted to do something a little different though, and the detail I have planned for the game won't allow the four-player idea.

    One of the interesting things about Twinkle Star Sprites is that you don't shoot at your opponent directly. Instead you blow up various enemies in ways that create attacks that go after your opponent. Each character has their own set of attacks, as well as differences in movement speed and shot power.

    I plan to recreate much of this style in my game, although the specifics will be drastically different. I'm still working out the gameplay, so I don't have much to report on this yet.

    I've already reached the first milestone however, and that's trakball support. Tonight I got trakball detection working, and I plan to support dual-trakballs.

    My hope is to get eight characters into the game. I have six characters already designed, and vague shadowy notions of what the other two will be. All of this is contingent on ROM space, so I may have to make some cuts to the roster.

    That's all I've got for now. I'm very excited for this project and can't wait until I have something decent to show.
  15. Ryan Witmer
    So I have some nifty non-gameplay related things to show off.

    The first is my fantastic title screen:





    I made the logo by firing up the GIMP, finding the fanciest looking font I could, and then just typing out the word "Curling." I then scaled it down to Atari 5200 resolution.

    I painstakingly converted the first two letters into binary, pixel by pixel, before realizing there was a better way. It turns out that GIMP can output images as C header files, so I started dumping the individual letters this way and wrote a quick and dirty C program to output the data in the assembly format I was using. Great!

    There's also a snazzy animation connected to the title screen, but I'll save that for my next ROM release.

    I also have this plain looking, but very important screenshot:




    Like Ratcatcher before it, RealSports Curling is fully open-source, under the GNU GPL3 license. This means that the source can never be hidden, and will be available to anyone who wants it for eternity, give or take a few years.

    This is something that's very important to me as a developer. I want my code out there for people to use, and if someone manages to learn how to write 5200 games from my code, I think that would be the best feeling in the world. I'm not claiming that my code is great or anything, but it's certainly better than Ratcatcher was and I think it's helpful to have complete games out there for aspiring programmers to look at.
  16. Ryan Witmer
    Well, I guess it's time for the big reveal.

    When I started this project, there was one killer feature that I just knew I had to do. It's taken a long time, but I've finally reached the point where it can be implemented.

    From the beginning, I wanted to have customizable shooters. The details of the customizations have changed over the course of development, but one thing never changed because it's so important it couldn't be dropped.

    This is the shooter customization screen:





    Behold, we have Norwegian curling pants.

    If you don't know about Norwegian curling pants, a quick web search will bring you up to speed.

    Here are the pants in action on the improved shooter sprites:




    Of course, with the 5200's relatively low resolution, this checkered pattern is really all I can do. Still, I think it looks great and this is the signature feature that will make RealSports Curling the best curling game on the 5200.
  17. Ryan Witmer
    In the last installment, I went into some detail on the scoring algorithm I had worked out. It turned out that there were a few bugs in it, but I think I have everything ironed out now.

    I've gone a little beyond that, and I now have the score for the end popping up on the scoreboard. I've also made the scoring rocks blink, but of course you can't see that in a screenshot.





    In this test end, the yellow team has scored two points.

    What's really great is that I'm not too far from having a functioning, albeit terrible, curling game. I need to code up the transition to the next end, and I basically have something that can be played. This doesn't mean the game is close to being done, however.

    What's also exciting is that all of this is working and I've only used a little over 4KB of ROM space. That leaves about 28KB for all the cool stuff I have planned.

    Here's a working checklist of all the crap I need to get done:
    End transitions: This includes checking for the end of the game, as well as managing "the hammer." In curling, the hammer refers to the last shot of the end. If the team with the hammer scores, the hammer passes to the other team. Managing which team controls the last shot is a huge part of the strategy of curling. Sweeping: This isn't implemented at all. I have some ideas for this, but nothing solid yet. It depends quite a bit on... Ice physics: The current ice physics are passable for a first attempt, but need a lot of adjustment and testing. Proper collisions: Rock collisions currently occur, but the physics are completely stupid. Free guard zone: Rocks that come to rest in front of the house are referred to as guards. They have important tactical value. There are some curling rules relating to when it's legal to knock out the other team's guards. Shooter graphics: I need to come up with the graphics for the shooter. I plan to have fully customizable shooters. There will be a few clothing and hair options, color choices, male/female, left/right handed, and another special surprise. Scoreboard embellishments: I need to put some kind of team indication on the scoreboard, as well as a hammer display. Control options for teams: Right now, everything runs off of controller 1. I plan to have a bevy of options here, including 4 player games (got to use those P3 and P4 ports!). CPU play: This ties in to the previous thing. I really want to have a CPU player, preferably with different difficulty levels. A four-players against the CPU game would be cool. Sound: There isn't any!

    All of these things seem reasonable to me, and this serves as a pretty good release checklist.
  18. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    After much difficulty, I've successfully implemented the free guard zone rule.

    This rule stipulates that each team is prohibited from removing the other team's first two rocks, provided those rocks meet the definition of a guard. For this rule, that definition is that the rock is outside of the house, and forward of the button. After each team has thrown two rocks, this restriction no longer applies and rocks can be removed normally.

    If the free guard zone is violated, the rocks are returned to their pre-shot state and the shooting team loses their shot.

    The purpose of this rule is to allow the team that shoots first to set up some kind of a defense. Without it, the team that shoots last could just keep knocking out the other team's rock and even a one point lead would be unassailable.

    After implementing this rule, the game has now reached a point that I like to call gameplay complete. This means that every feature required to play the game is now in place. Those pieces aren't necessarily all final, there are still bugs to fix and adjustments to make, but the game is now completely playable.

    My attention now turns to the aforementioned bug fixes and adjustments, and awesome features. So far, I've only used about 8KB of the 32KB ROM, so I have tons of space to use for cool stuff.

    The list of things I want to do include:
    Left-handed shooters: Some of the groundwork has already been done for this, but I need to finish the implementation. Team customization: I want to allow the player to customize certain aspects of the four members of their team. This is mostly color selections, but also handedness and a male/female option. I plan to have a default team that you can pick if you don't want to spend time messing with this. Variable game lengths: The game length will be anywhere from one to ten ends. CPU play: This is the big one, and it will probably be quite difficult, but I really want to have this in there. Multiplayer support: Right now, everything runs off of the player 1 stick. I plan to support all four joysticks, including a cool mode where two of the non-shooting players have to work together to sweep the rock, just like in real curling!

    I can't wait to get started on this stuff, and I would love to have this game done before the summer.



  19. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    At long last, we have sweeping!

    Sweeping presented a few challenges. The first was trying to figure out some way to visually represent that sweeping was taking place. I have a serious shortage on objects to use at this point, so I had to get a little creative.

    In this screenshot, you can see the new sweeping gauge in the bottom-left section of the ice.





    Well, actually you can see the letters "Sw" down there. The actual gauge is empty right now because nobody is sweeping. Catching that in action for a screenshot is really hard, so I didn't bother trying, but trust me, it's there!

    The rings are constructed from the four player objects, and I noticed that players 0 and 3, the two outer sections of the rings, had more empty space at the bottom than the other two did. I was able to move those two players to create the sweeping display.

    Sweeping is performed by wiggling the joystick up and down. You could cheat the hell out of this with a digital controller, I imagine, since the code uses the distance the stick moves to calculate the sweeping effect. This doesn't particularly bother me, I'm fine coding for the stock joysticks and if people want to use a digital stick for super-sweeping, so be it. Such a stick wouldn't be able to shoot properly, so you'd have to just pop it in when it came time to sweep.

    The sweeping effect is pretty good right now too, but I still need to tweak it a bit. Sweeping causes the ice in front of the rock to melt slightly, reducing friction. The causes the rock to travel farther and to curl less. Right now, I think the distance extension might be too great, but the curl reduction feels really good. Time and testing will settle these values eventually.

    There are also some implementation bugs I need to correct. Right now, sweeping impacts all of the rocks in motion, when it should only affect the rock that was thrown. This is a simple oversight and there are some others bugs in this area that I can fix at the same time.

    The only remaining gameplay element that needs to be done is the free-guard zone rule. I have a vague idea of how I want to do this, but I need to actually sit down and work it out. Once that's in place, it's time to start working on features and bug fixes.
  20. Ryan Witmer
    Haven't posted here in quite a while, since I haven't anything worthwhile to show.

    My real job has been very busy lately, and I've also been devoting a lot of time to a PC game project so RealSports Curling was back-burnered for a bit. I have some interesting things put together now that should help move development along.

    The big thing I got going was collision detection on the rocks. This isn't perfect yet, but it's there and it seems to work. It's very simplistic at this point, right now a collision just halts the moving rock and transfers all of its momentum to the rock it strikes. The physics will come later, for now just having the logic functioning is good enough.

    With collision in place, I was able to implement the front hogline boundary. Rocks that don't pass the hogline are now removed from play, unless they strike a rock beyond the line. This is a fairly obscure curling rule that I wanted to make sure I got right, but I needed collision detection before I could implement it.

    The next thing I want to pull off the scoring algorithm. This is a bit of a pain to test, because I need to be able to set up a variety of rock configurations to make sure the right thing happens. To this end, I've developed a neat little system that lets me pre-place any number of rocks so that I can now test all kinds of things, not just scoring.





    Here you can see the rock location tables that I've spun up, which allow me to create setups like the one shown in the emulator window. Also, MAME is quietly compiling in the background.

    The rock display at the bottom gets a little screwed up when I do this, but that's OK since I'm just debugging.

    This capability should speed my work along, and hopefully I'll have a functional scoring algorithm put together soon.
  21. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    I've now finished the last of the major changes to the shooting system, and the curl application phase is now much simpler and more effective.





    The original curl phase of the shooting process involved an ugly gauge that you used to apply curl in various degrees. This just didn't work well at all, so now it's very simple: you curl up, you curl down, or you don't curl at all.

    In the screenshot you can see the little red arrow indicating the selected curl direction. Simple, fast, and to the point. It works great.

    Now that shooting has been greatly improved, I need to turn my attention to the numerous collision bugs. Some of these have already been fixed, but I have a lot more research and testing to do before I can nail them all. When I'm satisfied with that, I plan to release a shiny new demo.

    I also took the time to do something that I failed to do with Ratcatcher, and that's watermark the ROM with some kind of version identification. I now have a string embedded 256 bytes from the end of the ROM that can be dumped to check the build. For the moment, it just says "Development build" but this will changed to reflect whatever release I ship.
  22. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    So, I've gone and completed the second phase of my shooting system overhaul.

    This time I've made some changes to the aiming system. These changes are entirely cosmetic, but make placing your shots much easier.





    In this shot, you can see that there is now a little scale in front of the aim arrow to give you some points of reference apart from the center line. I've also added a distant aiming line on the top display. The arrow on this line shows you approximately where you are aiming far down the sheet.

    This fairly simple change is pretty awesome, especially in combination with the new weight system I discussed in my last entry.

    The last phase to fix is the curl application, and this aspect of the game is going to become significantly simpler.
  23. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    After a somewhat successful "Portland build" I've been making some ambitious changes to the shooting system.

    Playing with the demo revealed some problems with the shooting and I'm overhauling all three phases of the shot process.

    The first thing I wanted to tackle was the shot weight. Until now, the weight was set by a single gauge, so every type of shot, from guards to heavy takeouts, was relying on this single mechanism. Experience has convinced me that this is not the way to go.

    What I've done is added a set of three shot modes, and you select the mode based on the type of shot you want to throw. This is much closer to the actual mindset that you have before delivering a rock when curling for real, and it seems to work fairly well.

    The modes constrain the weight of the shot to a certain range, so you can still screw up and over/under throw. Plus, there's a little bit of overlap between the modes. Proper sweeping will also be essential, once I get around to actually implementing that.





    Here you can see the shooter in guard mode. The three modes are guard, draw, and takeout. For those unfamiliar with curling lingo, this is what these mean:

    A guard is a shot that's typically placed in front of the house, either to defend an existing rock or to cut off certain areas of play.

    A draw is a shot intended to come to rest in the house, typically with the intent to score.

    A takeout is a heavy shot meant to strike and remove a rock from play. Takeouts are usually thrown so hard that they won't be remaining in play unless they hit another rock and deflect properly.

    The shot modes are selected with the 1-3 keys on the controller keypad. 1 selects guard mode, 2 selects a draw, 3 selects a takeout. I've also added the ability to press the 0 key to cancel weight mode and go back to reset your aim.

    So far, I'm loving this new system, and it may even be the excuse I need to have controller overlays produced. Wouldn't that be sweet?

    Next I need to make some changes to the two remaining shot phases, aim and curl. The aim changes I have in mind are largely cosmetic, but should help aiming immensely. The curl changes will drastically simplify this part of the shot process, hopefully for the better, since it's the weakest part right now.
  24. Ryan Witmer

    RealSports Curling

    By Ryan Witmer,

    Just realized that I've been working on this project for over a year now. Kind of scary, but then again, Ratcatcher took at least three years. Of course, Ratcatcher was my first 5200 game so there was a lot to learn.

    I've completed the the new physics system, as least as far as basic rock movement is concerned, The new system is much more physically accurate and just looks a whole lot better. The old approach had 16 different rock speeds (I think), this new one has 100.

    I've also made a small change to the aiming system, one I've been thinking about for a long time. Originally, you aimed the rock along the front hogline. The problem with this was that there were only about 5 or 6 aim points that were viable, the rest would just throw the rock off the sheet.

    The new aiming point is much further out, as displayed in this screenshot:





    This allows a much greater range of aim points, and also fixes some issues with "extreme" aiming that I really didn't want to fix otherwise, so everybody wins!

    PLANS FOR PORTLAND

    I will be (as always) attending the Portland Retro Gaming Expo for a few hours on Saturday. I really want to have a minimally playable demo of this game that I can bring to the show. What do I still need to do? Here's a handy checklist:
    Fix the curl. The curl code is still married to the old physics system and needs to be totally redone. Get collisions working right. There was never a truly functioning collision system. The meager one than was there needs to be modified for the new physics code, and needs to actually do something realistic. Sweeping. This is kind of an "extra credit" thing, but I have some ideas on how to do sweeping and the new physics system will help a lot with that.

    So, that's it. Two or three things, but they're not small things. I reckon I'll being the game to Portland even if I don't hit these targets, but I think these goals are totally realistic.

  25. Ryan Witmer
    Well, look at that. What is it, you ask?

    Just a memory dump of location $600. $600 is the scratch area that I'm using for the scoring algorithm. If you don't know, curling scoring works as follows:

    The team with the closest rock to the center of the rings scores one point, plus one additional point for each of their rocks that is closer to the center than the other team's closest rock. Rocks that are outside of the rings don't count, so it's possible that neither team will score.

    What you see here is a test end in which the yellow team has scored two points. The first two bytes are ID numbers for the rocks that scored, 0 and 2. The FF is the list terminator.

    The scoring algorithm is rather simple. First, I order the rocks by distance using a sort of insertion sort. This list is also constructed at $600, with a three byte entry for each rock. The first two bytes are the distance from the button (the button is the center of the rings), the third byte is the ID number for the rock in that slot. You can see the remnants of that list beyond the terminating FF. This particular test scenario only had three rocks.

    I can then determine which team scored by looking at the ID number of the first rock in the list. If it's FF, no rocks were eligible for scoring. Otherwise, I can determine the owner by checking to see if the number is even or odd.

    I continue down the list checking the ID numbers until either FF comes up, or I get a rock whose even/oddness doesn't match the first rock. Along the way, I've been pushing the IDs of the scoring rocks onto the stack.

    Once I have all the scoring rocks, I just pop them off the stack while copying them into successive addresses starting at $600. Now that I have the rock IDs, I can do something to visually indicate which rocks scored, I'll probably just have them blink.

    I'm immensely proud that I actually got this working. It's not perfect yet, there are still some edge cases I need to account for and some tweaking of the distance calculations, but the overall logic is sound. I also need to more rigorously eliminate rocks that fall outside the rings. Right now I'm just doing a bright-line test against the front of the rings, but I need something more detailed to hit the corner areas.

    The "physically correct" answer is to simply have a cutoff distance from the button. The problem with this is that it might not work correctly when placed up against the relatively low resolution of the 5200 playfield. Or maybe it will just work! I need to try it to find out.

    Either way, just having something that works this poorly is a major milestone in this project.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...