I'll be letting though certain keypresses in the future, and will only be blocking the alt key from hanging my app and such. It also blocks the Alt+F4 key combination and co.
The test of behaviour I tell is an input field, allowing to type letters of European languages like ü, ä, ą and so on. I’m quite disappointed when I can’t input something like „Łabądź” as a player name, but able to edit in memory or in save file.
One more thing I forgot to say. If default function of the alt key is to open menu, that it’s defined somewhere in your game, settings or the engine. If you try default loop in win32 api app with an empty window, alt key does nothing and you need actually bind it to change its behaviour to show menu. So I recommend to blame settings or an engine first before disabling events on so low level.
Also such way of disabling events would prevent you of porting your app to other OSes like Linux and macOS
You could start with a multiplayer server that handles the game logic, and a command line client that that can interact with it, create a game room and invite someone to it.
You can handle realtime communication with socket.io.
Once you have the client and some game rules, you can implement the client on a frontend using a canvas or game engine.
You could then add the bot opponents using simple random number generation and some basic strategies.
I think the command pattern would be useful. The user requests to perform a command. The command implementation can define preconditions and actions that mutate your game state.
Hi. I work at a conpany that makes digital card games.
Start by making the rules work. We generally use a callback implementation. We have a class that handles the game and enforces rules and dictates flow, classes that represent players, and then a rendering class.
The game will call relevant functions to prompt the players for an action, passing the game state with them. The players respond with what they want to do. The game calls the renderer to draw it out, and the renderer will then call the passed callback action. Repeat until the game is over.
When a human is involved then you just hook actions to buttons and pieces and clickable elements that the game catches and responds to if needed.
Really you can use any principle or design paradigm you want, but since you are making a "simple" turn based game just having it simple and well segmented is an easy way to keep a handle on it.
It's great to see the majority of workers paying for the mistakes of that big pricing fuckup that was approved by a minority of people in power. Just a normal day for capitalism, nothing to see here.
How do you expect a business to run? Every major business decision go to a vote? Or should a company that is bleeding cash not lay off anyone until the company shuts down and everyone is out of a job?
"If we don't do what they say they'll bring the entire economy to a halt, yes this is the best most flawless system imaginable" is definitely an objective and emotionless assessment and not ideological cowardice.
Yes, especially when you plan to fuck over all your existing customer base, as was the case here. A lot of Unity employees knew this was a major fuck up, and would have never went with the plan
Or should a company that is bleeding cash not lay off anyone until the company shuts down and everyone is out of a job?
Y. E. S.
This isnt as absurd as you think, its not the goddamn employees fault the execs suck ass. If there are performance issues from an employee that is different, but in general these moves are wholely driven by failure at the exec level.
I'd point you to godot but I'm pretty biased because I just really love godot.
I will say though that depending on the scope of the project you have planned, it might not be best to make your dream project your first one. Test the waters with a few really small games first, and then once you're comfortable and know your tools well enough do your big idea.
Godot is my goto engine for 2D and 2.5D stuff. It's fairly easy to pick up, it's free, and open source, and there's plenty or tutorials for it.
It uses GDscript which is a python like language, so it's not too difficult to learn. That's usually my recommendation to newbies.
But, I'd say try different things, and you'll figure out what you like personally. You may find something totally different suits your personal taste and interests best.
Definitely Godot, if you want a quick overview of it and or an introduction course it's very much worth checking out Brackeys on YT. He is an excellent teacher.
Unreal is heavy, and while you can make games without any coding knowledge, it's more for super fancy 3D games.
Unity and Godot are a bit simpler and more casual. Unity is ripe with issues and Godot is a little more immature. I would recommend Godot if you care about open source/community vibes, or Unity if you want more powerful features.
I wish there were better 2D or 2.5D dedicated engines, since imo most games don't require 3D to be cool, but I don't personally know any good ones (RIP Flash)
Thanks for the suggestions. I was initially looking at RPG Maker but when I saw that it can't really handle isometric views I was a bit put off it. Well, that and the price of it....
GameMaker is a pretty good 2D game engine. I used it up until Yoyo Games pushed me out by making it prohibitively expensive with the release of Studio - but from what I hear, they've recently reversed course on their pricing in a good way.
I originally learned how to write code using the (very easy to learn) drag and drop editor in GameMaker 6, and I'm now a professional software developer, so I guess it holds a special place in my heart, haha.
I have zero trust in Unity given recent events. In this case, I'd recommend Godot, unless OP is trying to build something that's intended for a large-scale/mass release.
Game Development
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.