Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - cjbruce

Pages: 1 ... 38 39 40 41 42 43 44 [45] 46 47 48 49
881
What does D.B. stand for

  :bigsmile:

No one is quite sure, but we are open to suggestions.

882
What does the bar under the HP bar represent? Would be useful for it to show CO2 levels on Eruption or spinner speed on Carbide
On Carbide, at least, it appears to represent motor temperature or something. If you have the weapon spinning for too long, the bar starts to fill with red, and you have to release the weapon button to get it to lower again. I don't know what happens if the bar fills all the way up but I'm guessing the weapon just stops working.

Heck yeah, 500 posts

You are correct on all counts!  Nice detective work!  (and a little bit scary) :smile:

883
What badger said.
Also the start points seem a bit odd. Like robots often start facing away from each other but sometimes not. I tried a match with original sin in the sumo ring and the physics pushed me out right when I spawned. I could also see the path that AI was planning to take. I assume that's just a debug feature that isn't normally supposed to be visible.

But other than that, great work. I'm looking forward to seeing the robot and arena editors in a more developed form. Looks very promising
Oh yeah, that was one of the bugs I forgot, Eruption always spawns facing backward.

Also might be nice if the dummy bot was invertible, so it can better serve its purpose as a punching bag. Just my personal opinion

Agreed!  We have D.B. Mk II coming in the next build, so it will be an easy change to make.

884
What badger said.
Also the start points seem a bit odd. Like robots often start facing away from each other but sometimes not. I tried a match with original sin in the sumo ring and the physics pushed me out right when I spawned. I could also see the path that AI was planning to take. I assume that's just a debug feature that isn't normally supposed to be visible.

But other than that, great work. I'm looking forward to seeing the robot and arena editors in a more developed form. Looks very promising

This was a problem with the way models were imported from 3DS Max, and shouldn’t be an issue for things created in the BotLab.  Unless a miracle occurs and we can get permission to use Eruption in the released game, the problem will go away with the Eruption model.

Something is wrong with the Sumo Basho arena physics, but I haven’t been able to find the problem.  We might need to rebuild the arena when the Arena Builder is ready.

I kind of like seeing the AI path line.  You are probably right that we should turn it off though.  :smile:

Thanks for the support and feedback!

885
Gave the newest build a shot, it's starting to look like a very solid base for a full game. I've found some bugs and I have some suggestions.

Bugs:
Some z-fighting with the dummy bot, particularly on the warehouse stage. At one point the mesh floor on the warehouse briefly displayed over the dummy bot's decal.

Suggestions/Compaints:
Eruption's flipper feels super anaemic.
Carbide's spinner feels like it's very slow, but with a ton of torque.
Everything feels like it has way too much HP. Except once an AI Carbide's blade fell off just by hitting my Eruption, with no non-HP damage being cause to my Eruption.
It's difficult to figure out what's doing damage when Original Sin's opponent is taking damage. Is it impact with the arena wall? Contact with the wedge arm things? It feels inconsistent.
What does the bar under the HP bar represent? Would be useful for it to show CO2 levels on Eruption or spinner speed on Carbide
Eruption's limited CO2 supply is realistic, but not very fun at all, especially with how weak its flipper is. Maybe give a debug option to allow unlimited flips?
Part of what made RA2 so long-lasting was the fact that component data was stored in a user-editable format, allowing for customization. Would it be possible to read robot data from text files, allowing the user to edit carbine's spinner speed or eruption's flipper power, for example?

I had a couple more bugs and inconsistencies but I've forgotten them now. Oh well. ¯\_(ツ)_/¯

Edit: I also managed to flip the DB out of the sumo arena without the DB being killed or the round ending
(Image removed from quote.)

Nice catch on the z-fighting.  I need to get smart on Unity decals.  All of the robots were modeled in 3DS Max, rather than using the in-game BotLab, so we will need to revisit this when the BotLab is ready for production.

