Projekt Wolfenstahl

Tuesday, February 12, 2013

Last minute problems...

 scroll down for english text

ゲームをテストしてた最中にまた最大な問題が発生しました。
パーフォーマンスの問題をコントロール出来るように頑張って解決をしようと思いましたが、解決できなかったようです。
解決できないって事は、パソコンによって遊べないって事になります。
(残念ながら僕は素人のプログラマーなので、正確な原因を突き止めることはできませんでした。)


現在これを解決する唯一の方法は、最初からゲームを一から作り直す事ですが、全くの現実的な解決方法ではありません。
これまで仕事とかで貯めてきたお金で何とかゲームを作り上げましたが、お金がほとんど残ってない状態になり、ゲームを再構築する余裕はないんです。
原因は僕のプログラミングなのは知っています。でもこれでゲームのキャンセルをしてしまったら、気長く待っていた方、パーフォーマンスの問題があっても遊べる状況である方に申し訳ないからです。


まぁ、僕にとっては別にお金がなく、またはお金を出す価値がないって思う人がいて、それらの理由で違法ダウンロードでゲームをDLする人もいればそれで良いと思います。
本当にゲームを楽しんでくださる方は開発者をサポートすると思いますし、最も重要なことは、それらの人々が存在していることだと思います。
問題もいっぱいありながらも僕はその思いでゲームを完成させることが出来ました。
そして最終的に誰もゲームを購入してくれなかった場合は、私が単に失敗をしてしまった原因とみます。


この問題に対して、少なくとも何かをするために、僕は次のことを行うことを決めました。
僕は公開されるゲームと新しく出来上がるデモ版をアップロードします。デモ版は技術的にフルバージョンと同じ量の資源を消費します。
(すべてのグラフィックスなどが含まれていますが、"ロック"されているのでアクセスはできません。)

デモ版が実行できる場合は、フルバージョンも実行できるということです。
100%確実にしたい場合は、デモ版のステージをクリアすることをお勧めします。
それと、ゲームは2BG メモリーを使うので、3GBか4GB メモリーのあるパソコンでしか遊べません。
(OSとその他もメモリーを使いますので。)



何人かの人々がゲームをプレイすることができない可能性がりますが、それでも私たちがゲームを続けられるようにサポートをしたい方に私たちは寄付金の受け入れを開始する可能性を考えてみました。
馬鹿な失敗を犯してしまった事はまことに申し訳ないです。始めてのプログラミングだったので、次回からはもう同じ失敗しないよう頑張りたいと思います。







During testing we ran into another unforseen problem.
It seems that though we tried our best to get the performance problem under control, it didn't disappear entirely.
This means, that the game seems to be unplayable on some computers.
(unfortunately, since I'm a novice programmer, I'm not able to pinpoint the exact cause of this)


Currently the only solution to this that I can see is, to start building up the game from scratch, which is no viable solution.
I financed the developement of the game so far with money I had saved during previous jobs, but since there is nearly nothing of it left anymore, I can't afford to rebuild the game from scratch.
I know that my poor programming skills are the cause of this, but I think it's sad if I just cancel this game, because people enjoy playing it, and because some people are still able to play it despite the performance problems.


I think I’m okay with people pirating the game, if they don't have the money to buy it, or if they don't think it’s worth it, because of the problems.
The ones that really enjoy playing a game will buy it to support the developer and the most important thing is, that those people exist.
That's what I think, and that's what made me finish development, even though there have been so many problems.
And in the end, if no one buys it, it simply means that I failed and in that case, I'm fine with it.


