abc013 / warriorssnuggery Goto Github PK

Also when actors are hovering over it, it should spawn special wave particles.

Currently, the menus are pretty compact and do not use the extra space they could have.
Also, margins and image scales are not lined up perfectly and the keyboard settings menu would need a redesign asap.

I am currently looking for ideas.

Conditions:

• x0 and y0 is 0
• tDeltaX and tDeltaY is infinity
  in
  

  WarriorsSnuggery/WarriorsSnuggery/Physics/RayPhysics.cs

  Lines 280 to 289 in 64a0089

  	if (tMaxX < tMaxY)
  	{
  	tMaxX += tDeltaX;
  	x0 += sx;
  	}
  	else
  	{
  	tMaxY += tDeltaY;
  	y0 += sy;
  	}

Game crashes, when trying to start. The playtest is specified for a special audio software, which I would like to be undone ^.^.'. I tried it with every selectable audio-ouput on my device, getting the same error. Version 1.4 still works for me, so one of the new mechanics seems to make the difference here.

exception log:

openal32.dll
System.DllNotFoundException: openal32.dll
bei OpenTK.Audio.AudioContext.CreateContext(String device, Int32 freq, Int32 refresh, Boolean sync, Boolean enableEfx, MaxAuxiliarySends efxAuxiliarySends)
bei OpenTK.Audio.AudioContext..ctor(String device)
bei WarriorsSnuggery.Audio.AudioDevice..ctor()
bei WarriorsSnuggery.AudioController.Load()
bei WarriorsSnuggery.Window.OnLoad(EventArgs e)
bei OpenTK.GameWindow.Run(Double updates_per_second, Double frames_per_second)
bei WarriorsSnuggery.Program.run()
bei WarriorsSnuggery.Program.Main()

debug log:

SHADER 1 locations: 0, 1, 2, 3;
SHADER 2 locations: 0, 1, 3, 4;
SHADER 3 locations: 0, 1, 3, 4;
SHADER 4 locations: 0, 1, 3, 4;
SHADER 4 shadowloc: 5

performance log:

61ms <- Configuring GL
133ms <- Loading Fonts

Even after installing the required software the game crashes - this time without exception nor entry in its log.

debug log:

SHADER 1 locations: 0, 1, 2, 3;
SHADER 2 locations: 0, 1, 3, 4;
SHADER 3 locations: 0, 1, 3, 4;
SHADER 4 locations: 0, 1, 3, 4;
SHADER 4 shadowloc: 5

performance log:

55ms <- Configuring GL
122ms <- Loading Fonts
585ms <- Loading Sound

• Player can choose 8 players at the start
• Switching players requires some time

This is due to the changes in the rendering system, which is discarding, allocating and saving huge amounts of data per render. This whole thing is happening here:

• Motivation: The current renderer model does not only hold both raw and calculated vertices in memory, but also a matrix. The CPU is used to make calculations with the modelMatrix, which should be done on the GPU. This leads to
  1. more GC calls
  2. more CPU usage
• Proposed solution: Store raw vertex data on the GPU in batches. Renderable structures only save buffer ID, offset and length of data as well as the matrix. Once called to render, the matrix is pushed into the GPU and the batch renderer renders the vertices with the specified offset. This saves a) the memory/GC problem b) the matrix calculation provlem
• Disadvantages: This basically makes batched renderers unnecessary. Also, it is not quite sure what happens once certain vertices are not needed. However, one has to be reminded that every vertex buffer basically is used by the game, as data structures are static and do not change often.

Add an attribute called Required or something similar to rules. If the rule was not declared, then crash instantly with a useful exception.

Currently, the index of the documentation only shows the major headers. It would be nice to also see the other headers, which would improve general oversight of the documentation.

Marshal.Copy(data.Scan0 + scanline * stride, scan, 0, stride);

where scanline is 7, width and height is 8, stride is 128 and scan is a float[128].
So everything should be fine??

Right now, the algorithm to create the texture sheets is very unpolished and leaves large gaps of unused pixel data. This can be increased by smarter sorting of the textures, perhaps splitting the whole buffer into smaller pieces (e.g. 24x24px pieces and lower) and filling it up by taking the smallest available piece.

The savegame system is still a whole mess. For example, spells are not saved, weapons and states of some traits.
This could be improved by adding a save and load function for traits and use them to store relevant information.
Weapons would become a new section with standart information.

Relations between actors should be completed via the currently actorIDs stored in actors. IDs used in map saves should be replaced by those.

• Rename effects to spells
• To activate effects, use key combinations
• Improve tooltip usage
• Buy: Show description of spell

split from #1.

A few sketches of how the generation should look like. The debug output should also be almost the same.

• Pathgenerator
  Nodes are placed on the lowest values of the noise texture. One per side and optional ones in the center or at key points such as villages, entries and exits
  

• Terraingenerator
  A noise texture and a value range is given to select the area where the terrain should be generated.
  

• Structuregenerator
  A noise texture and a value range is given to determine areas where structure can be generated. Same with towns.
  

Noise textures can be selected via extra numbers, so multiple can exist and selected. They are always normalized from 0-1.

In debug, the noise texture is now shown as greyscale background, while the selected tiles are displayed in color.

Describe the feature you'd like
Add multiplayer support using servers and a architecture that allows to join midgame. Servers are included in the game itself.

Describe alternatives you've considered
If midgame-joining is not possible, use lobbies instead.

Additional context
See this WIP branch.

My current proposal is that commands are sent by the players to the server. The server gathers all commands in each tick, processes them and returns the new world state (more exact: the difference to the last one). This is also used if a new client wants to join: just send the current world state.

Downsides
It will make the code a lot more complex.

Rendering, Animation ticks and ticks need to be separated.

There are still a few questions open:

• What about local games?
• Latency problems: Without simulation, an average internet game will take up to ~100ms.
• What about poor client connections? The server would wait until the commands for the current tick arrive. This may not be the best idea. Instead, one could just assume that the client sent nothing and continue ticking. If the request comes a bit later, then process it in the corresponding tick. If the requests take too long, drop the client. However, this opens another can of worms: How do we determine the latency? What about missing world states? etc.

Workplan as follows:

1. Basics

• Rework weapon.cs and weapontype.cs
• Remove missile weapons
• Add 3D collision logic for weapons
• Never let weapons join physic sectors

2. Add/Rework the weapon types

• Add direct-hit weapon
• Rework bullet weapon to be more logical (e.g. cannon-like)

3. Aftermath

• Add possibility to highlight creatures when hit, possibly remove the damage counter will be dealt with in future
• Make attack animations possible
• Add pre- and post-hit delay
• Add smudgelayer

The categories are:

• Instant hit
• Bullet
• Beam
• Magic (like missiles, with more turbulence)

• Beams
• Shroud visibility

https://cdn.discordapp.com/attachments/510951309005029376/612925186961965085/unknown.png

After 3D-collisions are now a thing, it gets harder to target actors. A targeting system should be added to visualize the aimed target and to adjust the height of the target to make it easier to hit something again.

E.g. giving values from 1.0 to 0.0, between every number a distance like 1024.
This would look like this:

Falloff=1.0, 0.9, 0.1, 0.4, 0,3, 0.0

And falloff values ingame (with linear interpolation):