It’s alive!

The cones are spawning in the middle of the road and then being tossed up as if they’ve collided with the ground, but other than that it’s great! Here’s the link:

https://newcarrots.games/games/carcoder/

I’ll add that to the side-bar as well. There are about a hundred things left to do, but I really need some feedback at this point in case there’s something I didn’t think of or something I want to change that will be too hard to change later.

Beta Release

Welp, let ‘er rip! The game is ready for beta, I just need to figure out how to upload it to this site. I don’t even remember how I set this up. Bother!

I will go work on that and update this post when it’s ready.

UPDATE: WebGL build failed to load the level files because WebGL doesn’t support os level functions.

That should have been obvious, and I seem to remember thinking that, but then immediately thinking I’ll deal with that later. Well, it is now later, so I have to deal with it.

I have to configure a static assets folder and feed them to Unity that way. So, the beta release has been rescheduled for next week! Stay tuned!

Player Progress Working

CarCoder can save the player’s progress finally. I worked on the single instruction deletion/removal code but it proved to be harder than I thought, so I switched tasks, and now you don’t have to start over every time you restart the game. I had already made the level progress object serializable in anticipation of eventually doing this and after some research discovered the PlayerPrefs class which works nicely for persisting string or int values between executions. The nice thing is it will work on any platform I build the game for, and although the WebGL build can only store up to 1MB that’s actually more than enough for what the game needs to store a basic object like this.

I have to get back on the single instruction removal stuff now, and, of course, some new bugs have cropped up after I fixed most of these. Now, for whatever reason, you automatically beat the level as soon as you start which is great for testing the level progress is being saved but horrible from the gameplay perspective. Unity’s UI support is great, but for me, it’s a slow learning curve, and what seems simple at first can quickly become complex.

Angular Velocity Listener Working

The game can tell how much your car is turning now and you can set a threshold on that amount to trigger an event. It’s used in level 14 where the goal is to have your car spin out of control. Only two things left now, deleting single instructions and saving progress. Not sure how saving progress will work in the web build. Localstorage maybe? dunno.. we’ll see!

Fixed Level 5

Cross that off the beta test punch out list. Now it’s on to the angular velocity listener for level 14. I’ve worked out a good schedule that allows me to work on the game and play rocket league (well.. let’s not forget work, school, and family as well.)

Progress Not Perfection

I have decided to clean the game up as it is now and begin beta testing. I wanted sixteen levels but I only have fourteen done which is fine. I started riding the train into work now that the kids are in kindergarten and we no longer have to drop them off at daycare, so that gives me time before work that I can use here.

Here is an off the top of my head punch-out list of the remaining critical bugs in no particular order:

  • Level four (or three, not sure) has another car heading towards the player’s car but the controls got mixed up so any instructions meant for the player’s car end up controlling the other one. I worked on this the other day and decided to use a new model for this car as well which is not working because the wheel colliders are messed up. This prevents the player from completing level four.
  • The angular velocity listener is half done. This component observes the car’s rotational velocity and accepts an expression like, “angular velocity is greater than 10,” which would mean the car is rotating very quickly. It needs to report back to the level manager when the listening expression evaluates to true. It’s used on level fourteen to determine if the player has spun the car around enough (has done enough doughnuts.) This prevents the player from completing level fourteen.
  • There’s no way to delete a single instruction. You can move instructions around using drag and drop, but you can only remove a single instruction by deleting the entire list. This makes the game too frustrating to play.
  • The game needs to save your progress. If you start the game over, you have to start back at level one. Another frustrating issue that will stop people from playing.

From now on, I will only work on issues that are truly blocking the game from its first beta release. The first two are total show stoppers, but the last two will also cause people to stop playing. There are some other features I would like to have, but will not stop anyone from beta testing:

  • Bronze/Silver/Gold awards when completing levels. In this case, they’re shown as different color traffic lights (red/yellow/green of course.) I need to develop a way to determine how well the player solved the level and reward curiosity and ingenuity somehow. This is actually a lot more difficult than I first thought because each level has its own criteria for determining progress. One level might be measured by raw speed while another will be measured by the number of injuries caused.
  • I would like to offer better coding controls somehow to people who want to get technical. The current structure of the coder is very simple and allows anyone to use it, but what if you want to accelerate and turn at the same time? My idea was to offer simple, intermediate, and advanced coding interfaces which all break down instructions into a new programming language just for the game, but that’s a lot more work than I want to admit.
  • I still want sixteen levels because sixteen is 2^4 (nibble), and, just as a general value, it often occurs in computer science e.g. hexadecimal notation.

Also, this is the model I want for the car (but I can not justify the cost without a product at least in beta):

Wish me luck!

Hard Part Is Over?

The concepts behind all sixteen levels of Car Coder are in place, and the bulk of the remaining work is the code needed to support the goals for levels fourteen and fifteen. Also, the layout for level sixteen, which is just going to be a combination of the past levels, is not done. I feel good about the recent progress made but now finding time to work is becoming more difficult because I need to make this more of a priority than I have been. Changing habits is hard, and I always want to change everything overnight which never works and ends up frustrating me more.

This is my problem now:

Rocket Crack

