Skip to main content

Vehicles in game (again)

It's been a while since i posted any updates. It's not tat I haven't been busy, only that the work hadn't reached a point where it was worth showing.
It's been a lot of small incremental changes, building a modular menu system with widgets and buttons, porting over some of my old code for displaying vehicle models etc...


This is just a dummy menu at the moment. From here I can set the active profile, manage vehicles for testing and jump right in to an in game testing environment.

Each chunk of screen space like this is a widget. It can have a number of buttons. The buttons react to being moused over and clicked. They send a message to the widget to decide how to deal with that interaction. The widget then executes some code and might reset the menu page or load a different one.

Clicking manage vehicles loads this menu:


I've moved some of the structural elements of vehicles away from components mounted in the vehicle and in to a system of options which modify how the vehicle stats are generated. For example, sloped armor is now a property of a vehicle and not something you can just add in the factory. It requires a whole different vehicle layout.

Clicking on contents takes you to the temporary vehicle contents modification menu:


The colored components you can see placed in the chassis will feature images to describe the parts placed there later, but for now it's just testing so they are just colored tiles. During testing I've discovered that I've made the chassis and turrets too big, there's too much space when compared to real life vehicles. This results in vehicles which are too heavy for their size category. I'm going to have to go back and juggle those values some more once I start testing more systematically.

Components are now single entities with a limited supply, if you pick one up from the inventory box, it is removed from the inventory. You can drop it back there by clicking outside the chassis in the contents box, or automatically when you either leave the menu or when you pick up a different item. There will be another screen where you can buy new components to add to your vehicles.

In game you will buy or salvage vehicles and then buy or salvage components to use in kitting them out.

The vehicles are now ready to be added in game:


I think they are a little small right now, so that's another thing I'll be modifying in future.
Next step is working on vehicle combat and movement. After that maybe enemy AI. Finally mission selection and design, UI and mini map and then it's nearly done. At that stage I'll be working on content, like all the infantry sprites, buildings and probably reworking the vehicle models.

Before that though I'm going to be doing some work on refactoring the code so more of the agent's behavior is in the agent states instead of the agent object, that will make it easier to write the AI control code.

Comments

  1. Will a unit be able to steal a working enemy tank?
    Like a engineer or a saboteur?

    ReplyDelete
    Replies
    1. Yes, if the crew is knocked out you can send in your own.
      Have to see how it goes in testing, but capturing enemy equipment is going to be quite a big part of the game.

      Delete

Post a Comment

Popular posts from this blog

Automating Level imports from Blender to Godot

  Recently I've been making some levels in Blender an importing them into Godot. There are only about 7 or 8 shaders for each level, not counting dynamic objects which will be added later. But to improve rendering performance, it can be a good idea to split the meshes up into sections. At that point you might be faced with a list like this: Or it might be even more chaotic, if you didn't use simple names for the objects in your level. So it can take a long time to sort out all the meshes, make them unique and add textures and so on. Blender imports with simple Blender textures, or with placeholder materials. This is sometimes OK, but if your Godot shaders are very different to those used by Blender, it means applying new materials to every mesh object in the level when you import the scene. I found that during the design process, I was importing and readying a level several times before I was happy with the final layout. So at first I was wasting a lot of time. In Blender, I us

Upstairs / Downstairs.

I've decided to make my prefabs multilevel. Later this should allow me to add pit traps and other great stuff. It also makes it easier to line up stairs so that you can exit them on the same co-ordinates where you entered them. The prefab editor is pretty much finished, it just needs some code for loading up prefabs from a saved dictionary, so that they can be checked or edited. The entries will need to be forwards compatible, so I'll be loading each tile and then translating the indexes to a new array, that way if I add extra indexes or extra info (like traps or puzzles) I'll be able to update existing prefabs to work with the new standard. Click for a video.

Advice needed on tilesets...

I need some advice on which is the best way to handle building the dungeon. Right now I'm using prefabs for my dungeon, they have a north south east and west section for each "room": The basic tileset. This has several advantages, and also several disadvantages. Firstly I can have curved rooms, I can have tunnels and other interesting shapes. The tilesets can look quite nice with a little work. On the other hand I can't easily get the navigation data before building the map and once the map has been built I can't make changes to the layout, like having active pit traps or believable secret doors. Although the rooms are interesting, they are quite repetitive, and it takes a lot of effort to make even a few different variations. Also rooms are constrained to one size. A newer version of the tileset with a lot of variant parts for making more interesting rooms. To create a tile set is a real headache too. Planning how to lay out the UVs, trying to cra