So to do at least something against the problem, I decided to do the following:
Along with the release I'll upload a new demo version, the demo version technically uses up the same amount of ressources like the full version.
(since all the graphics etc. are included, but "locked" so they can't be accessed)

If the demo version runs on a computer, the full version should run too.
To be 100%ly sure, you should play through the complete stage of the demo version.
Other than that, since the game uses up 2 GB RAM, you should have a computer that has 3 or 4 GB RAM in total.
(since the OS and other stuff uses up RAM too)



Because some people might not be able to play the game, but still want to support us so we can continue to make games, we tought about the possibility to start accepting donations.
I sincerely apologize for the stupid mistakes I made while programming the game, it's my first game project and I'll do my best to not repeat those mistakes on future games.


~Wolfenstahl~

9 comments:

  1. To be honest, I was kind of scared when I opened the task manager for the demo, it alone eats more resources than Sky rim, my PC has 2Gb of ram, if what you say is true, I won't be able to run the full version.

    I just did a test where I added around 40 wallpapers as backgrounds ranging from 768 to 1280 in size and around 90 non- cropped sprites, the resulting EXE file was 100mb but the memory usage only spiked to 720 Mb, while the demo eats around 1Gb with 50% Cpu usage and it was smaller in size, do you have more or less than that? It seems the graphics may not be the problem but maybe a memory leak probably having to do with resource loading, also sound sampling can be unnecessarily high especially if you deal with large WAV files.

    Would you care to share a brief explanation on how did you mange to optimize it down to 2 Gb the first time, there are maybe some other methods you are missing.

    I'd say it's worth it to spend a bit more trying to optimize it as much as possible, would only be you trying to fix it, no need for more people or extra cash.

    It seems like the best method would be external resources and fix a memory leak if there's any, but again, I don't know what you did exactly.

    ReplyDelete
    Replies
    1. I just added a bunch of wav files and it crashes upon loading, that could be another reason, if that's a problem you could use OGG files with the Super Sound System DLL, but that would mean rework all the sound portion codes and convert all the sound files to OGG.

      Just as a test you could SAVE AS a copy file (for lucifer, do not modify the original file) and delete all the audio, try to fix the entry level audio error messages and see if there's any difference in memory and CPU usage.

      But given the CPU usage spike, it must be a resource loading problem, maybe loading the same one several times or something like that.

      Delete
    2. So far the game contains 42 CGs (~62 CGs in total with all the variations), ~400 sprites of which I guess are about ~200 animations, and a lot of stage backgrounds that are of higher resolution.
      (and yes, there is also music in the game)

      If I take the information you posted and make a projection, the used up GB RAM matches.

      I managed to reduce the usage of GB RAM by splitting several larger graphics into smaller ones (especially the backgrounds).
      And I also replaced the CG PNGs to JPGs.
      Furthermore I decreased the music quality a lot...
      That way it was possible to save around 0,5 to 1 GB RAM...
      (no kidding)

      Unfortunately I already replaced all the stuff that was possible to replace, and the last and probably best solution would be, to store all CGs externally.
      The downside of doing this now is, that I would have to reprogramm a lot, and of course there can be new bugs, so we need to do more testing.
      I guess this would push the release for another 3-4 weeks.

      On top of that, I'm not sure if I manage to do it right at my first try, and if it will be sufficient to solve the problem.
      Worst case scenario, I would still have to externally store the backgrounds and sprites/animations.
      (as I mentioned in the blogpost, we are running out of money to work with...)



      What I learned of this experience is, that first of all, it's best to do games with smaller sprite images.

      Secondly, I wouldn't use so many hentai animations.
      As it is now, the tentacle monster has more than 16 animations for the hentai scenes...
      (I forgot the exact number, but I think it's even more than 20)

      Well, it's that much because it has 3 variations of hentai attacks, that can connect in different random sequences.
      (I'll spare further details, but I hope you get what I'm trying to say)

      Looking back at it... it's a nice idea, but it's unneccessary to have several different hentai animations per enemy.
      And in the end, those variations in the hentai attacks are eating up a lot of ressources.
      (and implementing them took a lot of time, drawing as well as programming them)

      Thirdly, and I think this is also very important, I should stick to simple tileset leveldesign.
      No big background sprites with big background objects.

      Fourthly, CG's should be loaded when they are needed, not right at the start of the game.
      And of course not all of them at once, only those CG's for the specific scene needed.

      Fifthly, use MIDI-files instead of WAV-files.
      (we couldn't do that because the music was already done, and the software that was used couldn't compile the music as MIDI-file)


      Well, I'll stop here.
      (And yes, I'm certain that the graphics are the main cause for the 2 GB RAM issue, splitting the graphics whenever possible into smaller graphics, greatly reduced the RAM usage)
      I already understood the core of the problem... but unfortunately it's too late already.


      I'll use this experience to improve on the next game.
      And my aim is to not go over 1 GB RAM, so that the game runs on 2 GB RAM computers without any trouble.
      (well I guess 1,1 or 1,2 GB RAM would be okay at most... but at no cost above those numbers, since it's just too much)
      I believe with the mentioned measures, a game can be made with 0,5 to 1,0 GB RAM usage, which should be fine.

      Well, this is about everything I figured out about the issue myself.
      (it's mainly the bigger graphics and the lack of externally stored files that get loaded into the game when needed)

      Delete
  2. I want to say thank you for all your hard work despite the problems you've encountered, and I want to assure you that I will support your game's development even if it is unplayable to me. You've obviously worked very hard and I've been very excited for this game.

    Please stay strong and continue with your dreams!

    ReplyDelete
    Replies
    1. Thanks for your support, it really means a lot to us.
      I hope that you'll be able to play our upcomming games.
      (certainly I'll make sure to not repeat the mistakes I made)

      Delete
  3. In which language is the game coded?

    ReplyDelete
    Replies
    1. I'm not sure which programming language it is, since we use game making software to build the game up.

      Delete
    2. Is it Game Maker? That's waht I thought it was.

      Delete
  4. https://www.paypal.com/uk/cgi-bin/webscr?cmd=_donate-intro-outside

    get your button up allready, i'm sure there are people who woudlve dontated allready given the option

    ReplyDelete