Holy half-flip, Batman, this game is fun. I have been playing this every opportunity I have had to do so since I started playing it about a year ago. My gosh, I like this game. Given the choice between working on my car game and this one, I will choose this one, so I need to stop that. From now on, I will not play Rocket Crack™ until I have given dev time to Car Coder!

#newcarrots

Level 10 & 11 With Some Other Stuff

Level 10 and 11 are working now. For level 10, a crowd of people is (are?) crossing the street, and for level 11, you have to drive in between two stationary people. When I say people I mean the pedestrian model I discussed in my last post. I’m making myself finish a new level every week until I hit 16, so levels 12, 13, 14, 15, 16 should be done in the next five weeks assuming I don’t have like a vacation or something coming up. When that’s done I’ll focus on polishing the game up. There’s going to be a serious amount of work then, but for now it’s just fun.

I wanted to talk about another idea I’ve had that came from me learning that none of the really big rogue-like games that are popular right now are taking true advantage of multi-threaded application design. Specifically, Dwarf Fortress runs on a single thread and this just seems like a tragedy to me. I had to stare at the wall of my bathroom for a good two minutes after reading about this if you know what I mean (spoiler: I was pooping at the time) and fester on how it could be that the game considered to be the most complicated simulation in the world runs as a single threaded application. Someone pointed out that it does run things like rendering and sound on separate threads but the vast majority of the simulation does not take advantage of multi-core processing which becomes noticeable once the game has a lot happening right in front of the player. I’m guessing things off screen are just approximated which I get because we don’t have enough machine power to simulate everything in the world, but, I mean, really?

The Layers Of The OSI Networking Model

I was quite sure after reading this that the developers behind DF had very good reasons for doing this. Things have to happen sequentially for the simulation to make sense, and doing things all on the same thread ensures things happen in the order they should, but I am not able to accept this explanation because I have heard suppositions like this before and have seen them proven wrong, so I decided that I needed to take matters into my own hands and develop a massive simulation like DF while attempting to take advantage of
multi-threaded processing to see for myself why this is impossible. My theory is that I can break up the work if I set up everything using a layered approach (similar to the OSI networking model) and then pass this on to a thread pool for processing.

The most basic example I could think of was considering times when multiple creatures attempted to enter the same block (google rogue-like or dwarf fortress and read about how the map is setup if you’re not sure what I mean by this). If two threads checked that the block was empty at the same time, each would see an empty block, and then allow the creature to enter the block, which as far as I know isn’t allowed, or would at least signal an interaction between the two. However, if you broke this task up into a few different pieces, each creature could then create a request to enter the block which are placed in a block-specific queue, and are then dealt with by the thread pool once all the creatures have made their movement requests. Breaking up things into smaller and smaller chunks, you should be able to spread out the needed instructions across multiple CPUs (GPUs?)

One situation I keep thinking of works like this: two creatures want to move into a block, so some thread comes along and says, hey you both can’t move into the same block, do you want to attack instead? One may say yes, the other might say no. Who moves into the block? Additionally, lets says 10 CPU cycles later, turns out another creature wants to move into the same block, do we now go back and ask the first two creatures if they want to attack this third creature? Do we have to accumulate all the movement requests before they can be processed? Also, creatures can been in different states at different times, and even multiple states. Most animals and people can think and move at the same time, right? So, once a creature decides to do something, and they’ve made this decision before another creature does, shouldn’t they get to move into the block (assuming they’re faster) first? And once they’ve moved into that block, wouldn’t that influence the decision making process of any other creature within viewing distance?

There’s a lot of questions like this to answer, but even if you were to assign threads to groups of adjacent blocks, it would be a better design that using a single thread for the entire simulation. However, truth be told, the real question is, how in hell am I gonna find time to do this?! 😉

Level 9 (Now With Pedestrians!)

You can’t have the old trolley problem without taking a few innocent lives, so the game needs pedestrians!
Unity offers many prebuilt assets for this, but because I’m still in the initial development phase focusing on the real content of the game is more important than wasting valuable time and willpower dealing with complicated 3D models of humans. While I was trying to get to sleep a few nights ago, I realized that I just needed to make the cardboard cutout (used in a previous level) mobile, so why not just put wheels on it so it can roll around in whatever direction I need. Here’s what I ended up with last week after wasting a few hours with blender (I ended up just using unity’s primitives because I’m too impatient for a real modeling app):

The Wheelbase Prefab

My modeling skills are embarrassing at best, but it works. I want to make the wheels more like bicycle wheels that spin when it moves so it looks like somebody made it in their garage at 3am. It’s only able to move in one direction, but you can specify the speed. I also want the pedestrian image itself to be an actual cutout not just a textured plane, but that will have to happen later when I have all sixteen levels working.

Bad as it looks, it works, and I was able to do the first real level where the trolley problem is implemented in the game. I’m hoping to have a playable demo on here soon. The neat thing was adding this to the game as an obstacle attached all the behaviors the previous obstacles have as well, so colliding with it causes a failure and so forth without any additional coding on my part. Maybe you can OOP correctly?

New Home and CC Update

So, we’ve relocated to https://newcarrots.games and I’ve finally got the code editor working the way I want. I need to build and publish the latest version of CC up here somehow.. working on that now. I’ll post an explanation and also write about some of the problems I’m having now with finishing CC.