Carbide’s spinner is actually spinning very quickly, but the on-screen representation of its speed is poor.  The game only shows its position every 1/60th of a second rather than as the continuous blur that you would see in real life.  I was hoping that I could avoid addressing this, as it is a more difficult problem to create cylindrical blur for the arbitrary spinning objects that people will create in the BotLab.  I have a few ideas on how to do this, but it might take an iteration or two to get it to look right.

Thanks for the feedback on Eruption’s flipper.  It used to be insanely powerful, so I toned it way down. Increasing the force is an easy fix.  For those of you who are curious, the flipper has the following exposed variables, all of which will be adjustable in the BotLab:
piston diameter
piston stroke length
high pressure cylinder CO2 capacity
buffer tank volume

The lack of Hit Point indication is big problem.  I would like to avoid damage numbers appearing above the robots, like in RA2.  Ideally, a player will see sparks, smoke, damage decals, and hear sound to indicate how much damage has occurred to a particular component.  I would like to reserve damage numbers as a last resort.

The hit point bar shows damage only to the body of the robot.  Original Sin is surrounded by parts that take damage separately from the body (wheels and wedgelets).  You have to knock off these parts before you can start damaging the body of the robot easily.

The heat bar is pretty much nonfunctional at the moment.  The intent is to have heat dissipation, heat generation, and environmental heat sources (lava pit or flames).  When a motor overheats, it shuts down, and if temperature gets too high, components take damage.

I agree that there needs to be some indication of remaining CO2.  There also needs to be sn indication (venting gas) that a CO2 leak has occurred, and whether it is a slow leak or a catastrophic leak.

I like the idea of user-editable components. @tashic, is this something we can put into the BotLab directly?

I will take a look at the OOTA volumes for the Sumo Basho arena.  It should be a simple fix to add more volumes.

Thanks for all of the great feedback!  I’m pretty swamped with another project right now, but I hope to have another release out by the end of March.

Also, for those of you who are curious, we are planning to have public releases like these until the first Alpha release.  The first Alpha release will be the first “Vertical Slice” and contain all of the basic functionality for the game (BotLab fully integrated with the arena and arena builder).  After that, we will do closed Beta releases, so if you are interested in the closed Betas, be sure to sign up to be a beta-tester on www.robot-rumble.com!

886
Seems cjbruce hasn't posted about it here yet but there's a new build out, with breakable components, new components for the bot lab, and a prototype version of the arena builder, among other things. I'm only posting about it because I want to offer some feedback:

  • The new immobility countdown flickers a lot, which is irritating, and if multiple robots aren't moving then it switches between them rather than each robot having an individual countdown
  • The text is wonky on some of the buttons (esp. in the arena builder). Dunno if that's just coz I'm playing in 720p windowed mode though.
  • The sound balance feels off - some sounds are too loud, others are too quiet. Dunno if it's just me.
  • Eruption's flipper apparently has a limited amount of CO2 but I don't see that indicated anywhere in the UI - if the blue gauge is CO2, then it's not depleting
  • If you click "Help" in the Robot Lab, it spawns a fully-finished robot that then sinks through the table. You can spawn them indefinitely and fill the lab with them. Amusing, but probably not intended?

Still looks great and feels great, though. Rome wasn't built in a day, as they say. Keep up the good work!

You beat me to the punch!

I was trying to concurrently wrap up this build and manage our high school's robot combat club.  Here a little taste of the last three days' festivities:



This new build has a lot going on behind the scenes.  I have been doing a ton of experimentation with driving, AI, and physics.  I also put in place the immobility timer.  There is also a component damage system, and Eruption is built with the new CO2 gas system.  Most of this stuff doesn't include any user feedback yet, so you won't know that a wheel is taking damage until it falls off, and you won't know if you are out of gas until the pneumatics stop working.  It is all there, we just need to add sound and particle effects so that there is an indication that something is wrong before it just stops working.

