Recent Posts

Pages: [1] 2 3 ... 10
Tutorials & Guides [EN] / ACL example bot programming guide
« Last post by MarvinMan on October 15, 2019, 08:56:43 pm »
The purpose of this guide is to explain the code required for a basic functioning combat bot suitable for participating in ACL. It is hoped that the ideas presented here will provide a foundation for others to use to build their first ACL entry. It is intended to take a step back from what may seem an overwhelming wall of code seen in some ACL bots and provide solutions to issues that may be obvious to experienced ACL participants but potentially present a challenege to those who have yet to experience the joys of trying to make a bot reverse out of a corner. This guide is suitable for anyone who is familiar with the basics of Rawbots. A blueprint of the bot is provided at the end of this guide.

1: Drive forwards
The first thing out bot needs to do is drive forwards until it sees a wall to avoid or an enemy to pursue. It is customary for ACL bots to use the 'X' key to enable weapons and movement. In this case the forward drive signal is a fixed value provided by a toggle. This bot is relatively slow to prevent it flipping when sudden changes are applied to the motors or navigating ramps. You may want to consider adding an integrator (or SLEW function in 0.16) to provide smoother acceleration, or code to make the bot drive faster in open spaces.

2 & 3: Don't crash into the wall
Now that our bot is moving, it is soon going to encounter a wall or ramp. The fundamental principle here is that hooks can 'see' terrain from a considerable distance, allowing bots to sense the world around them without crashing into it. Most bots use one distance sensor on each side, normally pointed roughly towards the front corners of the bot. When our bot sees a wall in its way we want it to steer away from it. Most designs will cause the bot to steer away from the side that has detected an obstacle. However, this can cause an issue when the bot is driving straight into a corner and can see a wall on both sides, usually causing the bot to either stop completely or continue driving straight into the wall. There have been various attempts to handle this, including scripted reverse, turn, continue procedures and bots that can drive in both directions. In this simple example we avoid the problem by stopping forward motion and always turning left when an obstacle is encountered. This is simply implemented by reversing the left wheel direction whenever the hooks detect that the bot is close to a wall.

Ramps complicate the wall avoidance somewhat. Again, there are various approaches to handling this. This bot uses two hooks on each side stacked on top of each other for the sake of showing how it's done, but you can also use a single pair of hooks which are angled upwards enough that they can see up ramps far enough to not trigger the collision avoidance code. Stacked hooks have less complicated placement requirements, and can easily detect ramps by checking for a difference between the top and bottom hook.

4: Identify a target
All combat bots need a camera to be able to identify a target. One major challenge that ACL bot designers face is picking out a target from scattered debris. This bot uses the camera activity output as a simple filter to only latch a target into a multiplexer when the part count exceeds 5. It is good practice to use some form of memory (like the multiplexer latch) for the targeted part so that the bot can continue to track its target even if it can't see it. You will likely want to improve the filtering for example to only target moving parts, or dynamically modify the camera box to check the proximity of the detected parts. You may also want to allow the camera to rotate and scan across the battlefield when it doesn't have a valid target.

5: Drive towards the target
Most ACL bots will benefit from proximity to the target, either for direct laser attacks or improved plasma cannon accuracy. In this example the code is rather brutally simple: If the left wheel motor is closest to the target, turn left, else turn right. The only slight complication is a check for the proximeters to have a valid output (not 65535) as the SIGN operand has no zero output. This is a part of the code that you should improve in your own bots, for example using a controller for smoother transitions or to implement target leading.

6: Precision targeting
This is where our example bot starts to deviate from the majority of existing ACL bots in terms of both philosophy and implementation. The majority of bots have turrets armed with rapid-fire plasma cannons (the implementation of such in worthy of a guide of its own) intended to saturate the target with damage at all ranges, whereas this bot has a fixed high-power cannon designed to one-hit nearly all parts. As such, every shot ideally needs to be on-target and the projectiles are faster and less affected by gravity.

To facilitate this, when the bot detects it is nearly pointing towards its target (the left and right proximity values are within +/-0.1) the camera switches from its wide scanning mode to a narrow beam looking along the barrel of the cannon.

