Waterlimon

What was the game like btw?

Hmmm...

 

-Generate lower detail minimap for far away chunks, so that the detail goes down as you go farther from the center of the minimap.

 

-Only add lit areas to the minimap (if you have lighting of some sort), unless already visited or unless it would be visible anyways (low detail, oceans, rocky areas...)

 

-Compress the minimap near the edges. First you see people, then you see houses, then villages, then big cities(, then huge landscapes?) but all the same size. This might be difficult to pull off, but would be certainly interesting. Near youre interested in the small stuff, far youre interested in things like big cities, mountains etc.

Imagine like if it was a sphere, more land area near the edges.

 

-Allow making notes on the minimap (for example if you open it in some sort of big mode, you can draw a path to your destination, and that path is visible when its in minified mode. Its annoying in many games how you need to keep the big map open all the time to find your way to some remote location)

 

-Only add a very low detail minimap that shows oceans / mountains (if you have height) / different types of land, and allow people to make their own markings there (here be ore, here be home, here be evil monstar)

I would, in each window, store a index to the window in front of it.

 

W1

v

 

W2

v

 

W3

 

So if you were to click on W2, you should swap the index of W2 and W3, and make W1 point to W3

 

W1

v

 

W3

v

 

W2

 

 

So its kind of a linked list. If you make it doubly linked (indices to the other dir. too) you could start from the topmost window (perhaps always store the top window index somewhere) and stop on the first window which the mouse is on top of to find the window you click.

 

If you want to use the same system for buttons and stuff, i would make each of those W's able to contain many same-depth elements (eg. buttons on the same window)

 

I suggest you also google for how to handle this.

 

EDIT:

Another way to handle it would be to have a separate list which contains indices to the list of the windows in depth order. This way you dont need the windows to know about their depth.

 

So

-List of windows

-List of indices to windows, in depth order

 

To move a window in depth, you just remove the index, move all the indices above down by 1, and place it at the top. However this requires you to find the window from the depth sorted list first, but if you just used the depth list to find which window you clicked on, you should have that information available.

Or you could simply store the time when the grass was created, and deduce the growth/age from that using the current time.

 

 

If you do some action on the tile that affects its growth you might want to reset its age and set its growth to what it was + the effect.

 

So:

 

T (age=5, lastGrowth=0)

*hit grass*

T (age=0, lastGrowth=5) //what the growth would be after age 5

T (age=0, lastGrowth=4) //reduce effect of hit

*time passes*

T (age=1, lastGrowth=4)

 

EDIT:

nowait, age should be "created", holding the game time at the time of the last update of the grass tile.

Add more dynamic things - water, ice, fire, crawling goo of dynamicismism - so you dont feel bad for looping through everything

 

Lets say by average grass needs to be updated every 4 mins.

 

You could do this:

 

Have different containers for grass tiles, 4 mins, 2 mins, 1 min, 30 sec... and so on (stop at some point)

 

After update of a tile, it goes to 4 min container with (4 + time since 4 min container was last updated) minutes of time.

 

When you update a container (tiles only updated when they reach 0 time!), you reduce the time of the below container (2 mins for 4 min container) from each tile in it, and move it to the container below.

 

4 min container could be the world. Everything else could be a list of tiles. That means you loop thru the world every 2 mins.

 

The last container needs to be checked at whatever update resolution you want (every 1 second, every 15 second...)

 

something like

 

a) World (4 min) (half of all tiles here)

b) List (2 min) (fourth of all tiles here)

c) List (1 min) (eighth of all tiles here)

d) List (30 secs) (eighth of all tiles here) --check this lets say every 5 secs, reducing 5 sec from everything. If something goes below 0, (lets say -3), you add it to the 4 min container with time (4 minutes - that 3 seconds + time since last time the 4 min container was updated)

 

*might contain logical errors*

 

 

