• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

2414 Excellent

1 Follower

About Avalander

  • Rank

Personal Information

  • Interests
  1. Tower Defenses: Best features?

    My absolute favourite feature of a tower defense game is from Kingdom Rush. There is this one tower that has the special ability to transform enemies into sheep every few seconds.
  2. Web Development Decisions.

    A CSS framework is a collection of styles designed to provide a consistent look and feel to a web page easily and without the user having to write any CSS. Josheir, we can gladly help you with any questions you have on what to use for this or how to use that or why does this thing behave that way. But if you want to get far in programming, you really need to start learning how to google stuff. Should I use bootstrap for this project? Is a question that we can provide insight on. What is a CSS framework? is easily googable, with a good Wikipedia page answering the question, and you wouldn't have had to wait eight hours to get an answer if you had just google that.
  3. Web Development Decisions.

    I do believe that learning Bootstrap is worthwhile. Here is my list of reasons. It's mature, maintained and actively developed (they released a new major version recently). You can customise the basic look and feel without a lot of effort. You get something that looks nice out of the box. Honestly, unless you have some serious experience in graphic design, the first hundred style sheets that you write will make your website look like the equivalent of a 5-year-old's drawing. It's widely used, so you will find a lot of examples and support on the internet. Using a (kind of) well-designed CSS framework will help you learn how to design your own CSS classes. If you are just starting web development, you will have to learn a lot of other stuff already, so keeping CSS for later should make things easier for you. Also, answering your question, it is free. Now, here are some reasons not to use/learn Bootstrap. You want to focus on learning CSS. You only want to build a very simple website with a header and some text, no fancy layouts, no styling forms, no menus with dropdowns and accordions, etc. You are going to use another CSS framework instead.
  4. How unwise would it be to still use flash for new game ?

    If you want an alternative to Flash, I suggest that you look into Pixi.js. It's javascript, has support for Canvas and WebGL, good performance and many examples and learning resources.
  5. Star Wars: The Last Jedi

    I liked it a lot more that The Force Awakens, although that can be explained by my expectations being much lower. I liked that there was more character development and less action scenes, and the plot felt less copy-paste from the original trilogy. I didn't like that there are some scenes that are trying too hard to be funny and I feel that they don't go well with the tone that the rest of the movie wants to set.
  6. November 2017 GameDev Challenge: Pong!

    You still have three weeks to go, should be enough to create a pong game
  7. Ask feedback about my idea

    Kind of hard to say anything... Lots of people like space exploration games, so sure, it's a workable concept. I suggest you spend some time defining the mechanics of your game if you want to get any good feedback.
  8. Hi, I've seen this a couple of times. I don't think this is the way it's supposed to look like. I'm using Chrome 60.0, if that's relevant.
  9. WoA V - Afterparty/Judging thread

    Hey, I'm a bit late to the party, but thanks to all the judges and @slicer4ever for making this possible! It was really fun to participate!
  10. Perceiving is believing - part 2

    That was an interesting reading, thanks for sharing!
  11. Pretty much any graphics library can render pictures in the background, photograph-like or not. Adding a few textboxes here and there isn't very performance intensive either. You should be fine with whatever library you choose.
  12. Hobby: How do you finish your projects?

    I don't do much game development in my free time nowadays, but I've got many other programming related projects going on, and my process is roughly the same. My philosophy is to try to remove or defer as much complexity as possible and get a "complete enough" version of the software as soon as possible. Usually, my personal projects follow these four stages: (1) I have a cool idea that I would like to realise, I spend an evening working on it. Many, not to say most, of my projects get abandoned after this stage. Maybe I'm not that interested, they weren't as fun as I expected or I simply don't have the time to keep working on them at the moment. In any case, I accept this as part of the normal process. I've got way more ideas than I'll ever be able to realise. (2) If I keep working on a project after the first evening, I try to reduce the project to the bare minimum set of core features required to cover the principal idea or use case. Even if I have a lot of cool ideas, I try to push as many as I can to further stages, and have a minimum game/project that I can finish in a few weeks of intermittent work. I know that I will abandon many projects after this stage, so I try to set goals that I can accomplish and have a feeling of completition even if my interest/free time plummets. (3) Now I have a working version of the game, but it probably feels more like a demo than a complete version. It's time to focus on the features that I need to make it feel like a finished product. Again, I try to focus on the features that are strictly required to make the game feel like a complete working version, and that I can hopefully finish in a few more weeks of work. (4) At this stage, I consider that my project is "complete" and I add all the features that I wanted to have but weren't important enough to implement in previous stages. Usually, I will have collected a list of them during the previous stages. I keep working on that set of features, one at a time, until I lose interest in the project. It doesn't matter how far I get, because at this point I have something that already feels complete and deliverable. As somebody once said, "software is never completed, only abandoned", and since chances are that I will abandon it sooner than later, I try to have something that feels complete enough as soon as possible. That doesn't mean that I defer all the cool and interesting features to the end of the project. However, most of the times I can identify one or two interesting ideas that are the core of what I want to do, and defer the rest to later stages.
  13. WoA V - Afterparty/Judging thread

    Yeah, that's exactly how it works. Capture game input into streams, map-fold everything with pure functions and then render to screen. I'll download your game and give it a try this afternoon. I'll get back to you
  14. WoA V - Afterparty/Judging thread

    I've written a post-mortem, if anybody is interested. I've also downloaded a few submissions, but since I don't have Windows, I couldn't play any of them
  15. Play it! | View on GitHub Now that I am slightly recovered after the Week of Awesome, I want to share my thoughts about what went well and what I have learned after this experience. A quite important part of my project was to experiment with functional reactive programming in games, and I promised to share some reflections about it afterwards. I'm going to talk about that in the second part of the post-mortem, which I expect to publish early next week. What was great Community support and feedback The absolutely best thing about participating in this contest was all the encouragement and feedback I got from the community. Big thanks to everybody who took the time to play my game, read my blog entries, post feedback and encouraging comments, and even find and report bugs! My game would have been a lot worse without that feedback. Many people suggested features I hadn't thought of or I had dismissed earlier because I didn't think they were that important. The ability to move to the left and better control of the landing position when jumping are clear examples of this. It was also really motivating to see every day people playing the game and posting new feedback. Browser game I think that going down the browser route was a good idea after all. The cool thing about the browser is that everybody has one. Distributing your game is so easy: no installation or configuration required, and everybody can play it regardless of operative system or installed runtimes. I could upload the game to my VPS since day one, update it often, and have people trying it out, which was great and I think that it made a difference in the amount of feedback I received. What I would do differently Have a level editor The game I delivered is inexcusably short. Once I had the basic mechanics going, it would have been really easy to add more and longer levels. The only reason holding me back was that I didn't have any visual tool to create and edit them. I created the only level in the game by manually editing a JSON file. As you can imagine, that was a tedious job and I decided to invest the little time I had in solving other stuff. Not having a level editor also prevented me from iterating the level and making sure it was fun and challenging enough. Next time, I will make sure to have a visual tool to create levels and maps at hand before the contest starts. Test the delivery format early When I set off to make a browser game, I set up a local development web server to serve the file and recompile and reload the changes quickly. I knew that I would end up delivering an index.html file with a .js bundle and that the judges would load that file from the file system instead of a web server. That should make no difference, right? Wrong! Turns out that Chrome, among other browsers, doesn't allow AJAX requests when loading a file directly from the file system. And guess how the rendering library I used loads spritesheets? Exactly: AJAX calls. I should have tested running the game from the file system since day one. Instead, I only tried it when I was about to upload the final submission. If I had known about the AJAX issue earlier, I could have written my own resource loader, or bundled the game with electron. Instead, by the time I noticed the issue, I didn't have the time nor the energy to do something about it. Even though the game can still be run locally with Firefox, I provided a python script to run it on a local web server, and some judges didn't mind playing it on my VPS, my developer soul still hurts because I wasn't able to deliver software that runs with a single click. Conclusion This community is awesome. I got far more interest and feedback than I expected. I liked the experience of making a browser game, even though at the end it wasn't as smooth as I thought, and I definitely need to get a level/map editor next time. If you are interested in reading my musings about using functional reactive style in games, stay tuned for the second part of the post-mortem.
  • Advertisement