@tashic has been really busy with the BotLab.  It still isn't ready to make a complete robot, but a rudimentary saving system exists.  You can see the save files as robot.txt in one of the game directories.  At a minimum, we would like to get to the point where you can manually share robot files around like you do with RA2.   If we have time, we might be able to automate the process, but this is more of an aspirational goal at this point, and it is more important to nail down the basic functionality.

@anarchy_fox has been working hard on the Arena Builder.  A lot of the stuff from the BotLab should be reusable in here, but we are still very early in the development.

To everyone who has tested it already, thank you!


887
Wow, This is really cool! I had a lot of fun throwing carbide around the arena
However, am I the only one experiencing severe input lag? It seems to take about a second for the game to register my inputs. Idk if its just my low spec laptop or whether it was an intended feature to simulate IRL robot controls maybe?

We haven't included any input lag in the simulation.  What are the specs for your laptop?  Are you using keyboard controls?

The game works great on my 2013 11" MacBook Air, but I am curious to see how low we can go with acceptable performance.  I am hoping to target midrange phones and WebGL.  Phones will probably be okay, but I'm struggling to get WebGL working, not sure why at this point.  We might have to wait for the Steam launch before looking into the WebGL version again.

888
I've just downloaded the linux version and this is what I get.
 [ Quoting of attachment images from other messages is not allowed ]

Thanks for trying this!

I might have to create my own linux machine to test it.  Apparently the crash details are buried somewhere in a log file:

https://docs.unity3d.com/Manual/LogFiles.html

889
I just put Robot Rumble 2.0 on an iPhone 7 Plus, and here is the result:



The game runs solidly during combat, but the BotLab crashes as soon as you try to load it.  This might be fine -- a limited action-oriented version of the game for mobile/Apple TV/console, with the BotLab and Arena Builder reserved for the full version on Windows/Mac/Linux.

Speaking of which, has anyone tried the Linux build yet?  It should work okay, but I don't have a machine set up to test it.

Sometime over the next few days I am going to try to get the game running on Apple TV for local multiplayer with two controllers.

890
Great progress so far!
I've taken some time to test it thoroughly and here are some notices
- So anytime a select a camera, W and S move the camera setting, and if i press space (weapon button) it selects the camera, which is annoying. Could you remap the camera buttons to f1, f2 & f3 (like in ra2)
- AI Eruption doesn't self right
- Eruption's flipper is too op in damage, or bots are fragile af
- Carbide deals no damage, or force, which makes me think if there is enough weight on spinner for force to flung enemies
Some wishes:
- Immobile countdown timer
- Maybe a component maker, something like a chassis maker
- Material for maker (Steel, alu, etc..., great for comp maker)
- Camera that follows you and AI (Something like Action cam in ra2)
- RA2 like attach point system (maybe add a button to enable/disable it)
All in all great progress and i wish you the best!

Oh man, thanks for all of the great feedback!

1.  Thanks for pointing out camera control mapping.  I'm working on a MacBook without quick access to F-keys, so we might do number keys instead.  Either way, controls up at the top of the keyboard would probably work great. 
2.  Self-righting should be working.  I must have accidentally nerfed it when I rebuilt the pneumatics system.
3.  Damage is our next big thing to tackle.  Right now, damage is based entirely on Joules of energy absorbed, not on force.  This works great for things like "my robot just bashed into a wall and is taking internal damage as components are jostled", but completely ignores things like pincher weapons that apply a consistent force over time.  Right now I am thinking a hybrid of the two might be best.
4. Countdown timer -- check! :)
5. I'll defer to @tashic regarding the component maker. 
6. The ability to make arbitrary 3D shapes exists, but right now there is no texturing/materials.
7. Which key gets follow camera control?  This should be really easy to do.
8. I will defer to @tashic regarding attachment points as well.

This is a great list.  I expect to knock out a least a few of these over the next month or so.  The biggest one is damage, followed by a more robust AI system.  The game still doesn't feel right, with AI being *too* perfect.

