On linux, console applications have the ability to format their output. They can set font color, set background color and can place signs everywehre on the console. Using that it is, for example, possible to implement a tetris game right into the console.
I´m wondering how one can do that. I think they use a output markup language or something else. Can anyone tell me where I can learn more about this?
Thanks very much!
Most console applications involving a lot of motion or color are built using the ncurses library. Some very common examples would be irssi (IRC client), mc (Midnight Commander, the console file browser), mutt (POP3/IMAP mail client)
It seems like you are already aware of the escape codes used to modify console colors. A good list of console color escape sequences (for Bash) can be found here.
You obviously need to get a hold of those every-popular Unix video games, rogue, srogue, larn, hack, and/or nethack. They have a long and venerable history.
Notably, these all use the standard curses — or more recently, ncurses — library. Here’s a screen shot.
Since they have no joystick, motion is with vi commands. They are hands-down the very best way to hone your vi motion skills ever invented: no more two-finger typing for you! You stop thinking about motion; it just becomes a part of your fingers’ muscle memory. You really have to play them to get a feel for the awesome “Zen” state you can get into playing them:
After enough practice, it feels as though your fingers themselves remember how to play the piece. You don’t even watch them. They've a job to do, and once they’ve learned it, can go about that job remarkably free of direct supervision. The key to clearing the mind of the outside world, so that the program becomes the dominant reality, is what a musician would call “finger memory”. (You might have heard athletes or dancers refer to it as muscle memory, but when we’re talking about using the computer, it really is the fingers that count.)
[...] Of course, that's not really what’s going on; it only seems to be. Your fingers don’t really remember. But a part of your brain that controls them does, even though “you” don’t realize it. What’s happened is that you've so successfully assimilated the moves needed that conscious direction is no longer required. The little lighthouse keeper behind your forehead can worry about other things, assured that your fingers will do the job you’ve trained them to do. Your eyes are on the screen, the program in your head, and your head is in the program. Your fingers become an unnoticed extension of your will. [...]
[...] There’s no question that, for certain tasks, the keyboard is clearly the optimally efficient input device. Consider the game of rogue or one of its more recent incarnations. You wouldn’t want to use anything but a keyboard there. The command set is just too rich. Trying to play the game with a mouse‐and‐menu interface instead of a keyboard one would slow you down by at least two orders of magnitude.
The rogue family of video games are also notable for showing how to write a video game for a regular terminal like a vt100 or an xterm, which I believe is what you are looking for. I’d probably use a more modern language than C these days, but all the same principles still apply. Both Perl and Python have good interfaces to these standard libraries.
It's not so much a markup language as a series of escape sequences that trigger the terminal viewer to format in a certain way.
You can send ANSI escape sequences before your output to indicate that the following output should be a certain color, weight, background. You can also send sequences that jump the cursor to specific locations to continue writing output.
If you are going to do a full blown app you should consider using some library such as ncurses which makes these manageable.
Related
Motivation: I'm trying to write scripts which send keystrokes to the currently focused window. Right now I use xdotool, which lets me send raw keystrokes. However, I want the exact keystrokes to be a function of the current text around the input caret in the focused window.
Problem: Is there a generic way of reading the state of the text input caret -- both its current position as well as the text around it? Intuitively, I want the content of the current "text box" as well as the location of the cursor within that text box. Perhaps this is not possible in the general case, but is there a way of doing it which would work for emacs and firefox? I'm running Ubuntu Linux
Further motivation: due to a bad case of RSI I control my computer by voice rather than typing. This works by setting up voice-activated scripts that are triggered by saying different phrases. When dictating English prose, it would be helpful to automatically capitalize words at the beginning of sentences. This automatic capitalization can be accomplished by reading the characters immediately before the input caret, checking if they contain a period, and if so, capitalizing the start of the next phrase that I dictate by voice.
Thanks so much! If anybody can help me here, it would greatly increase my day-to-day accessibility.
Since there is no standard widget toolkit for X11, but only a buch of independently developed arbitrary toolkits, there is no generic way to implement this.
As far as X11 and tools operating on its level (like xdotool) is concerned, there's only windows of either the InputOutput variety (i.e. visible windows, that receive events and one can draw to) or the just Input which are invisible and only receive events. There are no further refined "widgets" so to speak. You get a pixel grid, which you can draw to.
Accessibility interfaces are the burden of the toolkits (or if you don't use a toolkit – then you're a badass – you, the developer), to implement: https://www.freedesktop.org/wiki/Accessibility/
The absolute generic way would be to take a screenshot of the currently focused window, employ a computer vision / machine learning based solution to identify the caret, then OCR the line of text around it. And to be honest, IMHO doing it that way would probably be a lot more reliable than hoping for the accessibility interfaces to be properly implemented.
I recently broke my finger and can now only type with my right hand. This has seriously impacted my typing speed. Since I write software for a living, this is a serious problem.
I have been doing some research, but haven't found a great solution yet. Here's what I've come up with:
Wacom tablet + hand writing recognition software. Is it possible to write code with hand writing recognition software?
one handed keyboards -- I have only found expensive (> $100) keyboards. These look like they have a steep learning curve.
one handed typing instructions: http://www.aboutonehandtyping.com/manualcompare.html. Does this really work?
What do the one handed coders out there use?
If you're a two-hand touch typist, the answer is a "mirrored" layout.
Mirroring lets you begin touch-typing with one hand almost immediately. Pretty crazy how easy it is. Based on the muscle memory you already have.
If you're typing with your right hand:
Type all right-hand keys normally.
Don't type left hand keys. Instead type the same motion (but mirrored) with your right hand.
So if you want to type:
"D" -> type "K" instead.
"W" -> type "O" instead.
"S" -> type "L" instead.
Same row of keyboard, same finger, same motion. Your muscle memory can already do this... kind of like how you're unable to pat your head and rub your belly at the same time. The wires in your brain are crossing somewhere.
Software to mirror the keyboard as described above:
Hold Spacebar to mirror:
Linux - MirrorBoard
Mac - Mirror-QWERTY
Windows - AutoHotkey version of Half-QWERTY Half-Keyboard
Predictive Text; Automatic Mirroring
Mac - One-Hand Keyboard
Windows - One-Hand Keyboard
Regarding one-handed keyboards, I've tried using a frogpad and found it ok for typing text, but unusable for coding. The symbols require several consecutive key presses and I found it impossible to use shortcuts reliably. It was too easy to hit the wrong key and get it stuck in the wrong mode.
Nobody has mentioned ENTI-key aka Coffee++ Layout yet? It is exactly designed for programming with one hand (left). And unlike qwerty, it is even optimized for speed and ergonomics. I used it some years ago for a short while and I don't know if it still works on newer systems. I think I used it for writing CSS: Typing the words with left, typing all those numbers on the numpad with right.
I can not recommend pen+handwriting. I usually use a tablet PC and handwriting code is terrible. I tried it on Windows 8 and Linux with Cellwriter, and both are not bad programs, but I still switch to onscreen keyboard whenever I can. But maybe the problem is my scratchy writing :)
I also can tell from experience that learning a new layout is not as complicated as it sounds. Especially if the layout is more logical than qwerty. I use Neo Layout since 10 years and getting the hang of it went smoothly, I was able to write a blog article after an evening of training.
"But what if you have to use qwerty on another PC?" This, also, is no problem, really. My simple trick is to never look at the keyboard when using Neo, but glimpse at it when qwerty-ing.
Good luck to anyone who wants to or has to use one hand for typing!
Now, the time to heal a broken finger will be shorter than it takes to adapt to one handed coding, not to mention the time it takes afterwards to get back to two-handed coding
Also, the time it takes to learn the methods is time you could've spend on coding (read: making a living).
Knowing this, we need a quick-fix, short term solution.
First of all, A good IDE, with code completion and similar functionality will help you a lot.
Secondly, use the shortcuts of the IDE, remember, there are Shift, Altand Ctrl keys on both sides of your keyboard.
(you might want to create a cheatsheet for those shortcuts)
In addition to helping you during your time with your injury, learning the shortcuts will also improve your coding speed when you're back up again.
Now, my comments on your proposals:
Don't, simply, Don't, it'll take even more time to fix writos (typos) beacause recognition will be flaky.
That learing curve will slow you down even more.
Won't even comment on that one...
Mirrorboard
A friend of mine broke his wrist snowboarding, and he had reasonable luck using speech recognition software (Nuance Dragon Naturally Speaking). It worked quite well for email and documentation, which would solve a part of your problem.
Another colleague, Nils Klarlund of AT&T, developed a version of emacs hooked into speech recognition. He even had a home-brewed set of foot pedals for doing shift, control, etc. He used this exclusively for years (due to bad carpal tunnel syndrome).
And maybe your feet can take up some of the burden. This is part of a parallel discussion going on in this question.
And off-topic, but extremely interesting, T.V. Raman, who's been blind since the age of 14, wrote a version of emacs that works with keyboard input and audio output. There's a chapter on it in Beautiful Code. I've seen him use it, and it's completely awesome. And of course emacs is a great interface for more than just text editing.
If you anticipate that your left hand will be out of commission for a long while, and if it's worthwhile for you to learn a new layout, then there exist one-handed Dvorak layouts.
There's some information at PC Guide: Single-Handed Dvorak Alphanumeric Layouts.
There also once was software for Qwerty Half Keyboards that used the space bar as an extra shift key that reversed the keyboard.
Good luck with your injury!
We have a developer in the office that lost mobility in his right hand and probably won't gain back full use of it. He has mainly learned to type well with his left hand and kind of fill in for his right hand. Although he lets his right hand kind of peck for things. He has gained enough speed back for it not to affect his day too greatly from what i can tell.
Only thing i can think of that might let you speed up some while typing with one hand and maybe being able to get a key or two with the other hand might be to use an IDE instead of text editor if you already don't, so you can use tab completion. Kind of a lame solution if you don't like IDEs or just don't have that option in your work environment but might help out a bit.
The same thing happened to me (I destroyed my left pinky). At the time, I didn't touch type, so my only use for my pinky was left-control, left-shift, and caps-lock.
This sounds as if it just happened to you. I promise you'll quickly learn to compensate. Remember, it's quality, not speed, that counts most.
Perhaps you should seize the opportunity and read to improve yourself as a programmer. Or spend some time debugging.
I consider myself somewhat familiar with Vim,
hate the arrow keys (let alone the mouse),
regularly look up tips and plugins to get the most out of this tool,
use it daily to manage my cloud servers, etc.
However, I always find myself doing the same mistakes probably inherited from the GUI-world:
too often switching to visual mode to see what piece of code I'm about to manipulate,
undoing changes to retrieve lost statements because I forget to utilize registers (and pasting code on temporary lines just to grab it after other edits),
relying on Ctrl-C & Ctrl-V when working with operating system's clipboard,
keep pressing j button to browse through lengthy files to find certain functions.
Probably my Hungarian keyboard layout prevents me from being faster as most of the special characters (/, [, etc.) are only available as a key combination (with Shift or Alt Gr).
Given this specific situation, what pieces of advice could you give me? Have you faced similar bad habits when you were a Vim-novice? I'd like to see my productivity skyrocket (who wouldn't?). Thanks in advance.
I've found a simple, effective strategy. Choose one action, one task or one set of keys that you think is unnecessarily slow. Figure out a better way of doing this using the vim manual or googling or a plugin etc. Force yourself to use this every time. Rinse, and repeat. The path to efficiency is one-by-one elimination of the slow parts.
I'd also recommend just reading the vim manual from time to time - even if you don't remember everything, knowing something's out there is very helpful.
This probably applies well beyond vim, but
something that worked for me was finding a specific feature that I knew would
be more efficient and concentrate on using that for a week or two.
Just one feature at a time, and possibly using it excessively.
After a couple of weeks it becomes automatic and you can move on to the
next thing.
I learn programming tricks the same way. eg. I'll have a month of using lambda expressions for everything, then a month of mapping and filtering.
(not on production code though)
Probably my Hungarian keyboard layout prevents me from being faster as most of the special > characters (/, [, etc.) are only available as a key combination (with Shift or Alt Gr).
I'm sitting in front of german keyboards all day long and know this problem very well. Some keyboard layouts are simply not very suited for programming / using vim. I think its safe to assume that most programming languages and keyboard shortcuts were designed with the us-layout in mind.
My advice: reset your keyboard layout to us-english and practive touch-typing on that layout (typing without looking at the keys). It won't matter that the keyboard labels are wrong and you'll be much more comfortable using vim hotkeys.
The only problem that still remains for me is to produce language specific characters (german umlauts such as ä,ö,ü) wich i assume will also be a problem for hungarian. For that I use a combination of vim-digraphs, linux window manager digraph-key and windows layout-switching hotkeys.
just keep using it. The more you use it, the better you become at it. VIM isn't too bad. The main thing is you just have to remember that it isn't always in edit mode.
I am in the process of developping a game, and after two months of work (not full time mind you), I have come to realise that our specs for the game are lacking a lot of details. I am not a professional game developper, this is only a hobby.
What I would like to receive help or advices for is this: What are the major components that you find in games, that have to be developped or already exists as librairies? The objective of this question is for me to be able to specify more game aspects.
Currently, we had specified pretty much only how we would work on the visual, completely forgetting everything about game logic (AI, Entities interactions, Quest logic (how do we decide whether or not a quest is completed)).
So far, I have found those points:
Physics (collision detection, actual forces, etc.)
AI (pathfinding, objectives, etc.)
Model management
Animation management
Scene management
Combat management
Inventory management
Camera (make sure not to render everything that is in the scene)
Heightmaps
Entities communication (Player with NPC, enemy, other players, etc)
Game state
Game state save system
In order to reduce the scope of this queston, I'd like it if you could specifically discuss aspects related to developping an RPG type of game. I will also point out that I am using XNA to develop this game, but I have almost no grasp of all the classes available yet (pretty much only using the Game component with some classes that are related to it such as GameTime, SpriteBatch, GraphicDeviceManager) but not much more.
You have a decent list, but you are missing storage (save load), text (text is important in RPGs : Unicode, font rendering), probably a macro system for text (something that replaces tokens like {player} with the player characters name), and most important of all content generation tools (map editor, chara editor, dialog editor) because RPGs need content (or auto generation tools if you need ). By the way have links to your work?
I do this exact stuff for a living so if you need more pointers perhaps I can help.
I don't know if this is any help, but I have been reading articles from http://www.gamasutra.com/ for many years.
I don't have a perfect set of tools from the beginning, but your list covers most of the usual trouble for RUNNING the game. But have you found out what each one of the items stands for? How much have you made already? "Inventory Management" sounds very heavy, but some games just need a simple "array" of objects. Takes an hour to program + some graphical integration (if you have your GUI Management done already).
How to start planning
When I develop games in my spare time, I usually get an idea because another game lacks this function/option. Then I start up what ever development tool I am currently using and try to see if I can make a prototype showing this idea. It's not always about fancy graphics, but most often it's more about finding out how to solve a certain problem. Green and red boxes will help you most of the way, but otherwise, use Google Images and do a quick search for prototype graphics. But remember that these images are probably copyrighted, so only use them for internal test purposes and to explain to your graphic artists what type of game/graphic you want to make.
Secondly, you'll find that you need to find/build tools to create the "maps/missions/quests" too. Today many develop their own "object script" where they can easily add new content/path to a game.
Many of the ideas we (my friends and I) have been testing started with a certain prototype of the interface, to see if its possible to generate that sort of screen output first. Then we build a quick'n'dirty map/level-editor that can supply us with test maps.
No game logic at this point, still figuring out if the game-engine in general is running.
My first game-algorithm problem
Back when I was in my teens I had a Commodore 64 and I was wondering, how do they sort 10 numbers in order for a Highscore? It took me quite a while to find a "scalable" way of doing this, but I learned a lot about programming too.
The second problem I found
How do I make a tank/cannon fire a bullet in the correct direction when I fly my helicopter around the screen?
I sat down and drew quick sketches of the actual problem, looked at the bullet lines, tried some theories of my own and found something that seemed to be working (by dividing and multiplying positions etc.) later on in school I discovered this to be more or less Pythagoras. LOL!
Years and many game attempts later
I played "Dune" and the later C&C + the new game Warcraft (v1/v2) - I remember it started to annoyed me how the lame AI worked. The path finding algorithms were frustrating for the player, I thought. They moved in direction of target position and then found a wall, but if the way was to complex, the object just stopped. Argh!
So I first sat with large amounts of paper, then I tried to draw certain scenarios where an "object" (tank/ork/soldier) would go from A to B and then suddenly there was a "structure" (building/other object) in the pathway - what then?
I learned about A-star pathfinding (after solving it first on my own in a similar way, then later reading about the reason for this working). A very "cpu heavy" way of finding a path, but I learned a lot from the process of "cracking this nut". These thoughts have helped me a lot developing other game algortimes over time.
So what I am saying is: I think you'll have to think more of:
How is the game to be played?
What does the user experience look like?
Why would the user want to come back to the game?
What requirements are needed? Broadband? 19" monitor with 1280x1024?
An RPG, yes - but will it be multi-user or single?
Do we need a fast network/server setup or do we need to develop a strong AI for the NPCs?
And much more...
I am not sure this is what you asked for, but I hope you can use it somehow?
There are hundreds of components needed to make a game, from time management to audio. You'll probably need to roll your own GUI, as native OS controls are very non-gamey. You will probably also need all kinds of tools to generate your worlds, exporters to convert models and textures into something suitable for your game etc.
I would strongly recommend that you start with one of the many free or cheap game engines that are out there. Loads of them come with the source code, so you can learn how they have been put together as you go.
When you think you are ready, you can start to replace parts of the engine you are using to better suit your needs.
I agree with Robert Gould's post , especially about tools and I'd also add
Scripting
Memory Management
Network - especially replication of game object states and match-making
oh and don't forget Localisation - particularly for text strings
Effects and effect timers (could be magical effects, could just be stuff like being stunned.)
Character professions, skills, spells (if that kind of game).
World creation tools, to make it easy for non-programmer builders.
Think about whether or not you want PvP. If so, you need to really think about how you're going to do your combat system and any limits you want on who can attack whom.
Equipment, "treasure", values of things and how you want to do the economy.
This is an older question, but IMHO now there is a better answer: use Unity (or something akin to it). It gives you 90% of what you need to make a game up front, so you can jump in and focus directly on the part you care about, which is the gameplay. When you run aground because there's something it doesn't do out of the box, you can usually find a resource in the Asset Store for free or cheap that will save you a lot of work.
I would also add that if you're not working on your game full-time, be mindful of the complexity and the time-frame of the task. If you'll try to integrate so many different frameworks into your RPG game, you can easily end up with several years worth of work; maybe it would be more advisable to start small and only develop the "core" of your game first and not bother about physics, for example. You could still add it in the second version.
I find the concept of the programmable, tiling, keyboard-focuessed window manager ion3 very appealing, but I think it takes some time to customize it to your needs until you can really evaluate this totally different UI-concept.
Therefore, I would like to read reviews of people who tried it for a longer time as environment for programming (in particular using emacs/gcc).
(The policies of the ion3-author concerning linux-distros are not easy to follow for me, but this should not be the point here...)
I use ion3 daily. It's a wonderful window manager. The tiling interface really enables you maximize real estate. Once you get it setup to your liking, it is much more efficient to navigate via the keyboard. Even moving applications between tiles isn't that hard once you get used to the tag/attach key sequence.
With ion3, Vimperator and the various shells I have open during the day -- I barely use the rodent.
The author's opinions aside -- a good resource for configuring/extending Ion to your liking can be found at:
Configuring and Extending Ion3 with Lua
I've been using Ion daily for nearly two years now. Good things:
Easy to use from the keyboard.
Handles multiple screens (Xinerama) very well (once you have the mod_xinerama plugin), especially as in my case the screens are different sizes.
Very predictable where windows will appear.
Splitting, resizing and moving windows is very easy.
Multiple, independent workspaces on each screen.
Very fast and reliable.
Bad things:
Too many different shortcuts. e.g. there are separate keys for moving to the next tab, next frame, next screen, and next workspace.
Applications that use lots of small windows together work really badly (e.g. the Gimp) because it maximises all of them on top of each other initially.
Sub-dialogs can cause trouble. Sometimes they open in a separate tab when you want them in the same tab, or sometimes the open in the same tab and take the focus when you want to continue interacting with the main window.
These things can probably be changed in the config files, but I haven't got around to it yet. Also, the actual C code is easy to read, and on the few occasions where I've wanted to fix something it has been very easy. I don't feel tempted to go back to a non-tiling WM, anyway.
I've used it off and on for the last few years, I think its a great window manager, but I keep crawling back to kde3 whatever I use.
Its however difficult to put into quantifiable terms why this happens, but its right up there with the gnome-vs-kde battle. Neither side can understand the other.
I would also just love to have kicker + ion3, but they don't gel awfully well.
Moving applications between tiles ( something I tend to do lots ) also is a bit inefficient ( too addicted to the mouse )
( Kicker + Evilwm is a good combination, but evilwm just can't handle stacking in a user-friendly way )