|
surt
|
|
« Reply #1 on: February 16, 2017, 11:05:51 PM » |
|
Had a quick fiddle in linux. Runs smoothly and looks great. Found it somewhat awkward that the buttons in the top right of the screen preventing edge-scroll.
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #2 on: February 17, 2017, 05:31:32 AM » |
|
Thanks for trying it! Good to know it works on Linux.
The button/scrolling thing is tricky to get right - the buttons needs to be easily available, and it's annoying for the map to scroll when you're just trying to open the editor, but the scrolling dead zone can be annoying too. Maybe I'll think of a solution eventually...
|
|
|
Logged
|
|
|
|
zugz
|
|
« Reply #3 on: February 24, 2017, 10:49:29 PM » |
|
Very nice!
To get it to compile on gentoo linux, I had to manually link with -lm and -lallegro_foo for various values of foo.
On a 1024x768 sreen, the help text in the design tab flows off the screen, and in-game text editor shows too few columns to be usable. I'd suggest having the rightmost tab take up more of the width of the screen than it does.
If I select 'custom game' from the main menu, everything slows to a 0.2fps crawl until I quit the game.
It would be very nice to be able to rebind keys by name rather than keycode, at least for alphanumerics.
As for the game itself: I've played only the first three levels and fiddled about a bit with the designer. It all seems pretty smooth. The design interface was slightly confusing at first, particularly with the role of uplinks and downlinks, but became clear after a little experimentation.
I haven't really experimented with the coding aspect. It looks feasible and plausibly fun, but pretty daunting! I don't see any documentation of the 'auto classes' or the basic functions like scan_for_threat() - is the idea that you figure these out from the few samples provided, or are you meant to sourcedive into the actual game source?
In principle, designing and on-the-fly adapting an RTS AI does sound like a lot of fun (though probably a pretty niche kind of fun!).
One thing - since you already seem to have set up the graphics structure to allow arbitrary zoom, it would be very nice to be able to zoom out arbitrarily far in the main game screen. I think it would make for a more intuitively fluid way of navigating the map than using the minimap.
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #4 on: February 25, 2017, 02:31:21 AM » |
|
Thanks for your detailed comments! On a 1024x768 sreen, the help text in the design tab flows off the screen, and in-game text editor shows too few columns to be usable. I'd suggest having the rightmost tab take up more of the width of the screen than it does. You can resize the panels! (except the template panel) Move the mouse over the edge and the cursor turns into a pair of arrows, which you can drag left and right. If I select 'custom game' from the main menu, everything slows to a 0.2fps crawl until I quit the game. This shouldn't be happening! I'll see if I can work out what's going wrong here - most likely it's some kind of memory error that doesn't cause problems on my Windows setup but does on systems with less forgiving memory management. It would be very nice to be able to rebind keys by name rather than keycode, at least for alphanumerics. I do see what you mean, but the key rebinding is mostly there for people who use non-QWERTY keyboards. Adding key names wouldn't work for them (because there are so many keyboard layouts out there that I couldn't match the names to the codes for all of them), and would probably cause more confusion. As for the game itself: I've played only the first three levels and fiddled about a bit with the designer. It all seems pretty smooth. The design interface was slightly confusing at first, particularly with the role of uplinks and downlinks, but became clear after a little experimentation. I've been meaning to make the way uplinks/downlinks work a bit clearer. I should do that. I haven't really experimented with the coding aspect. It looks feasible and plausibly fun, but pretty daunting! I don't see any documentation of the 'auto classes' or the basic functions like scan_for_threat() - is the idea that you figure these out from the few samples provided, or are you meant to sourcedive into the actual game source? The manual has details of all of the functions, and right-clicking on a keyword in the editor gives a quick description of what it does, the parameters it takes and its return value. I should add a hint about this somewhere, though, because you're right that it's not obvious. In principle, designing and on-the-fly adapting an RTS AI does sound like a lot of fun (though probably a pretty niche kind of fun!). I hope so! One thing - since you already seem to have set up the graphics structure to allow arbitrary zoom, it would be very nice to be able to zoom out arbitrarily far in the main game screen. I think it would make for a more intuitively fluid way of navigating the map than using the minimap. This is a perennial problem for designers of RTSs and similar games - most players prefer to play at a zoom level that lets them see as much of the battlefield as possible, but if it's too far out they don't see the graphics. The current zoom levels are my attempt at a compromise. However, at the moment they don't deal very well with lower resolutions like 1024x768, and I need to fix that.
|
|
|
Logged
|
|
|
|
zugz
|
|
« Reply #5 on: February 25, 2017, 12:23:34 PM » |
|
You can resize the panels! (except the template panel)
So you can. That does help! It's still a little painful to have to resize every time I bring up a new tab - would be nice to have it remember the width you've set for the nth panel. The manual has details of all of the functions
Aha, I entirely missed the existence of the manual! It does the job well. The current zoom levels are my attempt at a compromise.
I experimented with allowing view.zoom_level=1, but at least on my machine it isn't actually usable - I get 2-4fps. So probably it's best to keep it as it is. I played around a bit more, and have a few more comments. I tried to remap the control groups (I use a dvorak keyboard, for which the defaults are horrible), but couldn't get it to work. I'm finding it quite annoying that the map scrolls when I try to select the buttons in the top-right for the tabs. I'm not sure what to do about it though... maybe move the buttons to just above the minimap when the main view is in focus, and hope it isn't too confusing that they pop up to the top-right once selected? Assigning keys to them (e.g. F6-F10) could also help. I believe %d is rather more common that %i as a printf escape for an integer. I found that auto_move() doesn't handle unusual configurations of thrusters - I tried having two pointing in opposite directions, and auto_move() just fired them both at once, leading to plenty of spin but no travel... I found the in-game text editor pretty painful to use, without features like autoindent and keyboard-only navigation beyond arrow keys. But I don't suggest you reimplement a proper programmer's editor, and I can see it does make sense to have some kind of editor in there, if only to teach the player that there is code for them to play with. So the only thing I'd suggest is a quick way to fire up an external editor on a process source file (using $EDITOR on *nix). Anyway, I'm generally pretty impressed with the project. It's a really unique game, solidly implemented. Good luck with the final polishing!
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #6 on: February 25, 2017, 08:41:16 PM » |
|
It's still a little painful to have to resize every time I bring up a new tab - would be nice to have it remember the width you've set for the nth panel. It remembers the width for each specific panel, so if e.g. you resize the editor panel, the editor panel will stay the same width regardless of its position (although it doesn't save this to disk). This seemed like the best way to me. Aha, I entirely missed the existence of the manual! It does the job well. I've made it so when you start a game, the log (at the bottom of the display/editor panels) mentions the right-click help and the manual. I experimented with allowing view.zoom_level=1, but at least on my machine it isn't actually usable - I get 2-4fps. So probably it's best to keep it as it is. I've changed the zoom to be less dependent on resolution - now it tries to fit the same amount of vertical battlefield space on the screen, regardless of resolution. The way it worked before was a bit broken. It should be much more playable on a 1024x768 screen now. I tried to remap the control groups (I use a dvorak keyboard, for which the defaults are horrible), but couldn't get it to work. Hm, unfortunately I don't have access to a dvorak keyboard, so I can't test this I'm finding it quite annoying that the map scrolls when I try to select the buttons in the top-right for the tabs. I'm not sure what to do about it though... maybe move the buttons to just above the minimap when the main view is in focus, and hope it isn't too confusing that they pop up to the top-right once selected? Assigning keys to them (e.g. F6-F10) could also help. I think there needs to be a way of manually hiding the buttons when all panels are closed, so that they don't interfere with scrolling. I'm thinking of adding a new button which does this. The function key idea is a good one, too. I haven't generally put as much thought into keyboard shortcuts as I should have. I believe %d is rather more common that %i as a printf escape for an integer. It is? I'll look into this and allow both if the code I need to change isn't too tangled (it's a while since I looked at that part of the compiler). I found that auto_move() doesn't handle unusual configurations of thrusters - I tried having two pointing in opposite directions, and auto_move() just fired them both at once, leading to plenty of spin but no travel... The move methods should deal with most configurations. But if there are only two thrusters, pointing in opposite directions, it may be that there's no simple way to use them to travel as they both probably produce too much spin. I found the in-game text editor pretty painful to use, without features like autoindent and keyboard-only navigation beyond arrow keys. But I don't suggest you reimplement a proper programmer's editor, and I can see it does make sense to have some kind of editor in there, if only to teach the player that there is code for them to play with. So the only thing I'd suggest is a quick way to fire up an external editor on a process source file (using $EDITOR on *nix). Yeah, it's meant to be basically functional, but more complex IDE features are beyond it (and probably beyond my ability to implement!) It would be good to have a way to open files in an external editor, but I think I would need someone else to code that as I don't have any way of testing those kinds of *nix things on Windows. Anyway, I'm generally pretty impressed with the project. It's a really unique game, solidly implemented. Good luck with the final polishing! Thanks! I appreciate the detailed feedback! Also, I've removed some unnecessary code from the custom game setup menu, so hopefully the slowdown bug you experienced is no longer there.
|
|
|
Logged
|
|
|
|
zugz
|
|
« Reply #7 on: February 26, 2017, 06:54:23 AM » |
|
Thanks for the update. The changes all helped, including eliminating the slowdown. I think there needs to be a way of manually hiding the buttons when all panels are closed, so that they don't interfere with scrolling. I'm thinking of adding a new button which does this.
Actually what I think might be nicest is to have a simple toggle between having just the main game screen visible and having other tabs open too. Then you can place the toggle somewhere away from the scroll border, and it means that the choice of which tabs to have open can be saved - so with one click/keypress you can bring back whatever tabs you had open when you were last working on something. The function key idea is a good one, too. I haven't generally put as much thought into keyboard shortcuts as I should have.
More would be better! I'd also like keyboard commands in the editor for compiling and for loading and saving. The move methods should deal with most configurations. But if there are only two thrusters, pointing in opposite directions, it may be that there's no simple way to use them to travel as they both probably produce too much spin.
Yeah, it seems auto_move prioritising turning to face the target over accelerating towards it. That makes sense for many configurations, but not for all. But maybe it's fine to let the player do the coding if they want unconventional movement. It would be good to have a way to open files in an external editor, but I think I would need someone else to code that as I don't have any way of testing those kinds of *nix things on Windows.
Actually, more important than opening an external editor is getting easy access to what it saves. A "reload" command which doesn't make you locate the source file every time would be great. So would be the ability to load files for locked templates when the header hasn't changed.
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #8 on: February 27, 2017, 03:59:15 AM » |
|
Actually what I think might be nicest is to have a simple toggle between having just the main game screen visible and having other tabs open too. Then you can place the toggle somewhere away from the scroll border, and it means that the choice of which tabs to have open can be saved - so with one click/keypress you can bring back whatever tabs you had open when you were last working on something. Ah, I understand. I'll see what I can do But maybe it's fine to let the player do the coding if they want unconventional movement. Yeah, that's the plan. The autocoder and many of the higher-level methods (like .move_to()) are meant to be good enough for most situations, but they still leave plenty of scope for players to optimise process behaviour. This is tied into what I've always meant to be the ultimate purpose of the game, which is the autonomous-mode programming-game multiplayer. Although I don't know if anyone will ever actually play it like this! A "reload" command which doesn't make you locate the source file every time would be great. So would be the ability to load files for locked templates when the header hasn't changed. I can see how these would be useful, and they shouldn't be hard to implement (the second would just require disabling the check that prevents it).
|
|
|
Logged
|
|
|
|
zugz
|
|
« Reply #9 on: February 28, 2017, 09:42:23 AM » |
|
Cool, I look forward to the next update.
I can definitely imagine the autonomous mode getting some interest... maybe (eventually) you could set up an automatic weekly tournament, where players mail in the latest version of their template, they play each other, and the results are announced. Could be fun!
A few more niggles and suggestions:
The in-game text editor regularly drops characters when I type, I guess because I type faster than 1 key per frame. I don't know if allegro has an event buffer like SDL does, but if so that would be more appropriate than just checking for what key is being held down.
I guess this is again because I'm using a lower resolution than you test with, but for me the minimap hides most of the component information dialogue. Maybe the minimap could float over leftwards when it needs to?
I wonder whether it would make sense to support some C preprocessor statements - maybe just #include, #define, and #ifdef. Of course players can run cpp themselves to generate source files to be read by the game, but it'd be easier if it was directly supported. This would make it much easier to develop and maintain interdependent processes - which if you want autonomous mode to be a big part of the game, seems important.
It could even makes sense to have a single editable master autocode file, with the autocode function on the design screen just setting some #defines according to the objects on the process and the chosen AI behaviour, made use of by #ifdefs in the autocode file. That way autocode would stay useful even when you find you want to customise the details.
One last thing: I experimented with messages, and found that check_messages() seems to always returns a positive number even when no message had been received, contrary to the docs.
|
|
|
Logged
|
|
|
|
zugz
|
|
« Reply #10 on: February 28, 2017, 12:55:48 PM » |
|
Another little thing to add to the wishlist: a way to quit a game which doesn't exit the whole program.
|
|
|
Logged
|
|
|
|
michaelplzno
|
|
« Reply #11 on: February 28, 2017, 12:58:40 PM » |
|
The trailer could use some work. Edit it down and focus a bit more on the editor and other RTS features IMO.
Also, the background, while cool, kind of distracts from the foreground because both the background and foreground use a sort of hexagon shape. If the BG were circles in a grid rather than hexes that would make the difference between FG and BG more pronounced and easier to parse visually.
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #12 on: March 01, 2017, 03:29:00 AM » |
|
Another little thing to add to the wishlist: a way to quit a game which doesn't exit the whole program.
If you open the System panel (Sy) you get a quit button that exits the game without exiting the program. I can definitely imagine the autonomous mode getting some interest... maybe (eventually) you could set up an automatic weekly tournament, where players mail in the latest version of their template, they play each other, and the results are announced. Could be fun! I'd love to do something like that! One day. The in-game text editor regularly drops characters when I type, I guess because I type faster than 1 key per frame. I don't know if allegro has an event buffer like SDL does, but if so that would be more appropriate than just checking for what key is being held down. Allegro does have an event buffer, but I was using it in a really stupid way. Changing a while to an if fixed this problem (which I never really encountered because I don't type all that quickly). I guess this is again because I'm using a lower resolution than you test with, but for me the minimap hides most of the component information dialogue. Maybe the minimap could float over leftwards when it needs to? Moving the minimap might cause other problems, but it might make sense to move the component information. Since you can minimise it (the X button at the top of the component information box) I'm not too worried about it taking up screen space. I wonder whether it would make sense to support some C preprocessor statements - maybe just #include, #define, and #ifdef. Of course players can run cpp themselves to generate source files to be read by the game, but it'd be easier if it was directly supported. This would make it much easier to develop and maintain interdependent processes - which if you want autonomous mode to be a big part of the game, seems important. Yeah, I'd like to add at least #define and #ifdef. #include is a bit trickier; I wrote a much more comprehensive compiler for the proto-version of this game (Invincible Countermeasure) and getting #include to work properly was quite difficult (unfortunately that compiler was an unmaintainable mess inside, so I scrapped it when I changed from IC to LC). One possibility that would avoid needing to load #included files from disk each time the compiler is called may be to add a special header template, with #defines and enums and maybe subroutines, that the other source files can include at the start. I'll keep it in mind! It could even makes sense to have a single editable master autocode file, with the autocode function on the design screen just setting some #defines according to the objects on the process and the chosen AI behaviour, made use of by #ifdefs in the autocode file. That way autocode would stay useful even when you find you want to customise the details. Yes, a more advanced autocoder is on my to-do list. One last thing: I experimented with messages, and found that check_messages() seems to always returns a positive number even when no message had been received, contrary to the docs. You're right, it was broken. Fixed. Also, I'll update the manual to better explain how to read messages (including an example of the recommended way of using a while(next_message()) loop to read messages one by one). Just updated the github repository with these fixes.
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #13 on: March 01, 2017, 04:28:20 AM » |
|
The trailer could use some work. Edit it down and focus a bit more on the editor and other RTS features IMO. The idea of that trailer is to give an impression of the game's theme and what the action looks like, while showing just enough of the RTS/editor stuff to convey what kind of game it is. I'm going to record a longer, more gameplay-focussed video at some point before the final release, though (after I've sorted out some final interface stuff). Also, the background, while cool, kind of distracts from the foreground because both the background and foreground use a sort of hexagon shape. If the BG were circles in a grid rather than hexes that would make the difference between FG and BG more pronounced and easier to parse visually. Hm... is it really that hard to tell the FG from the BG? I've been looking at the game so long that it's hard for me to know. If it is, one solution is to use the colour switching options in init.txt to change the process colours to something with more contrast. I'd prefer to avoid circles, as they require a larger vertex buffer and take longer to render. Anyway, thanks for trying it!
|
|
|
Logged
|
|
|
|
zugz
|
|
« Reply #14 on: March 02, 2017, 09:55:09 AM » |
|
Thanks, the update helped. The editor now processes my keystrokes fine. I like the new position of the buttons on the main map screen, but there's still a slight problem in the other direction: hitting the 'X' to get *back* to the main screen leaves the mouse in position to scroll. This is quite annoying and disorienting. I'm not sure what should be done about it - perhaps just a special case for this situation that the pointer is in the scroll border when the map is shown, making the map scroll only once the pointer leaves the border then re-enters it.
The component box placement is fine, and thanks to the alpha blending doesn't seriously get in the way. I think it would be worth allowing it to be closed without closing the process box too, though.
As a datapoint: I had no problem differentiating foreground from background.
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #15 on: March 02, 2017, 07:27:39 PM » |
|
Just updated the repository. Changes:
- closing all panels (or closing the last open panel) now blocks mouse scrolling until the mouse moves away, as zugz suggested. A temporary interface thing shows up when scrolling is blocked.
- there are now a few more keyboard shortcuts: ctrl-s to save, ctrl-a to save all, f8 to test compile, f9 to compile. These are indicated in the editor menus.
- I tried to implement ctrl-o to open a file, but ran into some problems with the way Allegro's keyboard routines work when opening a file dialogue box. There's a workaround in the latest unstable version of Allegro 5, but I'm using a stable version. I'll try to fix this sometime.
- there's a new "reload" function in the "File" editor menu. It reloads the current file from disk.
- it's now possible to load source code into a locked template.
... and a few minor issues fixed.
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #16 on: March 03, 2017, 08:43:21 PM » |
|
A new video with plenty of RTS gameplay, playing a mission from the start: harvesting, expanding, defending, and designing new processes and sending them into battle.
|
|
|
Logged
|
|
|
|
zugz
|
|
« Reply #17 on: March 04, 2017, 02:24:16 AM » |
|
- closing all panels (or closing the last open panel) now blocks mouse scrolling until the mouse moves away, as zugz suggested.
Great. One little problem though - when an editor tab is open, moving the mouse to the very top-right corner leads to the main map scrolling. - there's a new "reload" function in the "File" editor menu. It reloads the current file from disk.
Good stuff. How about a keyboard shortcut for it (^R?)?
|
|
|
Logged
|
|
|
|
linley
|
|
« Reply #18 on: March 04, 2017, 03:40:38 AM » |
|
Great. One little problem though - when an editor tab is open, moving the mouse to the very top-right corner leads to the main map scrolling. I haven't been able to reproduce this, but I can see how it could happen if the Allegro mouse routines are reporting the mouse's position as equal to or greater than the maximum size of the display - this appears to be impossible on my system but may happen on yours. I've added a check for this which will hopefully fix the problem. Good stuff. How about a keyboard shortcut for it (^R?)? I considered this earlier but decided not to add it, to avoid having a single keyboard shortcut that could overwrite all changes to a source file. But it's simple to add so I've put it in as a compile-time option - if you define RELOAD_KEYBOARD_SHORTCUT (or uncomment the #define for it at about line 170 of e_editor.c) it will be available. Just updated the repository. Hopefully the next update will be version 1.0!
|
|
« Last Edit: March 04, 2017, 04:20:45 AM by linley »
|
Logged
|
|
|
|
zugz
|
|
« Reply #19 on: March 08, 2017, 09:32:25 AM » |
|
Great. One little problem though - when an editor tab is open, moving the mouse to the very top-right corner leads to the main map scrolling. I've added a check for this which will hopefully fix the problem. It did! But the big commit on Wednesday (2348adf1), though it included some nice things, seems to have broken things a bit for me. The game now runs really slowly. The game rate seems to be scaling with fps, which it seemed not to be before. I get about 12-15fps when not much is going on, which translates to a painfully slow gamerate. If I turn off the background (thanks for that option!) I get 30 fps and a decent gamerate. Couple of other things I forgot to mention before (not affected by this update): When any of the 'skip' options are in effect, the game runs faster as you'd expect, but scrolling the map is paradoxically much slower then normal. I wonder if it would make sense to make the build queue a bit cleverer. Currently it waits for the builder of the job at the front of the queue to finish recycling, even if it would be possible to start a job further down in the queue immediately. It took me a while even to realise that recycling was per-builder rather than global, and realising it made my operations much more efficient - but more fiddly.
|
|
|
Logged
|
|
|
|
|