7: Fire at the target
When the focused camera detects a part that is close to the part it is currently tracking a fire signal is sent to the cannon.

8: Only fire when fully charged
The philosophy of this bot is to detach any part it hits, for which it needs a fully charged cap. Additionally, undercharged shots are unlikely to be on-target as the projectile moves slower. To avoid this, an integrator is used as a timer which gates the fire signal to the cannon. When the cannon fires, the timer is reset and further shots are blocked until the counter finishes.

The bot as presented here weighs in at 20 parts, qualifying it for the lightweight (25 part) ACL class. However there are still mechanical improvements to be made, such as adding armour and removing unnecessary parts. Look out for the improved version in the ACL thread soon to see how this basic platform evolved into a (hopefully) competitive ACL contender.

Development Logs / New Devlog 6/4/2019
« Last post by cupid_the_conqueror on June 05, 2019, 02:41:34 am »
Hello everybody, I know its been a while since the last devlog, but I don't want to pull a Rozgo and leave you all in the dark.

I have good news, and I have bad news.  So as per tradition, I will start with the good news.

The good news is, development isn't dead. We've recently taken on a new team member, and our understanding of the rawbots source code grows every week - if ever slowly -

The bad news is, 1.6 is a long waaays off. We realized while working on the project that we really need to have a fundamental understanding of HOW the source code works going forward, and I won't put icing on the cake here - none of us really have the professional experience or education that the original development team had. In order to understand how to do fundamental improvements not just to performance, but also to game play mechanics, we have to learn how everything is hooked up and what everything does. For example, Z26 has been learning how to use the debug tools the devs left baked in to the source.

I really need to emphasize this ; Nothing is documented. Period. We may have gotten the source, and some of the older .git data, but we don't have internal notes or documentation. So we have the long and arduous  task  of creating our own.

Now for even more bad news. Some of the development team is busy with real life happenings. I know myself, I have quite alot on my plate. I recently evicted a destructive room mate, have become a property manager, and have a host of finical issues years of neglect have caused. I have books on C# net 7, Unity 2018 , Java and java script, python, Design patterns for object oriented code... ect ect.. but they will be gathering dust in my library until things settle down.

But I can promise you from the bottom of my heart, we will not go dark and give up. We will make progress over time (heck, the battle of wesnoth was worked on on/off for what.. 12 years?)

we have a lot to do , and a lot to learn. And if in the future the source code goes fully open, we will still be here doing our work.

as per pressureline - "stay calm and build rawbots"
Challenges / Re: Autonomous Combat League
« Last post by MarvinMan on April 01, 2019, 08:22:30 pm »
Interesting idea.

The fixed camera seems to have same trouble finding targets compared to turret bots, but once it gets up close it is very effective. The low profile seems to make it difficult for most other bots to hit, and the cannon placement is almost guaranteed to cause crippling chassis/internal damage.
Challenges / Re: Autonomous Combat League - Wedge
« Last post by PressureLine on March 31, 2019, 11:26:04 am »
New Lightweight competitor!


Weighing in at 25 parts, Wedge is an invertible lightweight Plasma Shooter capable of tracking and engaging both ground based and aerial opponents.

Get Wedge here.
Development Logs / Re: The Development Road map
« Last post by MarvinMan on March 30, 2019, 12:18:47 pm »
Once we have the ability to store code in re-usable blocks, it would be relatively simple to include a library of example functions that new players can use and learn from. Combined with a set of blueprints of archetypal bots, this would provide a good platform to get new players started and provide shortcuts for more general use.
Development Logs / Re: The Development Road map
« Last post by cupid_the_conqueror on March 30, 2019, 02:57:36 am »
Thank you for reminding me marvin! at some point in the far future I would like to have a talk with all the devs about Accessibility within rawbots.  I think that a system of configurable PreConFig-VP tiles would ease new  users into the game. Example:

Turret - VP: Asks for a motor labeled "rotation point" , a elbow labeled "elevation point" , a camera labeled "vision point" , and "left reference" "right reference" as inputs. It also shows an image of an example turret, and then contains a folder VP with pre-generated code for a basic turret would be auto hooked up.  Usage of these Simplified VP's would be inefficient power wise, and wouldn't be the best performing , but could greatly speed up the time it takes to "pick up and play"

