Nice graphical update. There were some issues with how the snake is drawn, but seeing the snake twist and turn is very nice.

My high score was 3150 for a normal run, and 9950 for the run where I somehow became invincible through the levels, and decided to quit after getting a lot of points :- ). I tried to reproduce it but didn't succeed.

There are still some bugs here and there, but they are pretty rare, and I never encountered any crashes.

About the Intellisense style syntax checking, I don't have much experience with Visual Studio. I personally like error highlighting and auto-completion, though I don't find them absolutely necessary. Given that different people have different tastes in regards to those features, I think it would be a good idea to make it easy to turn them on and off.

The new additions are in general very nice, it is easy to tell the difference between turrets and blocks now (and the turrets look nice), and wrapping around is very nice. I am not certain what the yellow pulse means. Is it purely a graphical effect, or does it indicate something?

I sometimes lost lives/lost between levels. It would be nice if the turrets do not shoot for a little while at the snake after a life has been lost, just like when a level starts. On some levels, there were eye power-ups, and in some there weren't. The shots can be difficult to see when they fade out, which is bothersome given that it seems that they can still kill the player.

Overall, the game can be quite challenging, which is very nice. I don't know what my best score is for this version, given that I kept replaying after dying :- ).

I pushed a commit earlier that should fix the issue with .bmp loading. gra, did it fix the problem?

In regards to loading .png, couldn't we use an existing image library to handle .pngs? That way, we ought to also be able to load other image formats easily. And in order to avoid making binaries larger than necessary, we could provide it as a non-default extension.

Working on both an IDE as well as an image editor seems very ambitious, but I believe that is ok, since we already have a working IDE, which means that we will not be stuck in the meantime without an IDE while wxENIGMA is developed.

In regards to version control systems, I know that git have some support for working with the zip format (see http://tante.cc/2010/06/23/managing-zip-based-file-formats-in-git/), though I have not tried it myself. So given that the zipped EGMs are based on folders and text internally, zipped EGMs could be used in version control, as long as the IDE still reacts to changes in the zipped EGM.

In regards to the logos: Given that ENIGMA can be used with both LateralGM and wxENIGMA, and LateralGM can also be used separately from ENIGMA to edit GM sources, I think it would be difficult to clearly determine what is and what is not a part of the whole development environment. LateralGM is not necessarily a part of the core, even though it can be used with it, since it can also be used separately from ENIGMA. So I don't think that it would make sense to either exclude it or include it when determining what is part of the whole development environment. And assuming I am right about this, the definition of the whole development environment will therefore be fuzzy. And having a logo for the whole development environment would therefore not be very useful.

I think the atomic logo is nice, although I think each ring should have its own particle :- ).

I think I should have been clearer. I do believe that EGM can be used for what I want. Basically, while you are using the IDE, you can access the files inside the game (like object files, room files, etc.) outside of the IDE, modify them in some way (a text editor, a pull through git, etc.), and you can then refresh the IDE (or similar) to get the changes, without having to restart the IDE. Likewise, if you change something inside the IDE, it will be reflected in the file system, and the VCS can see the changes.

An example of what I am talking about is gedit. You change a file inside gedit, save it, and it is reflected in the file system. If you then change a file you have open in gedit outside of gedit (for instance through another text editor or pulling some updates) and you switch to the view of the file in gedit in which the changes have been made, gedit informs you that the file has changed, and offers to either reload the file or cancel reloading. Basically, gedit checks the status of the files on the file system and reacts on it. I know that other editors like Eclipse and NetBeans have similar handling of files changing on the system.

Currently in LateralGM, if you save as an EGM, the game is stored compressed in EGM. If you go into the EGM file without unpacking it and make changes in it, LateralGM is unaffected. If you restart LateralGM, it will see the changes you made to the EGM. Basically, what I want the editor to do is to detect any changes in the EGM file, and handle it in some way, without having to restart the editor.

So I guess what I actually want is for the editor to detect changes on the file system (for instance coming from some VCS) and handle it, such that the editor does not need to be restarted. That would enable it to work well together with different VCSes.

I think this sounds very interesting. The two main features I can think of that I would really like is a room editor like in LateralGM, as well as the possibility of easily using a version control system while using the editor.

For the version control systems, I don't necessarily want them integrated directly into the editor, rather just being able to use them simultaneously and having changes from the VCS reflected in the editor or vice versa. That would be very nice.

The latest release is very nice, the turrets add a lot of challenge to eating some of those apples. My best score so far is 3450.