That seems somewhat reasonable at least. You can vary the amount of the containers. I would keep times half of the above time, seems optimal. Now, if you have a resolution of 5 secs, instead of updating ALL tiles by looping thru the whole world every 5 secs, you can loop thru the world every 2 minutes, and loop thru only a small part of the tiles every 5 secs.

 

If someone understand this, please come up with an O() thingy because it looks like it contains a log or something else cool.

 

EDIT:

Wait this doesnt make any sense. Forget all about moving tiles back to the 4 min container, unless they happen to die and start growing again

You could put the torch outside the cell, have a guard sit guarding nearby (sleeping?)

Then you lasso the torch to set the guard on fire and hope he stops somewhere near a cell.

Cute kittens taught to stare the enemy in the eyes, duh.

UI stuff (menus and controls of various kinds, state machines, all kinds of input and how to handle it)

Trees of all sorts (for searching, efficient storage of sparse data... a tutorial for a tree that doesnt use pointers everywhere would be nice)

Interpolation/extrapolation (basic stuff, SLERP, using quaternions to interpolate matrices...)

Procedural generation of content (noise of all sorts and how to combine it to get results)

Basic game code architectures (for projects of different types and sizes, to give an idea of how to organize all that code and data)

Source version control (or whatever its called, different ways to do it from USB sticks to the actual ones)

How to keep code error free (simple stuff like logging or asserts or watever)

How to represent objects in code (creatures, buildings, inventory items...)

How to make a save system/replay system/undo-redo system

How to make effects that apply for some time (spells, power ups)

How to format your resources (images, settings, whatever, file or embedded in code etc.)

How to do multiplayer/solve the latency problems (simple, lets say firing a fun or shooting with a minigun or throwing a bomb)

How to repair your time step

How to make remappable keys

How to make an awesome multiplayer infinite millimeter resolution voxel world that supports 8999 players

Path finding algorithms (A*, navmesh (3D navmesh for spaceships? :<), laggy raycasting based thing that never works properly)

Ways to implement AI

Or you could just add perspective even if its top down.

 

So a building at the center will only show the roof, but the buildings at the sides will show their walls.

Are you binding the fragment color output to be used as the out color? Probably worls without but just to be sure.

Its something like glBindFragColorLocation

Its feasible, but you might want to consider a few things:

-Since you want a flat-ish object, using an octree isnt probably the best choice. Consider using a quadtree or multiple octrees. (An octree does work though, and is likely simpler than some hybrid solution in case you want to be able to have a floating island 10 km in the air)

 

-You should consider not making the leaf nodes so small. If possible, have the leaf nodes be regular grids of tiles/voxels. This is because if the size of the node related data is large compared to the actual tile/voxel data, being able to not store a single tile wont be very useful because there will be a lot more data because of the nodes. (For example if you have 1 byte tiles/voxels, and the node is 64 bytes, it doesnt make sense to make each leaf node contain 1 tile if you can instead have them contain a 16*16 grid of tiles)

Especially since your tree will likely just represent a big sphere/circle, the savings from having little tiles/leaf are small in terms of memory usage.

Moved all of my resource owning classes to use move semantics, prevented use of copy ctor and assignment operators (should probably implement those so they actually copy the resource for the few classes where it makes sense...) and used a lot of std::move, and it finally works properly with whole program optimization too.

IIRC there was also a requirement for texture sizes to be divisible by 4 (so width needs to be divisible by 4)

 

I couldnt find much information by googling, it might only apply to compressed textures.

As i dont have much practical experience with c++ yet, i tend to:
1.Design system that is able to do everything required
2.Implement (or start to)
3.Fix design to make it simpler, cleaner and.more flexible
4.Reimplement/modify based on new fixed design

Though i dont make the details perfect (like optimization unless its relatively easy and i know exactly how to), just trying to get the overall design work.

= should be ==? or is that just an error in your post?

Maybe you should post the full code i cant see anything wrong with the current one apart from the syntax errors...