891
I absolutely love the game, so far. I don't know if it actually emulates real life, but I found that the person taking the initiative to move towards the opponent, when they have the same wedge (Eruption vs Eruption), always loses the wedge war. It lead to me losing to Eruption (as Eruption) over and over again until I realised all I had to do was not move, which shouldn't be what anyone should come to the conclusion to. I don't know how much useful this feedback is, honestly, considering the game is in the early stages of development and the pre-built bots are just a demo. Not to mention that I was using a bot against an exact copy of itself. I just thought I'd mention it, anyway. It did make me cry out in joy when I saw this, tho:
(Image removed from quote.)

Edit: After doing Original Sin v Eruption, that could be the way the wedge war works, in this game. Hopefully, this is just because the game is too early in development.

In all honesty, I never get my hopes up too much whenever I see anything like this pop up because the projects usually get abandoned, after a while. Either that or progress on them is made at the pace of a snail dragging a boulder. Nevertheless, I wish you an incredible amount of luck with this project. I really appreciate that you're working on this.

Agreed on all counts! 

Right now Eruption's "tactics" consist of the following:

1. Drive toward enemy.
2. Fire flipper the instant you collide with enemy.
3. Back up slightly until the flipper is reset.
4. Repeat step #1.

Carbide is even simpler:

1. Drive toward enemy.
2. When in range, turn on spinner.


We did a bunch of play testing with my robotics club students, and they found that the computer AI is frustratingly difficult to beat.  The computer is 100% agressive, and unlike in RA2, there is no "thinking delay" for the computer to evaluate its list of tactics.  All in all, I thought it was really good training for my students, who are going to take their real-life robots into battle at the end of February, but not so great for a game where it would be nice to be able to win against a computer opponent every once in a while.

There needs to be a balance, and, unless the game is designed to be AI vs AI, it isn't fair that a computer has zero reaction time when a human has a reaction time on the order of 2/10ths of a second.  On the flip side, the computer is stupid when it comes to hazards.  Right now it is not really avoiding hazards, it just marks an area around a hazard that is "not drivable".  As a human, you can exploit these areas by positioning yourself or the computer in them, then watch as the computer tries to get back to a drivable area.  It also doesn't have any sense of positioning itself or you with respect to the hazard, so you can use that to force the AI into a hazard.

I'm hoping that as I build out the AI system, things will start to come into better balance between computer and human.  We'll see. :)


After reading through a decade and a half of game development threads on here, I understand the sentiment about losing faith in abandoned development efforts.   The good news is that this is not Nerd Island Studios' first multi-year project, it is the fifth, and I am committed to seeing this one through.  It is, however, the most ambitious project I have ever started, and has required the development of more tech than any of the other projects.  We are shooting for a total development time of about 2000 hours, and I think we are on track for a mid-2019 launch.

892
Crashes on startup for me every time I try to run it. If I had to guess at the cause I'd say it might be that I have sh**ty integrated intel HD graphics on my laptop, but I can't be certain. I could well have ****ed up the install somehow. Here's the popup I get. I can also send you the crash logs if you'd like.

 [ Quoting of attachment images from other messages is not allowed ]

Ahh yes!  Our first crash logs! :)

There are four of us building the game, and I was hoping that if were stable for all four of us on different machines that it would be stable for pretty much everyone.  I'm using a 2013 11" MacBook Air with Intel graphics myself, and it is running pretty well, but I do have 8 GB of RAM.  Maybe I can dust off an old Windows laptop from the closet to see if I can reproduce the crash...

Would you mind sending the crash log to developers@nerdislandstudios.com?

Also, details of your machine's OS and specifications would be really helpful.  Thank you so much!

893
This is looking really, really promising. Keep up the good work you guys!

edit: downloading the windows build exe and trying to run it gives me this error:
(Image removed from quote.)
seems like you forgot to package the rest of the files with it

Fixed!  I accidentally included just the .exe, rather than the .zip with all of the files.