I didn't have any trouble with either crashing or too long level generation in this release. When I died, the number of apples to eat before next level didn't seem to reset, such that I had to eat 12 apples on level 1 before getting to the next level. Also, it would be nice if the turrets were a bit easier to tell apart from the normal walls.

The game crashes a lot less now, though it still crashes sometimes. In some of the later levels, the level generation either takes a long time before finishing, or does not finish.

Nice improvements, the level generator is a great touch.

The game also crashed when I played, but I managed once to get to level 3 and play through that before crashing when going to level 4. I also sometimes lost lives when changing levels.

Working on making the game fun might be a better idea. If you make the game fun, you can always go back to working on displaying score points. Then again, if you are still new to game development, it may be a better idea for you to just experiment as you want to. Modifying existing examples can be a great way to do that, because most of the work in the game is already done. I remember modifying the example 1945 (http://sandbox.yoyogames.com/downloads/tutorials/shooter.zip), adding stuff like shooting two or three bullets at a time, shooting rear bullets, shooting new types of bullets (like seeking bullets), new types of enemies, power-ups, and all kinds of stuff like that. Basically, just having fun messing around with the existing examples. Once you have done that, creating a game from scratch becomes much easier.

Nice WIP, early in its life but still playable. There is not much challenge in the game at the moment, though I assume that you are going to address that.

One thing I noticed is that the fruits are not aligned to the grid of the snake's movement. If you align the fruits to the grid of the snake's movement, it will be easier for the player to determine when the snake is going to collide with the fruit. In the LateralGM room editor, you can adjust how large the grid should be by adjusting the "W" and "H" fields. They are by default set to 16 by 16.

It isn't that many years since there would often be one problem or another when setting a Linux system up, such as drivers and hardware, which often required users to use the command line to try and solve it, and search for solutions online just to get simple things working. For programmers, this was often not a large burden, but for regular users, it could be difficult or impossible to figure out what to do. The situation has become considerably better the last couple of years, especially due to the improved driver support, but also due to general progress in Linux desktop environments. I think Ubuntu is getting to the point where a regular user never needs to open a terminal ever or very, very rarely, which is close to the situation on Windows, where you also never or very, very rarely as a regular user have to open a terminal. Windows "just works" for regular users, and Ubuntu (and other distributions, to some degree) is getting close to have the same property. Ubuntu is probably one of the more pragmatic distributions out there, for instance in regards to the use of proprietary drivers.

The errors are due to issues with "min" and "max", which are related to the parser and are going to be fixed in the future. In the meanwhile, copy-pasting the following code in LateralGM into Enigma->Definitions should fix the issues:

Code Select Expand



#define min internal_min
double min(double x1, double x2) {
return x1 < x2 ? x1 : x2;
}
double min(double x1, double x2, double x3, double x4) {
double xmin = x1;
xmin = xmin < x2 ? xmin : x2;
xmin = xmin < x3 ? xmin : x3;
xmin = xmin < x4 ? xmin : x4;
return xmin;
}
#define max internal_max
double max(double x1, double x2) {
return x1 > x2 ? x1 : x2;
}


[General Guidelines and Rules]

This forum is for discussion of game projects you are working on and share your games for everybody. Useful feedback includes bug reports, suggestions, praise and criticism of the game, with the purpose of helping make the game in question better. Please stay on topic here, we have other boards for posting bug reports including a tracker that is integrated into the website and an off topic forum.

Works in progress that are posted here should be generally playable and usable, somewhat bug-free, and be realistic in their scope. They do not have to be filled with content, but there should be some gameplay available, such that useful feedback can be given on the game. You should also read the universal board guidelines and rules as they are in effect site wide.

General Guidelines and Rules

* DO NOT post spam or post virus-infected downloads, or your account may be terminated.
* Prank games and programs are only allowed if very clearly labeled, with instructions for disabling the program.
* Keep feedback to constructive criticism: do not bash other members' games for unrelated personal matters.
* Try to limit the number of images you have in your topic; nobody likes taking 6 hours to load a page. There is no set limit; if moderators feel you have too many, they will inform you.
* Try to stay on topic and not hijack a members topic bragging about how many kills you got on Call of Duty last night. It is disrespectful to them, and we have an off topic forum for such discussion.

Posting Criteria


* Please include screenshots and images in your post. Other users may like to see these before they download. Consider DropBox, ImageShack, Tinypic, PostImage, ImageUpload, etc.
* Information regarding the download size of your game is also helpful for other members.
* Try to be concise without cutting out important details in your description. It is also nice to include information regarding the genre, and other specifics.


Rules by forthevin and Robert B. Colton.