another example

Car - Has Left, Right , users just hooks up the motors, pre-made WSAD car code is used.

Another option is to simply have "basic bots" that the player "unlocks" and can spawn in, giving them a plethora of useful bots they don't have to program. New users who want to just hop in, explore and adventure without learning right away will be able to do so. While the inefficiencies of doing so will encourage them to learn code over time.
Development Logs / Marvins view on the grand plan
« Last post by MarvinMan on March 29, 2019, 09:07:25 pm »
The current state of Rawbots:
The Rawbots we have today is largely stable (remarkably so for something claiming to be pre-alpha), and numerous bugfixes and quality-of-life improvements have been made by the dev team for 0.15/0.16. The bot building and programming system is pretty solid, as evidenced by the creations on display in the various workshop and ACL threads. In other words, you can build nearly anything, but there isn't really any inherent motivation to, which has to be supplied by the players creative urges or community challenges.

The code contains several parts, ranging from the relatively straightforward but tedious to fully implement, through to parts presumably intended to have complex functions but only exist as a name and a model. Making these usable is likely to be part of the first stages of development as a reasonably safe addition of content we've been denied all these years.

Where to next?
The Rawbots universe is fairly dull, populated by a scattering of barren planets or whatever blocky structure the player cares to build suspended in an infinite void. On the structures front, there are plans to re-add the pillars and platforms seen in earlier versions, suitably scaled for compatibility with the smaller terrain hexes found in the current version. Also to be added are an assortment of minerals, resources and asteroids, which will start to bring the world alive and lay the foundations for an energy economy and motivation for exploration. While these would likely be inert statically generated features at first, developments could include random spawning, regeneration of resources, mining/harvesting and increased variety.

Longer term:
Cupid has done a pretty good job of outlining how gameplay driven by an energy/materials economy would work, so I'll just add a few paints here. While getting to this point is unlikely to require a complete overhaul of the game, significant changes will be required, and it would be best for us to understand the ultimate objectives now, rather than starting out without a clear picture and finding we've made some feature far more awkward to add than it otherwise could have been. In my opinion, the end game should provide a reason to build, automate and explore a dynamic universe, while allowing room for creativity for the sake of creativity at all stages of progression. Populating the world with NPC bots could be cool and really help bring the universe to life, but risks changing the character of the game, especially if things get too combat-heavy and it ends up resembling a base-building/tower defence game.

Parallel goals:
In addition to ongoing bugfixes, and the developments listed above, there should be gradual bot-building focused additions. These would include original new parts, new operands, building/programming aids, user friendliness/UI efficiency improvements, etc. As mentioned previously, there are potential changes to the underlying platform/physics engine, but I'll keep this post limited to user-facing changes for now.
Development Logs / The Development Road map
« Last post by cupid_the_conqueror on March 28, 2019, 09:30:16 pm »
Hello again folks! As part of our policy to avoid pulling a Rozgo and leaving you all in the dark. I've decided to post a rough devlog of the changes and updates to the game we will be trying to push out over the coming months. Some of this stuff is pretty complex and won't be seen anytime soon, but there are some smaller items you should look forward to seeing soon!

So in the general order of how we plan to roll them out, here is the stuff you can look forward to!  This post will be changed overtime as we adjust our dev goals. Check this post every now and then  to keep up to date!

Rawbots 1.6 - Bug Free and Filled with content!
Spoiler: show