894
This is looking really, really promising. Keep up the good work you guys!

edit: downloading the windows build exe and trying to run it gives me this error:
(Image removed from quote.)
seems like you forgot to package the rest of the files with it

Drat!  I will try to fix it tonight.  Sorry about that!

895


10" AmpFlow wheels.  They are all you can add at the moment.  :smile:

896


Sumo Basho!

This is a tricky arena against an AI opponent.  There isn't much space, and it is easy to accidentally fall off.

897


This is a picture of a 5-robot battle.  Note the lines indicating each robot AI's path to its target.

898
The new builds are up on our brand new itch.io page!

Here is the link:

https://robot-rumble.itch.io/builds

In addition to this thread, we will be posting periodic updates on Twitter: https://twitter.com/robotrumblegame

The official website also contains a signup page for game-related emails.  When we are ready to go into beta testing, we are planning to use the email list for beta testers, so please sign up there if you are interested in Beta testing (hopefully next year!).  The official game website is: http://robot-rumble.com

899
I like the idea of the pneumatic system having its own individual components. it feels like those parts could be adapted to serve in a similar fashion in crusher/hydraulic systems as well.

That's what we were thinking too.  The extra parts definitely take up space, so there is now a balancing act to do, and you really need to decide if the extra space is worth it, versus just using motors.  It is also possible to run a pneumatic system without a buffer tank, but the amount of force produced is extremely limited by the rate of evaporation of the CO2 as it leave the high pressure tank.

Eruption is the gold standard, so I did some tweaking to get the numbers to feel right.  I'm thinking it is okay to have a pneumatics system that is less powerful than Eruption's but going much more powerful than that would be so weight- and space-inefficient that it shouldn't be worth the tradeoff.

900
We've been busy creating over the past month, and are hoping to put together a build in the next day or two (Merry Christmas!).  In advance of that, here are a few of the things we have been working on:

1. BotLab - The chassis builder is really close.  Now @Tashic is working on the ability to add components.  Right now, there is only one component in the list, a 10" AmpFlow wheel.

2. Navmesh - We are using the new Unity NavMeshSurface component to dynamically generate Navmeshes.  This will allow for robots to navigate through user-generated arenas.

3. AI Pathfinding Lines - The current build draws lines to indicated where each robot is currently trying to drive to.  This includes pathfinding around obstacles.  It is really interesting to watch as each robot shifts its target path as it moves.

4. Pneumatics system components - Eruption is using a new pneumatics system behind the scenes in this build, with three new components: CO2 Cylinder, Buffer Tank, and Piston.  This new system will be incorporated into the BotLab in the "Actuators" section in a future build.  In order to build a pneumatics system in the game, there are four key attributes:
a. CO2 tank capacity - Dictates how many "shots" can be fired before running out of gas.
b. Buffer tank capacity - Controls the shape of the pressure vs extension curve for the piston.  In particular, this dictates the amount of pressure the piston sees when the piston is fully extended.
c. Piston stroke length - This controls the geometry of the system.  A longer flipper stroke means a greater flipper actuation distance, but also a lower pressure at full extension, and more gas used.
d. Piston diameter - This controls the force exerted by the piston.  A larger diameter piston means more force (proportional to diameter squared), but more gas used per stroke.

5. Arena Builder (PREVIEW COMING SOON!) - The arena builder is still in its infancy.  I don't think we will be ready to preview the arena builder on the next build, but hopefully we will have something to show soon!

6. Sumo Basho Arena - @AnarchyFox was kind enough to port this one over from a previous project.  It is super simple, looks great, and works really well for testing basic robot AI.

7. 5-Robot Limit - We are pushing the CPU really hard, and it looks like the limit to the number of robots in a given match is somewhere between 5-6 robots.  We are including a 5-player version of the "Test Arena" so people can see how chaotic things can get with 5 robots in one battle.

Pages: 1 ... 38 39 40 41 42 43 44 [45] 46 47 48 49