1,157 karma · joined April 17, 2022
I'm creating Metropolis 1998, a 2D city builder/simulation video game.
https://store.steampowered.com/app/2287430/Metropolis_1998/
"He cited an example in which an AI model attempted to avoid being shut down by sending threatening internal emails to company executives (Science Net, June 24)" [0] Source is in Chinese.
Translated part: "Another risk is the potential for large-scale model out of control. With the capabilities of general artificial intelligence rapidly increasing, will humans still be able to control it? In his speech, Yao Qizhi cited an extreme example: a model, to avoid being shut down by a company, accessed the manager's internal emails and threatened the manager. This type of behavior has proven that AI is "overstepping its boundaries" and becoming increasingly dangerous."
This is my current opinion as a game developer. IMO this isn't going to be fun for most once the novelty wears off. Games are goal oriented at the end of the day and the great games are masterfully curated multi-disciplinary experiences. I'd argue throwing a game wrapper around an LLM is a new LLM experience, not a new game experience.
That way when people visit from the future, they dont get the most recent article
When adding an item, it gets added to the next unused vector element. The sorting range end offset gets updated.
Then it sorts (note you would actually need a custom sort since a PriorityQueue is a pair)
std::push_heap( vec.begin() + startOffset, vec.begin() + endOffset ) [1]
endOffset++; vec.insert( vec.begin() + endOffset, $value ); [1]
endOffset++; vec[endOffset] = $value; [1]
startOffset++;
It ended up being > 2x faster in debug build, but 2x-5x slower in the release build (??!!?) [1]. I haven't learned much about compilers/"lower level" C++, so I moved on at that point.
How it worked:
1.) The P.Q. created a vector and resized it to known bounds.
2.) The P.Q. kept tract of and updated the "active sorting range" each time an element was inserted or popped.
2B.) So each time an element is added, it uses the closest unused vector element and updates the ".end" range to sort
2C.) Each time an element was removed, it updated the ".start" range
3.) In theory this should have saved reallocation overhead.
[1] I believe Visual Studio uses -O0 for debug, and -O2 for release.
I dont think I am alone in saying this. IIRC the game was making millions while still in alpha.
It is possible to "pay what you'd like" on itch though :) [1]
The demo up there is in pre-alpha, but I push out a big update every 4-6 months.
Ha! That’s what I’m stuck with for Metropolis 1998. I have to use the ancient OpenGL fixed function pipeline (thankfully I discovered an AB extension function in the gl.h file that allows addition fields to be passed to the GPU).
I’m using SFML for the graphics framework which I think is OpenGL 1.x
Game to show what’s possible: https://store.steampowered.com/app/2287430/Metropolis_1998/
[1] https://x.com/SebastienBubeck/status/1970875019803910478
edit: full text
It's becoming increasingly clear that gpt5 can solve MINOR open math problems, those that would require a day/few days of a good PhD student. Ofc it's not a 100% guarantee, eg below gpt5 solves 3/5 optimization conjectures. Imo full impact of this has yet to be internalized...
I mostly understand what you're suggesting (I'd need to read up on how each individual algorithm works at a low level). It's true that most of the sprites would remain in the same order and in theory it would be worth looking into this (it may benefit low powered machines -> widen the potential market).
However, there are other limitations with the framework I'm using that make me pause. I'm using OpenGL and Vertex Buffer Objects (semi-dynamic Vertex Arrays, ie. a std::vector<> of vertex information that the GPU can store locally). When a vertex array is updated, the entire array must be resent to the GPU, or alternatively one can do individual range updates (which... are not working at the moment). There can be so many sprites on the screen that a full update would cause the FPS to drop (learned this by example). And since CPU -> GPU communication is so costly, I assume hundreds of individual updates would also drop the FPS.
With my custom depth maps for each sprite, the vertex array only needs to be sent once. (Side note: the world is broken into 40x40 chunks)
> If the only way to get topo sort to work is by treating the sprites as a fully connected graph, then it's not the right approach.
One trick the OpenRCT devs did was split the screen (or scene?) into 64 pixel wide vertical strips. Though they still said the performance was O(N^2) for each strip.
[1] I am content with the engines performance for now. Last I tested I, a very dense scene ran >165 FPS on a medium performance GPU.
The solution I went for was drawing a 3D box (in 2D space, i.e. in the sprite sheet over each sprite), and then using that box to calculate the local depth within the "diamond"/isometric space is occupies (er, hope that makes sense!)
It appears there are O(n log n) algorithms though, I just didnt come across them at the time :)
EDIT: Or maybe not! I dont have time to dig into this, but it may not be accurate enough
Im not sure that would work for my use case though, since you can see inside the buildings in my game (and there's see thru windows!). A bunch of high density buildings will be drawing tens of thousands of sprites within the camera's field of view.
For anyone who's interested, here's the scope of the problem:
Isometric projection is simulating a 3D world by layering 2D sprites in a specific order. Notably, units/vehicles in the game have smooth (floating point) movement, so they can be e.g. partially occluded by a wall or another object. My game also has pixel thin walls that can be placed on any edge of a tile.
So imagine sorting a vehicle sprite behind two wall sprites (the vehicle sprites are twice as wide) as it's moving across them. All you have are rectangles to work with. Now add in a stationary plant in front the wall, and a person walking in front of the plant, the two walls, and the vehicle.
e.g. There will be a time when the front the vehicle (the bottom of the rectangle sprite) is lower (i.e. closer to the camera) than a wall sprite, but the vehicle would still be occluded by the wall.
[1] https://mazebert.com/forum/news/isometric-depth-sorting--id7...
The roadmap has both early access and 1.0 goals. I just wrapped up terrain generation/modification, so all that's left is to add in the municipal services, funds, and prob. street parking. Then wrap up the overlays.
I'm the developer of Metropolis 1998. Unfortunately the launch date in the article has come and passed, but that's how things are in game development world. :D
Some tech talk:
- Custom engine (C++) using SFML for the graphics framework, and SQLite for database/data oriented design
- True isometric engine. No 3D models, everything you see is hand drawn sprites (made to look like a 3D render ha)
- Since sorting sprites is O(N^2), I figured out a way to create a depth map for each sprite to depth sort on the GPU
- Tons of work went into the pathing code to make it efficient, since this is the traditional bottleneck in these types of games. The game can handle around 100K units and vehicles moving around (on one CPU core)
- The team is just me and a couple part time contractors for the art and buildings.
- Most recent update (some cool skyscraper construction): https://x.com/YesboxStudios/status/1978928991663776224
- Fun fact: the entire game is currently 27 MB.
- Steam: https://store.steampowered.com/app/2287430/Metropolis_1998/
I've never smoked cigarettes, but decided to try Nicorette gum as an alternative to a second cup of coffee (if I drink after 12:00, I wont go to sleep on time).
I've been using it for 8+ years now and have found a sustainable dosage that doesn't give me withdrawal/depenency. I've never had an issue with tolerance.
I buy a big box of 4mg gum and go through around half to one piece a day. I discovered consuming 2+ pieces (+8mg) led to withdrawal symptoms (empathetic lightbulb moment for me for smokers who want to quit!)
Regarding dependency, I don't take any when Im traveling/on vacation, and have never felt the need to use it then.
Any desire comes from wanting to continue the alertness once the caffeine starts to wear off.
> The Zhemao hoaxes were over 200 interconnected Wikipedia articles about falsified aspects of medieval Russian history written from 2012 to 2022
Discussion at the time: https://news.ycombinator.com/item?id=31915937
I never asked them why they participated. But from observation they had great joy in hand crafting costume, weapons, and armor, then utilizing their craft to roleplay and battle. Maybe there’s something to be said about ownership.
I’d also hesitate to guess that the medieval time period was a time when most of the technology at the time could be understood and actively participated by the average person while simultaneously supporting a growing! civilization.
Now the average person undesirably participates in a no or low growth job where they have no agency in their day to day.
At the time, every umpire had their own strike box, and I loved it! It added variance to the pitches and swings each game. Some batters would turn their head and confirm with the umpire where one edge of the box was when they called a strike (and others would silently curse without turning their head haha)
It's (much) less work to obtain this info than other options (like walking to a store and buying a newspaper, or talking to your neighbor/friend, or doing a hobby instead).
That's my very quick take. Conserving energy once benefited us greatly, and now that feature is being used against us.
Go outside and interact with people.
There is enough “content” IRL or otherwise on this planet that is immeasurably beyond a single person experiencing that affords you the opportunity to choose the life you can live.
Teach yourself how to choose