Our goals for 1.6 is to quash the final 2 bugs we have remaining in our dev branch, and then put out a stable release with the following content added :
- Colorizer VP : Takes RGB values to give you an FFFFFF color, can be used to make disco bots with the help of a oscillator!
- Comparortor VP : Returns a designated + or - Value based on which input is greater.
- More Math Functions : Limit - Limits output to a range within the selected inputs. 
- More Math Functions : Slew - Limits the rate of change in a system
- Magnet Part : MAGNETS? HOW DO THEY WORK? - Attracts parts in around it in a field.
- Rope Part : How else could you go part fishing with your new magnet? - will be able to "pull" but not push, grappling hooks anyone?
- Selective Disconnect mode : Allows you to disconnect 2 parts, without breaking ALL connections those parts have
- Mouse Wheel Rotation of Parts : does exactly that, use scroll wheel to rotate
- Motor Idle- Motors can be set to idle and will now freely spin.
- Planet Draw distance : How can you explore worlds you can't see? planets should now be seen from anywhere in the solar system on Stardust Style maps
- Blueshift Map Despawning : Parts that fall into the void can start to build up slowdowns over time. Parts will now be despawned after they fall a certain distance.
- Resurrection of old assets : parts like armour, pressure plates, crystals and what not which appeared in the orignal rawbots trailer will be re-added to the game.
- Build mode (Possibly) : A reduced gravity, physics damped environment for building bots easily. With a real editor coming MUCH later in development
- Some more stability fixes : We hope to get rid of collison checks between connected parts, they aren't going to collide with each other.

AFTER 1.6 , sometime in the far future

New Bullet API
Spoiler: show

We need to upgrade to the newest verison of bullet for more stability fixes and performance improvements. This is going to require alot of re-writing and fixing. This update may take a month on its own.

x64 Builds
Spoiler: show

X64 architecture will get us access to more ram, more ram means more things loaded at once and less slowdowns. This maybe require an update to the newest bullet api or unity edition, which will be alot of work. this feature isn't coming anytime soon

More VP tiles and A map
Spoiler: show

Vp tiles we'd like to add :
Folder VP - allows a section of the vp screen to be "compressed" inside of it without messing with I/O. this will allow us to clean up the VP screen for complex bots
Advanced Math VP - Takes a formula, generates inputs equal to the amount of unknown variables in the math. Outputs the missing variable solved by the equation

Map - Takes the local terrain and generates a map image based off of it, allows mousing over to see GPS coordinates of that spot in the world. Won't have any features like Waypoints or Radar at the start.

Damage Shader and Part destruction
Spoiler: show

How damaged is that part? Who knows? We want to add a way to gauge the damage of a part, and make it so parts that lose all HP explode/break apart and are removed. Parts falling off will still be a thing, but won't be from just damage alone. A fist might punch your head off, but a Plasma cannon will just make it explode. Stuff at the center of a grenade blast will be vaporized , but the shockwave can still make parts go flying.

The Great Energy Economy
Spoiler: show

This isn't coming anytime soon. This is our overreaching goal for the YEAR, it requires a huge amount of work. From creating Models, to programming alot of behaviours. But here is our loose plans at the current moment :

 We need to add gameplay to rawbots. This is my personal theory for the direction on which we should go. Let us begin the biggest of all  theorycrafting.....

Do we want rawbots to be “survival” exploration? Where once you’ve pillaged an area you have no reason to return, or “survival” adventure where the player has a base that they can return to such as games like TERRA TECH?
I will assume the TERRA TECH model for the case of this theory crafting.

So for starters, everything uses energy at a rate proportional to its usage and balance factors. I would have VP tiles use energy as to encourage effective coding (why do 5+5+5+5+5 when 5X5 works?). I would have all output devices consume energy (motors, plasma cannons, jets, hovers, ect). This will give us freedom in the future to release “time saving” VP tiles that consume a high energy rate (such as a FIRE vp tile, which generates a firing solution for you, or a GPS tile which returns target XYZ). Of course the energy cost of VP tiles would be very low, and its purpose would be to add a slow drain effect to bots, which justifies ON/OFF mechanics.

I would have the spawning of parts require energy. I would have the repairing of parts require energy (as at some point we will need to create damage states for parts besides just “falling off the bot”)

Now as for Energy Economy itself. I would limit the player to a maximum amount of energy storage. Which could be increased with “energy tanks”. I would then create a system of base building utilities. Such as a storage depot for energy which can be used while within a fixed radius of it. And down the road parts which can “transmit” energy from depot to bot at a cost would be added. The energy sources would contain maximum amount of energy which requires time to harvest and eventually depletes. I would have energy sources spawn and respawn at random locations on the planet, outside of player base structures Hypercubes would make perfect “harvesting/storing” tools. In order to help the player EXPEND that energy, I would have hostile combat bots spawn around the player base at various distances. Easier bots spawning closer, Harder bots spawning further. ACL bots could already perform this function quite well.

