For some reason the game graphics from Amaranth doesn't appear correctly on my PC.
http://lachie.phatcode.net/amaranth_on_my_PC.png
It's competition time!
-
Lachie Dazdarian
- Posts: 2338
- Joined: May 31, 2005 9:59
- Location: Croatia
- Contact:
Alrighty, I updated my original release post. It has the source version for my entry (simply compile sector.bas to build the game) and a separate zip for the executable + src archive. I made this a 1.1 version, applying some minor tweaks to gameplay in the last 5 randomly generated levels to make them a little easier.
From the previous post...
Play it today! : )
(Downloads: competition entry, with .exe)
From the previous post...
You can read that post for more information or get to playing using the links below...So, what is SECTOR SHOCK? Well, it's a top down space shooter that takes advantage of the arrow keys for movement, WASD for firing, and shift/ctrl for special features. The game features 6 types of enemies and their generators (portals), 3 types of weapons, 2 special maneuvers, and 2 special bonus types spread across 25 waves of combat. Each wave gets progressively harder, while your ship gets more lethal. There are a few different level types, and even some health and support resources that must be managed during gameplay. There are some fun particle effects to provide atmosphere, courtesy of the excellent HGE library without which my entry would not be near as good. I assure you the game is very beatable, as I've played through every level myself. Estimated play time is somewhere around 45 minutes to an hour. I hope you have great success, and please post your scores on the forums!
Play it today! : )
(Downloads: competition entry, with .exe)
-
KristopherWindsor
- Posts: 2428
- Joined: Jul 19, 2006 19:17
- Location: Sunnyvale, CA
- Contact:
Here is my final entry! High scores are provided by my little brothers (the beta testing team)! XD
http://fusionware.ourproject.org/itech/uploads/orb.zip
EDIT: Server is down right now, should be back soon. oO
You can also try the same file from: http://www.zendurl.com/tzmne/orb/Orb.zip
Last edited by KristopherWindsor on Nov 20, 2007 4:01, edited 1 time in total.
Put all of the entries except your own in the order you like them. Then, give your top entry 15 points, your next highest 14 points etc.Lachie Dazdarian wrote:How will we be voting for other entries? Just pick our favorite and name it, or give some points to each entry?
You'll have until 21:00 GMT on Monday 26th November to decide on your scores and get them to me either by posting on this thread, or if you prefer to do this in private, via an email sent to: chris [@] ciw42 dot net.
I'll be adding up all the points and re-awarding the highest scoring one 15 points, the next highest 14 etc. The total scores will be published along with the results, but I won't be saying how you each voted.
Edited: The time I'd given was wrong.
Last edited by ciw1973 on Nov 20, 2007 18:20, edited 1 time in total.
Oh man... just played Orb, Final Invader, and duke's shooter... these games rock. Thanks a lot for the fun guys... gonna have to download the rest and get to playing. I love the story screens in Final Invader, the physics in Orb, the graphics in Duke's... fun stuff. I'm quite impressed and may just have to recruit duke4e to help me spice up SECTOR SHOCK after the competition. ; )
Can't wait to play the rest!
Can't wait to play the rest!
Yeah, I'm a big fan of the same, but I think next time we need a regular game programming competition without any restrictions like these last two.ssjx wrote:@ciw1973, for the next competition, how about a limit on the binary size? I've always like the idea of squeezing as much as possible into a tiny file!
Ok, for all people who are getting weird graphics in my game:
Seems like this is problem with HGE 1.8 or HGE wrapper. Most probably with HGE 1.8 (and thus HGE wrapper). There have been some problems with 1.8 reported to HGE forums. I've also had problems with HGE 1.8 in c++. When the game was compiled with HGE 1.8/Visual C++ some people couldn't run it. The exact same file compiled with HGE 1.7/G++ worked perfectly.
So PLEASE take this in mind when judging my game, and try it to run it on friends computer (intel + nvidia = similar to my pc where game works 100% correct)
Seems like this is problem with HGE 1.8 or HGE wrapper. Most probably with HGE 1.8 (and thus HGE wrapper). There have been some problems with 1.8 reported to HGE forums. I've also had problems with HGE 1.8 in c++. When the game was compiled with HGE 1.8/Visual C++ some people couldn't run it. The exact same file compiled with HGE 1.7/G++ worked perfectly.
So PLEASE take this in mind when judging my game, and try it to run it on friends computer (intel + nvidia = similar to my pc where game works 100% correct)
duke, I noticed that and was hoping it wasn't my computer. I'd love it if you could post up a version w/ the images already included, even if it won't count for the competition! Also... I'm not getting any sound. : ( Sorry, I should've tested and reported back earlier in the competition.
Also, for everyone else, by my count we have eight awesome entries. I've thrown up a page here that will be updated with the results next week. I imagine there were some who e-mailed their entries directly to ciw1973, so there may even be more entries!
http://tracker.freebasic.net/ciw1973-sp ... ompetition
Also, feel free to post your high scores in my SECTOR SHOCK post:
http://www.bywombats.com/blog/ryan/11-1 ... ctor-shock
Also, for everyone else, by my count we have eight awesome entries. I've thrown up a page here that will be updated with the results next week. I imagine there were some who e-mailed their entries directly to ciw1973, so there may even be more entries!
http://tracker.freebasic.net/ciw1973-sp ... ompetition
Also, feel free to post your high scores in my SECTOR SHOCK post:
http://www.bywombats.com/blog/ryan/11-1 ... ctor-shock
Last edited by Ryan on Nov 20, 2007 1:50, edited 2 times in total.
-
KristopherWindsor
- Posts: 2428
- Joined: Jul 19, 2006 19:17
- Location: Sunnyvale, CA
- Contact:
During the trouble with HGE (to be more precise hge_Texture_Lock/hge_Texture_Unlock), I was rushed to make a NON COMPO version of game.
The gameplay is IDENTICAL while the only real difference is the graphics.
So, anyone having problems with compo version can check the gameplay by playing this version, and check graphics for compo version by viewing images generated in original/compo version's folder "graphics" OR by looking at screenshots I've posted earlyer.
Get the "enhanced" version here:
http://rapidshare.com/files/70936963/am ... al_gfx.zip
http://duke4e.sitesled.com/amaranth_real_gfx.zip
http://files-upload.com/files/629856/am ... al_gfx.zip
Sorry for the inconvenience caused by HGE and f**k you HGE for screwing with my chance to get some money!
The gameplay is IDENTICAL while the only real difference is the graphics.
So, anyone having problems with compo version can check the gameplay by playing this version, and check graphics for compo version by viewing images generated in original/compo version's folder "graphics" OR by looking at screenshots I've posted earlyer.
Get the "enhanced" version here:
http://rapidshare.com/files/70936963/am ... al_gfx.zip
http://duke4e.sitesled.com/amaranth_real_gfx.zip
http://files-upload.com/files/629856/am ... al_gfx.zip
Sorry for the inconvenience caused by HGE and f**k you HGE for screwing with my chance to get some money!
"Regular" meaning not doing a Maximum With a Minimum.. not like this compo ...ciw1973 wrote:Yeah, I'm a big fan of the same, but I think next time we need a regular game programming competition without any restrictions like these last two.ssjx wrote:@ciw1973, for the next competition, how about a limit on the binary size? I've always like the idea of squeezing as much as possible into a tiny file!
What a pity ...
I miss out this compo due to an "over busy period" with my boss
Then I 'm hoping that another compo of this style will come soon ...
You know ... only Short Project is accessible to me, with no Xtra time costly stuff.
Anyway depending the scope of the "regular" compo, I 'll try to attend.
duke4e:
Don't worry about that side of things, I have the same problem with black boxes whilst playing your game on my machine, but I think we all understand that this sort of thing is beyond your direct control, and that in a competition such as this you're probably not going to have time to test a game on a number of different machines and configurations.
If you look back to my first post in this thread, I've detailed how the scoring is going to work for this competition, and as you'll see, only 25 of the marks are for graphics, and they are for how effectively the original graphics are used.
What I should point out is that there have been concerns raised about the running of a seperate program to generate the graphics actually used by your game. I have to say that this wasn't what I'd expected, and I've thought long and hard about this since I tried your game out last night, and will explain my thinking on this and what I've decided to do.
When we discussed you creating temporary graphics files on disk and then loading those into the game, I expected that the user would run your game, which would load the original file, create the other graphics files, load and use them, and then delete them once they were no longer needed or when the game closed.
What we actually have is a seperate program, albeit written in FreeBASIC, which converts the existing graphics file into a number of other files on disk. The game, which runs seprately, then uses these files and not the originals. Whilst this does technically break one of the main rules, it warrants further consideration as follows:
We did discuss this on the forum and I said it was OK to create temporary graphics files, mainly because I accept it does make things a lot easier with most libraries being geared up to loading graphics from disk. Whilst the files you are creating aren't temporary files, I'm prepared to accept that this was simply a misunderstanding between us.
Also, there is no reason why the code which you are currently running once to create the graphics couldn't have simply been included at the start of your game. I'm aware that this would have resulted a 30 second start-up time, which would have been annoying every time the game was run, so I can certainly understand why you would have wanted to avoid this.
The conclusion I've come to, is that the situation we have now can be put down to a difference of interpretation, rather than any attempt to gain an advantage, and there is technically no reason why the code which has been provided seperately, couldn't have been included as part of the main game code. There is no external processing done, and everything was in written in FreeBASIC, so I'm happy for the game to stay in the competition and take its chances up against the others.
As can be seen from the judging categories though, there is much more to this challenge than how pretty the graphics look.
On another note, those of you with a hunger to take part in a(nother) competition may want to check out the next Ludum Dare 48 hour game programming competition due to begin on the 14th December.
There's no restriction when it comes to programming languages etc., as long as you don't use a game maker or anything which provides any game logic.
Details can be found here.
I'm hoping to take part myself, and will be using FreeBASIC instead of Python as I've done previously.
Don't worry about that side of things, I have the same problem with black boxes whilst playing your game on my machine, but I think we all understand that this sort of thing is beyond your direct control, and that in a competition such as this you're probably not going to have time to test a game on a number of different machines and configurations.
If you look back to my first post in this thread, I've detailed how the scoring is going to work for this competition, and as you'll see, only 25 of the marks are for graphics, and they are for how effectively the original graphics are used.
What I should point out is that there have been concerns raised about the running of a seperate program to generate the graphics actually used by your game. I have to say that this wasn't what I'd expected, and I've thought long and hard about this since I tried your game out last night, and will explain my thinking on this and what I've decided to do.
When we discussed you creating temporary graphics files on disk and then loading those into the game, I expected that the user would run your game, which would load the original file, create the other graphics files, load and use them, and then delete them once they were no longer needed or when the game closed.
What we actually have is a seperate program, albeit written in FreeBASIC, which converts the existing graphics file into a number of other files on disk. The game, which runs seprately, then uses these files and not the originals. Whilst this does technically break one of the main rules, it warrants further consideration as follows:
We did discuss this on the forum and I said it was OK to create temporary graphics files, mainly because I accept it does make things a lot easier with most libraries being geared up to loading graphics from disk. Whilst the files you are creating aren't temporary files, I'm prepared to accept that this was simply a misunderstanding between us.
Also, there is no reason why the code which you are currently running once to create the graphics couldn't have simply been included at the start of your game. I'm aware that this would have resulted a 30 second start-up time, which would have been annoying every time the game was run, so I can certainly understand why you would have wanted to avoid this.
The conclusion I've come to, is that the situation we have now can be put down to a difference of interpretation, rather than any attempt to gain an advantage, and there is technically no reason why the code which has been provided seperately, couldn't have been included as part of the main game code. There is no external processing done, and everything was in written in FreeBASIC, so I'm happy for the game to stay in the competition and take its chances up against the others.
As can be seen from the judging categories though, there is much more to this challenge than how pretty the graphics look.
On another note, those of you with a hunger to take part in a(nother) competition may want to check out the next Ludum Dare 48 hour game programming competition due to begin on the 14th December.
There's no restriction when it comes to programming languages etc., as long as you don't use a game maker or anything which provides any game logic.
Details can be found here.
I'm hoping to take part myself, and will be using FreeBASIC instead of Python as I've done previously.
Whilst I'm pretty pleased with how this competition turned out, I know that quite a few people also enjoy creating their own art and sound/music, and so the next competition needs to allow for this creativity.redcrab wrote:"Regular" meaning not doing a Maximum With a Minimum.. not like this compo ...
What a pity ...
I miss out this compo due to an "over busy period" with my boss
Then I 'm hoping that another compo of this style will come soon ...
You know ... only Short Project is accessible to me, with no Xtra time costly stuff.
Anyway depending the scope of the "regular" compo, I 'll try to attend.
I intend the next competition to be theme based, but there will still be restrictions of some sort to push people to be creative in terms of design and gameplay.
I think holding the competition over three weekends rather than a full month worked well, and unless anyone has any objectsion, the next one will be run for the same sort of period.