duffys 060000RF24 3,359 Views
Learning Java Programming has never been this fun and this easy, using IBM tooling for mobile and web development, with an Retro Interactive Community Social Racing Game. The game is an easy-to-play racing battle where you and your team use their development skills to design in advanced intelligence, creating the fastest vehicles, avoiding obstacles, challenging courses, and competing against simulations and/or other development teams through virtual courses and challenges to reach future levels. Each team creates their own vehicle using IBM tooling including WebSphere Application Server (WAS) Liberty Profile, WAS Developer Tools for Eclipse (the IDE), Worklight Studio for Mobile development, and Rational Team Concert to design the vehicles and the obstacles to race through the courses, enabling a range of developers -- from beginners to advanced hackers -- to participate in the fun. Follow along as this game (Code Racer) starts you on your way to building your own customized lean, mean, racing machine.
Get ready to play the game, releasing soon!
This blog post is the first of many writeups about our (Mark, Nick, and my) progress on the top down racing game.
Users will be able to customize cars by the attributes they invest in them. The current game only has a few functional attributes (acceleration, weight, turning, traction) but we plan on expanding these in later iterations. Attributes are invested in a point-weighting system. You can give any attribute any number of points to invest, but the game ends up using the final ratio, not points to determine how well your car performs for each of the attributes. Investing a 9-1-1-1 attribute spread is the same as a 90-10-10-10 spread, as the ratio of points in each category is the same. This allows for the system to remain fair regardless of the total points, while allowing fine-tuned customization if desired.
One of the early challenges in designing a top down racer is teaching the AI to follow the track. Cars aren't aware of the track, and with a variety of environments and track layouts, pattern recognition would be very difficult. We initially decided to use a checkpoint system, which involves placing a predefined list of points for each track, so the cars have a "guidepost" to follow and attempt to aim for so they remain on track. Our early design was exactly as described, a JSON list of x, y points that corresponded to points on the track that the cars were meant to follow.
It worked - partially. There was difficulty in determining when a car should advance towards targeting the next checkpoint in this list. We didn't want every car to take exactly the same route, so the cars aren't going to move directly above the checkpoint. Instead, checkpoints were considered "passed" if a car moved within a certain radius from the center. This initially seemed to be a good compromise, but it had some drawbacks. Occasionally, cars would move slightly outside of this radius. The AI would react as if it had gone off-track, and force the car to turn around, go the wrong way to reach the missed checkpoint, breaking the immersion (and causing numerous collisions). Increasing the radius of the checkpoint was not a viable solution, as it meant cars could be capable of skipping portions of the track and going off-track.
Our solution was to turn checkpoints into a line instead of a fixed point. Checkpoints went all the way across the track, much like ski gates. Cars don't aim for the center checkpoint, they just attempt to cross the line at the best intersection point [best being the intersection point that involves the least turning to still intersect the checkpoint]. These line-checkpoints are invisible to the user, but the AI uses them as guides to navigate the track.
Another early issue was the AI design - we needed to provide an event driven AI that could guide the car through the track and also react to different situations. Our initial design was a completely reaction driven AI design. Cars had an AI that listened to events, and responded to each event. Events were fired for the race start, checkpoints being reached, if the car goes off-track, if an opponent moves in proximity, obstacles, and other related situations. The AI did not have any long term memory, it did not remember what previous events have been fired and did not have any long-term strategy.
There are several problems with this design that we encountered. In a best case, cars have little difficulty navigating the track, but other cars and obstacles often pose a problem. Because the AI only responds to the last event it receives, it might end up ignoring the track to escape another car, and end up worse off if it had simply collided. Or it might get stuck off track, and not be able to recover.
The Race-AI is not a problem we have completely solved, but we are experimenting with a strategy system that allows the AI to have longer-term goals, and pick and choose which events to respond to, based on the current situation.
duffys 060000RF24 4,373 Views
duffys 060000RF24 7,573 Views
Want to use Code Rally in academia?
Thanks to Code Rally's simple design and friendly graphics it is the perfect fit for the classroom. As every download of the game comes with a Java/Java EE development environment (Eclipse, IBM WebSphere Developer Tools, IBM WebSphere Application Server Liberty Profile) it is easy to use the tools that come with Code Rally to teach Java and Java EE programming.
You are able to run your own server for your students to race on - this can be school, room or class wide and with it you will be able to identify which students are doing well and which need some help based on their race times. This also enables you to have healthy competition between students who can be competing for top place!
For a beginner's programming class students can be introduced to the game by racing an intermediate AI - this does not require any coding but introduces the students to how to race the game. Once they have raced an intermediate car they can then be moved onto coding their own basic AI.
The simplest AI only needs 3 lines of code adding to be able to navigate around the track - see how to create your first AI for information on how to create an advanced car with only a couple of lines of code. Once your students have a basic AI that can navigate around the track they can iterate over their code adding one or two lines of code that will change how the car behaves. As soon as they want to see how their changes have changed the car's behavior they can race again - races take less than a minute to run before the students can watch how their vehicle did.
Once you have your students modifying their cars to perform better you can introduce them to new tracks - each with their own challenge to overcome (be it building a car that handles corners well to a car that avoids collisions) - to find out what each track introduces see our post covering the 6 different tracks in Code Rally. You can also introduce new challenges on the tracks - by having the students racing against cars you have created you can challenge them to improve their code to be able to beat your own entry.
Racing in teams
If you have limited computers or want to encourage teamwork between your students you can have them working in teams - this can be done by having each student working on their own AI and entering it into races with a team username, or by sharing the code between students on the same or different machines. To be able to have different machines sharing the same code you will need to create a free project on the Academic JazzHub and add the Rational Team Concert plugin to the Code Rally eclipse install. This will then let you put students into teams which share the same code between machines (you will be able to see their code as well as which students made which changes as well. For more information on how to get this working please ask in our forums and someone from the development team will be able to walk you through what is needed.
Although Code Rally is designed to be accessible and easy to get started it can be used as an advanced teaching aid. Here is a list of challenges you can ask your students to beat in the game:
These challenges are currently not built into the game - you will need to manually verify if a challenge has been completed by watching the race replay. Of course these are just a list of challenges we have run at code rally challenge events - if you can think of more challenges you can set let us know!
If you would like more information on how to use Code Rally in education, or if you have any requests/suggestions then visit our forums - the development team would love to hear your thoughts and feedback.
duffys 060000RF24 5,208 Views
Code Rally is built with some key IBM Developer tools including:
duffys 060000RF24 104,346 Views
What is Code Rally?
Code Rally is a free, open source racing game where you play by programming a vehicle (either in Java or Node.js) to race around various virtual tracks for you!
Code Rally is also a sample of a microservice architecture - each vehicle is its own self-contained microservice, which connects to a monolithic application in the cloud which simulates physics and sends events to your vehicle code as it is racing around, so in playing the game you are modifying a microservice and then connecting it to other services around the world.
You can play single-player on your own computer, multiplayer on your own or your friends' computers or race against people from around the world on the Code Rally cloud servers - the choice is yours.
Whether you're an experienced software engineer or someone starting to learning programming Code Rally is a fun, exciting challenge. What are you waiting for - start downloading the game now!
Downloaded the game and ready to race? We have a few tutorials to help you get started:
AI not racing? Wondering why you keep getting stuck on the side of the track? Check our
Would you like to know more?
Visit the blog posts from our development team page covering some of the work involved in creating the game - from figuring out a good physics implementation to creating graphics for the different vehicles.
The multiplayer server for Code Rally runs on IBM WebSphere Application Server Liberty in IBM Bluemix - you can find out about the lightweight, fast WAS Liberty runtime including the awesome stuff you can do with it from WASdev.net.
We have a new release! Version 1.5 is available from our downloads page.
As part of the new 1.5 release we have added damage to races - the more your vehicle crashes, the more damage it takes. We've also refactored the Eclipse UI and have released a sample Node.js implementation so you can program your cars in Java or Node!
Powered by WebSphere Application Server Liberty | Hosted on IBM Bluemix
During our initial brainstorming sessions we acknowledged the need to spend some time exploring the physics-related aspects of the game. However, looking back, I think it's fair to say that we underestimated the complexity of the required computations. Naively thinking that our faint recollection of various formulas from old physics classes would suffice, we charged forward and planned to tackle all physics-related requirements as they arose. This resulted in quite a few learning experiences and code refactoring sessions as the overall complexity gradually rose over time. In the end we decided to integrate a robust, third party physics engine into the game. But before arriving at this final conclusion we implemented a number of our own home-brewed solutions.
In this post I will describe our original method for collision detection (such as between two cars). Although we are now using a powerful physics engine to handle much of this work for us, the engine itself also uses this method (among others) underneath the hood. My intention is to perhaps offer some guidance to anyone wishing to implement their own game physics or to just give a quick look at some of the inner-workings of what you see in the game.
At the core of our method of collision detection is the Separating Axis Theorem (Wikipedia link). The theorem simply states that if two convex objects are not intersecting, then there exists an axis for which the projections of the two objects do not overlap. Note that if you wish to test a concave object you must first break it down to multiple convex objects and individually test each one. SAT is an efficient, generic algorithm for detecting overlap between two entities and its ability to execute relatively quickly makes it often ideal for collision detection in games.
To picture this concept of "overlapping projections", take a look at the image below. In diagram a you see two squares which are clearly not intersecting. If you were to project their respective images onto the horizontal axis as pictured, their projections would not intersect either. As soon as you have found an axis in which these projections do not overlap, you can assert that the objects do not intersect. Conversely, the two squares are clearly intersecting in diagram b. For every possible axis, the projections of the two objects will also overlap, allowing you to assert that the objects themselves are overlapping. For any two polygons, the only axes you must test against are the normals of each edge. To obtain the normal of a vector you simply swap the coordinates and negate one (ie. [5,3] becomes [-3,5]).
Unlike the previous image, objects being tested for collision won't usually be simple, un-rotated squares. You might be dealing with a complex polygon with many vertices. You may be wondering then, what the best way to programatically project these polygons onto an axis is. The answer, luckily, isn't very difficult. You would simply loop over all of a polygon's vertices, perform a dot product between the vertex and the normalized axis to be projected on, and store the minimum and maximum result. Remember that there is a difference between a vector's normal and a normalized vector! In simple pseudocode, this would look similar to the following:
We now know enough to be able to assemble a simple function for determining whether or not two objects are intersecting. But in our racing game, we needed more than simply knowing if two cars are colliding. We also wanted to prevent them from simply driving right over the top of each other. For this reason it is beneficial to calculate the Minimum Translation Vector - a vector which tells us the shortest path to push the two objects apart to keep them from intersecting. Your final collision detection code might look similar to the following pseudocode:
Don't forget that the array of axes in the above code would have to consist of both objects' axes needing testing.
This was a very simplistic overview of the algorithm we employed for collision detection in our beginning stages of development. Before using it yourself, you would likely want to spend some time making the algorithm more efficient (such as by not testing parallel axes) and adding additional functionality to handle curved features or to properly handle the case in which one object is completely engulfed by the other.
Collision detection is just one facet of our physics-related computations. Things seem to get exponentially more complex when you begin to account for resultant forces due to a collision, cancelling out a car's lateral movement due to traction, applying the appropriate amount of torque to turn a car just the right amount, etc. In future blog posts we will discuss our move to the JBox2D physics engine, how much easier this made our lives, and all the cool physics stuff we've been able to put into the game.
In order to develop your own artificial intelligence to control your vehicle, we developed an event-based system in the game engine. Throughout a race, the engine will throw out certain events at vehicles, and the AIs will call their corresponding method to respond to that event. The AI classes use an API that controls your vehicle, with access to how much you are accelerating and where you want your car to turn. In future releases, we hope to add more events, and more control over your car. For example, it would be cool to have access to special speed boosts and weapons your car may contain. Below is a simple explanation of the current Race Events and API Calls you will look at when programming your vehicle.
The following methods are in the AI interface that you will have to implement to get your car running.
You will use the following API calls to manipulate your vehicle. The list is separated into calls that will give you information, and methods you will use to control your car. More will be added to this list over time.
Code Rally features race track environments rendered in a simplistic style with cut-out images and multiple layers of color.
The image sample below showcases the different layers of colors and textures of the Sky Track environment.
How were these graphics created?
The visuals implemented in Code Rally are created using Adobe Photoshop and Illustrator. Adobe Photoshop is a pixel based software and Adobe Illustrator is a vector based software which creates smoother, flatter looking graphics. A distinctive characteristic regarding vector images is that they can be scaled up or down to any size and maintain the same quality. To incorporate vector based art into Photoshop and to maintain the flexibility in scaling, the artwork has to be converted into a smart object. The next time you take a look at the game, see if you can identify which graphics were created in Photoshop and which ones in Illustrator.
All the environment (background) graphics start off as a standard 1024x768 pixel artboard. The backgrounds are made up of a mixture of Photoshop tools and real photographs which are edited and enhanced to blend in seamlessly. Some of the photographs used are mostly of textures found in nature, for example rock, sand or grass which are then adjusted and scaled down to the appropriate size. All the environments have a fairly neutral, toned down color palette overall which enables the viewer to focus more on the vehicles, objects or specimens racing along the track. More contrast and a range of vibrant colors are added to the vehicles in the game as they are smaller elements within the environment.
Stay tuned for my next entry, where I will show you how to create one of these vehicles!
The first impression a user has of their race is the most important. It's vital that players are able to see all of the information in order to interpret the game around them. However, too much information can easily overwhelm a new player and make them lose interest. With Coderally, we've taken several steps to ensure users have the best visual experience possible when they play a race.
Three Second Pause
When a race starts, there is a three second pause before the races begins playing. This pause allows the user to see the track, their cars, and get a brief feel for the game environment without feeling like they are jumping off a virtual cliff. This pause isn't just an empty delay that might annoy users - it shows a traffic light countdown to green and keeps their focus on the center of the race.
Some of the tracks are large. They have lots of turns, and can go off-screen, especially on smaller screens or mobile devices. Coderally will pan and follow the player's car, but it's important to be aware of the rest of the track, especially if you aren't sure where the other players are. A minimap offers a visual way to show where other cars are on the race, without needing to display the entire track.
Name Tags & Lap Indicators
It's easy to lose track of which car is yours when watching a fast paced race or violent collision. Name tags that show which car is yours and which are other players provide an easy way to tell cars apart.
Lap indicators allow players to know when the last lap starts, and whether any cars have finished the race. In the upper right corner, it displays a yellow light when any car starts their final lap. It displays a red light when any car finishes the race.