Now to encourage the exploration of the planets. I think we should create more then just one resource type, although after the creation of energy, other resources would be easy re-skins. Better parts would require better materials, some of which would not spawn on the starting world. This would allows us to create more content for player base building (Storage Depo, Advanced part spawner, Resource refinery, Turrets, Energy bridge walls, Teleporter, ect) and allow a longer gametime before players reach “end game” status.

Here is the example of my gameplay loop

Start with basic bot → find some energy to harvest → make a depo → improve your bot with some basic parts/weapons → explore the world to find more parts to “unlock”  and more energy → improve your bot with the new parts → repair your bot when it gets damaged → find all parts to unlock on base world → explore other planets → die a few times and respawn with your bot back at your depo → fly back to new world → establish new base → explore new world until all parts are unlocked and your bot is king of the bots → end of upgrade cycle, all gameplay past this point is purely emergent.

Of course since rawbots is a programming game, I would hope we can come up with some way to have player programed bots do basic tasks such as harvest resources and seek and destroy hostiles around a base, or do guard duty around the player.

The creation of this world would also allow stuff like challenge areas, “boss”fights and other such things. But that is a little to deep for my theorycrafting.

I hope this fills you guys in as to the work we are doing, and if anybody wants to lend a hand (we got any blend masters in the crowd?) you can hop on the discord and talk with Marvin, Pressureline, Z26 or Myself.

Keep calm and Build Rawbots!
Development Logs / Dev Log: 23/03/2019
« Last post by cupid_the_conqueror on March 24, 2019, 12:42:04 am »
Hello ladies and gentlemen. I have some good news and some bad news for you this week!

The good news is we have a build that is ready for release. It isn't perfect and we are aware of some key buggfixes that are still required. However this update contains some stability tweaks, Along with all the base XFM features. Nothing too fancy in terms of features yet, but they are in the oven and cooking.

The bad news is we have had a small setback due to GitClient errors and had to reset to a backup. We haven't lost much but we are out a few days work and will need a day to reset and get going again. Rest assured we've started to implement internal documentation and processes to avoid this happening in the future! we are all first time devs, so some hiccups were unavoidable.

Without further adue, I present to you Rawbots 1.5B!

If you find any bugs in this edition let us know. Even if you think we've already found them, it will help us determine the order of bug fixing.
Also, if anybody out their is contemplating making new parts for the game (which I am sure you've all thought about) I will be putting out the a public guide on what you need and how to create a part for rawbots.

In the coming weeks we hope to address :

- Outputing nans causes crashes
- Adding more operands
- adding some useful parts
- Stablity
- Stability
- Stabilty 

I look forward to next week, when hopefully I can show off alot more.
Development Logs / Dev Log: 16/03/2019
« Last post by PressureLine on March 16, 2019, 04:46:12 am »
Development Log: 16/03/2019

What a week! The first new Rawbots release since 2013 is fast approaching. While there's no really fundamental changes in the works at present, there is quite a lot of cool stuff happening. The observant among you will have noticed in last week's devlog that XFM features are being incorporated into the main build; like the 'string' output on Math operand tiles in the VP grid, which allows you to connect them to Label operands and thus allowing Projectors to act as (amongst other things) speedometer and altimeter readouts on your bots. The performance increasing aspects of XFM have also been incorporated, and the graphics quality settings have been tweaked to ensure a better visual experience for all.

In the 'new feature' space there's been a decrease in the visual (the collision model is the same size, which actually matches it's visual size much better) size of the plasma cannon's projectile. At the suggestion of the Rawbots Discord server users you also now have the option of using your mouse scrollwheel to rotate parts when attaching them, in addition you can also hold 'shift' while rotating the part to rotate it in smaller steps.

And the 'stardust' map makes it's return to Rawbots after a long absence!

If you want to make suggestions or request new featues, head on over to the Development forum or even the Rawbots Discord, and start up a discussion.

Keep calm and build Rawbots!
Pages: [1] 2 3 ... 10